Hindsight 监控指南：Prometheus 指标、健康探针与 OpenTelemetry 分布式追踪

Hindsight 监控指南Prometheus 指标、健康探针与 OpenTelemetry 分布式追踪【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsightHindsightAgent Memory That Learns通过三条互补的通道提供完整的可观测性Prometheus 指标/metrics端点、三个语义不同的健康端点/health/live、/health/ready、/health以及遵循 GenAI 语义约定v1.37的 OpenTelemetry 分布式追踪。本文以 monitoring.md 为主线结合仓库中的 metrics.py、tracing.py、liveness.py 以及 monitoring 启动脚本 等实现系统讲解如何在本地一键拉起 Grafana LGTM 可观测栈、正确配置健康探针避免把数据库抖动升级成停机事故、理解每一类指标与标签的语义并利用现成的 Grafana 仪表盘与示例 PromQL 查询完成生产级告警。本地可观测栈一条命令启动 Grafana LGTMHindsight 为本地开发提供了开箱即用的 Grafana LGTMLoki、Grafana、Tempo、Mimir一体化栈一条命令即可启动./scripts/dev/start-monitoring.sh该脚本是 start.sh 的便捷包装后者会先探测 API 是否已在运行curl http://localhost:8888/metrics未检测到时给出警告并提示先通过./scripts/dev/start-api.sh启动 API随后调用docker-compose up拉起整个栈。从 docker-compose.yaml 可以看到它基于grafana/otel-lgtm:latest镜像启动一个名为hindsight-monitoring的容器并做了三处关键配置端口映射3000Grafana UI、4317OTLP gRPC 追踪、4318OTLP HTTP 追踪匿名管理员登录GF_AUTH_ANONYMOUS_ENABLEDtrue、GF_AUTH_ANONYMOUS_ORG_ROLEAdmin、GF_AUTH_DISABLE_LOGIN_FORMtrue本地开发无需登录挂载 Prometheus 配置与 Hindsight 仪表盘用 prometheus.yml 覆盖 LGTM 默认抓取配置并把三个 Hindsight 仪表盘 JSON 挂载进容器通过 grafana-dashboards.yaml 自动 provisioning。启动后即可获得能力地址 / 说明Grafana UIhttp://localhost:3000匿名 admin 访问追踪TempoOTLP 端点 http://localhost:4318HTTP与 http://localhost:4317gRPC指标Prometheus/Mimir自动抓取 http://localhost:8888/metrics日志Loki日志聚合预置仪表盘Hindsight Operations、LLM Metrics、API Service值得注意的细节是 prometheus.yml 中的抓取配置它同时声明了hindsight-apihost.docker.internal:8888和hindsight-workerhost.docker.internal:8889两个 job配合extra_hosts: host.docker.internal:host-gateway让容器能访问宿主机上的服务scrape_interval: 5s、evaluation_interval: 5s并开启了scrape_native_histograms: true以支持原生直方图。注释明确说明 worker 的 job 在宿主机没有运行 worker 时是无害的空操作——这为后续生产环境抓取独立 worker 指标提供了现成模板。在 API 中启用追踪export HINDSIGHT_API_OTEL_TRACES_ENABLEDtrue export HINDSIGHT_API_OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318:::note 生产环境部署 本地监控栈仅用于开发。生产环境应单独部署 Grafana LGTM或使用商业平台Grafana Cloud、DataDog、New Relic 等。 :::健康端点区分存活与就绪避免把数据库抖动变成停机API 服务端端口 8888与每个 worker端口 8889都暴露同样的三个端点。它们回答两个不同的问题把探针指错位置就是平稳度过数据库抖动与把抖动升级成一次停机事故的区别端点是否检查数据库用途/health/live否Liveness 探针/health/ready是Readiness 探针/health是Readiness——/health/ready的别名为兼容性保留/health/live只要进程还能处理请求就返回 200且不产生任何 I/O{ status: alive, version: 0.4.0, uptime_seconds: 812.4 }能应答本身就是检查。Hindsight 在单个事件循环上运行请求处理器与任务工作因此被阻塞调用卡死的事件循环无法在探针超时内应答——而这正是重启能修复的故障类型。其实现位于 liveness.py模块文档开宗明义地写道liveness 只回答一个问题这个进程是否已经卡死到只能靠重启修复它绝不能触碰数据库因为运行SELECT 1的 liveness 探针会把数据库降级变成停机事故。worker 的载荷额外增加了worker_id、is_shutdown和seconds_since_last_poll距上次完成 claim 周期的时长第一次之前为null。最后一个字段是为了告警而设计的它从不改变状态码因为卡在饱和数据库后面的 poller 恰恰是重启会雪上加霜的情形——正如 WorkerLivenessResponse 的文档所写报告它只是为了告警——无论它多陈旧端点都保持 200这样饱和的数据库永远不可能触发重启。/health与/health/ready获取一个池化连接并执行SELECT 1数据库可达时返回 200不可达时返回 503。载荷区分了两种出错方式——db_acquire_ms与db_pool_waiting指向连接池耗尽而慢查询指向数据库本身{ status: healthy, database: connected, db_acquire_ms: 0.4, db_pool_waiting: 0 }:::warning 绝不要把 liveness 探针指向依赖检查 liveness 失败意味着重启这个进程。如果 liveness 探针检查数据库那么数据库变慢会让所有 Pod 同时重启在途请求被丢弃已认领的异步操作以递增的retry_count重新排队一步步走向永久失败悬崖每个重启的 Pod 还会在一个已经不堪重负的数据库上重新连接、重新预热连接池。就绪失败才是正确响应——它把 Pod 从 Service 中摘除待数据库恢复后再放回。仓库自带的 Helm chart 已经如此配置livenessProbe→/health/livereadinessProbe→/health。如果你基于旧版本手写了 manifest请把 liveness 路径改过来。 :::这条警告在源码与 Helm 配置中都能得到印证api-deployment.yaml 将探针模板化为 values 中的值而 values.yaml 中 API 的livenessProbe使用httpGet: path: /health/live, port: 8888initialDelaySeconds: 30, periodSeconds: 10, timeoutSeconds: 5, failureThreshold: 3readinessProbe使用path: /healthinitialDelaySeconds: 10, periodSeconds: 5, timeoutSeconds: 3, failureThreshold: 3。注释还特别说明 liveness 需要 chart 的 appVersion 或更新版本的镜像——旧镜像只提供/health会以 404 使探针失败。worker端口 8889的探针配置同样遵循这一模式。指标端点与指标体系概览Hindsight 在/metrics暴露 Prometheus 指标curl http://localhost:8888/metrics指标基于 OpenTelemetry SDK 构建由 metrics.py 中的initialize_metrics()完成初始化创建带service.name/service.version资源的MeterProvider通过PrometheusMetricReader导出并为三个时长直方图注册自定义分桶的 View见下文直方图分桶。MetricsCollector类通过create_histogram/create_counter/create_up_down_counter/create_observable_gauge逐一注册了本文列出的全部指标当指标未启用时NoOpMetricsCollector提供同接口的空实现保证调用方无需判空。指标体系中还有几个仓库实现中值得一提的细节租户标签所有核心指标都通过_get_tenant()附带tenant标签来自当前 schema多租户部署可按租户拆分查询原文档表格未列出但源码确认存在端点基数控制normalize_http_endpoint() 会把路径中的/banks/id段、UUID 和纯数字 ID 分别模板化为{bank_id}、{id}保证endpoint标签基数有界指标开关metrics_include_bank_id配置项控制是否附加bank_id标签避免高基数同步抓取路径backlog / 队列深度等 gauge 由后台任务每 30 秒刷新缓存/metrics抓取路径保持同步见 metrics.py。指标详解操作指标Operation Metrics指标类型标签说明hindsight.operation.durationHistogramoperation, bank_id, source, budget, max_tokens, success操作时长秒hindsight.operation.totalCounteroperation, bank_id, source, budget, max_tokens, success已执行操作总数标签operation操作类型retain、recall、reflect以及consolidation等异步 worker 任务类型bank_id记忆银行标识source操作触发来源api、reflect、internal、workerbudget若指定则为预算等级low、mid、highmax_tokens若指定则为最大 token 数success操作是否成功true、falsesource标签用于区分api客户端直接 API 调用reflectreflect 操作期间发起的内部 recall 调用internal其他内部操作worker异步 worker 在认领任务达到终态时记录的完成对于sourceworkersuccess标签是完成吞吐信号false表示任务在重试耗尽或发生意外错误后向 poller 抛出。在 executor 内部处理并正常返回的失败在此仍记录successtrue要获取权威的异步操作失败状态请使用hindsight_async_operations{statusfailed}。从源码看操作指标还隐藏了一个语义细节在 record_operation 的上下文管理器中客户端断连导致的取消OperationCancelledError由 HTTP 层以HTTPException(499)重新抛出既不算成功也不算失败会被完全排除在指标之外避免膨胀成功率或失败率——这是通过遍历__cause__链匹配取消异常实现的见_is_client_cancellation。Retain 指标指标类型标签说明hindsight.retain.documents.totalCounteroutcome, bank_idretain 处理的文档数按抽取结果分桶标签outcome文档在 retain 后拥有记忆单元时为facts没有则为no_factsbank_id记忆银行标识outcomeno_facts是文档已存储但未产生任何记忆的信号。这些文档对recall和reflect不可见直到被重新处理——没有其他指标会报告它们因为 retain 本身成功了。该占比上升通常意味着 retain mission 排除了超出预期的内容sum(rate(hindsight_retain_documents_total{outcomeno_facts}[15m])) / sum(rate(hindsight_retain_documents_total[15m]))这一指标的动机在 metrics.py 的注释中有明确记录只有 memory_units 携带嵌入文档零事实意味着它在 recall/reflect 中不可达而系统内没有任何其他东西报告它——操作仍然成功完成。对它告警可以捕捉到 retain_mission 静默排除过多内容issue #3040。LLM 指标指标类型标签说明hindsight.llm.durationHistogramprovider, model, scope, successLLM API 调用时长秒hindsight.llm.calls.totalCounterprovider, model, scope, successLLM API 调用总数hindsight.llm.tokens.inputCounterprovider, model, scope, success, token_bucketLLM 调用输入 tokenhindsight.llm.tokens.outputCounterprovider, model, scope, success, token_bucketLLM 调用输出 token标签providerLLM 提供商openai、anthropic、gemini、groq、ollama、lmstudio、bedrock、litellmmodel模型名如gpt-4、claude-3-sonnetscopeLLM 调用的用途memory、reflect、consolidation、answersuccess调用是否成功true、falsetoken_bucket用于基数控制的 token 数分桶0-100、100-500、500-1k、1k-5k、5k-10k、10k-50k、50ktoken_bucket的实现就是 get_token_bucket()把连续 token 数映射到 7 个离散桶避免每个调用产生一个唯一标签值而引发高基数问题。此外源码中还注册了两个原文档未列入表格的补充计数器用于更诚实的成本归属hindsight.llm.tokens.cached_input按缓存费率计费的输入 token 子集用于独立追踪提示缓存命中率hindsight.llm.tokens.thoughts推理/思考 tokenGemini 2.5 系列按输出费率计费但不出现在 candidates 中——按输出量看起来便宜、实际因长推理链而昂贵的工作负载正是靠它暴露的。合并指标Consolidation Metrics指标类型标签说明hindsight.consolidation.batch_failuresCounterfailure_class, error_type失败的合并 LLM 批量调用包括其事实后来被恢复的标签failure_class调用的处理方式fail_fast——模型返回了响应 schema 拒绝的内容重发相同载荷无济于事retry——传输层形态的问题原样重发可能成功propagate——不属于批量失败重新抛给任务处理器error_type异常类名如ValidationError、JSONDecodeError这与 bank stats 中的failed_consolidation字段不是同一个信号。该字段统计的是失败后仍在等待合并的事实当批量调用失败时合并会把批次减半重试因此一个在批次大小 8 时失败、大小 1 时成功的调用会让failed_consolidation停留在 0。但失败响应请求的一切都会被丢弃——包括它想删除的 observations——所以一个银行可以看起来完全健康而其超驰清理却什么都没做。对 schema 拒绝率告警这是其他指标无法暴露的sum(rate(hindsight_consolidation_batch_failures_total{failure_classfail_fast}[15m]))持续非零的速率通常意味着合并模型不能稳定地为响应 schema 输出合法 JSON。切换到结构化输出更强的模型或在提供商支持语法强制的 schema 时启用HINDSIGHT_API_LLM_STRICT_SCHEMA_CONSOLIDATION是常见的修复方式。同一计数还会按运行周期报告为合并操作结果中的llm_batch_failures合并日志摘要会在其非零时打印警告行。两者统计的都是尝试次数——一个重试三次的批量调用贡献三次——因此不受运行中批次数量上限的约束。源码注释metrics.py进一步阐明了设计动机failed_consolidation是对携带consolidation_failed_at的行的 gauge因此它只报告卡住的事实——绝不会报告失败后其事实被调用方的自适应二分法救回的调用。一次运行可以烧掉几十次 schema 非法的调用、丢弃它们携带的全部删除却仍以该 gauge 为 0 和observations_deleted为 0 结束与健康运行无法区分#4151、#4152。这个计数器正是缺失的信号它统计调用而非卡住的行。HTTP 请求指标指标类型标签说明hindsight.http.durationHistogrammethod, endpoint, status_code, status_classHTTP 请求时长秒hindsight.http.requests.totalCountermethod, endpoint, status_code, status_classHTTP 请求总数hindsight.http.requests.in_progressUpDownCountermethod, endpoint正在处理的 HTTP 请求数标签methodHTTP 方法GET、POST、PUT、DELETEendpoint请求路径已归一化以降低基数——UUID 替换为{id}status_codeHTTP 状态码200、400、500等status_class状态码类别2xx、4xx、5xxHTTP 指标由 observability.py 中的纯 ASGI 中间件HttpObservabilityMiddleware记录。该文件的文档字符串解释了一个重要的性能背景它取代了两个基于app.middleware(http)的 StarletteBaseHTTPMiddleware处理器——后者每次请求都会派生子任务并通过 anyio 内存流管道传输响应在 2-CPU 容器、32 并发客户端的实测中移除它们使/health/live从约 1500 rps 提升到约 5100 rpsp99 从 159ms 降到 33ms同时 CPU 从饱和的单核降到约 65%——成本来自调度跳转而非计算。纯 ASGI 中间件则是在同一任务中的一次await包裹send以观察响应同时负责把未知参数注入X-Ignored-Params响应头。数据库连接池指标指标类型标签说明hindsight.db.pool.sizeGauge-连接池当前连接数hindsight.db.pool.idleGauge-连接池空闲连接数hindsight.db.pool.minGauge-连接池最小大小hindsight.db.pool.maxGauge-连接池最大大小源码中还存在hindsight.db.pool.acquire_wait直方图用于记录等待获取池化数据库连接的时间——即连接池耗尽信号以及hindsight.event_loop.stalls/hindsight.event_loop.stall_duration用于检测超过 watchdog 阈值的事件循环停滞来自 loop_watchdog.py。进程指标指标类型标签说明hindsight.process.cpu.secondsGaugetype进程 CPU 时间秒hindsight.process.memory.bytesGaugetype进程内存使用字节hindsight.process.open_fdsGauge-打开的文件描述符数hindsight.process.threadsGauge-活跃线程数标签typeCPUuser或systemtype内存rss_max最大常驻集大小进程指标以可观测 gauge 实现在抓取时通过回调采集CPU 时间来自getrusage的ru_utime/ru_stime内存使用ru_maxrss源码注释提醒Linux 上该值以 KB 计需乘以 1024 转字节而 macOS 上本身就是字节open_fds在 Linux 上通过枚举/proc/self/fd计数否则回退到资源软限制threads使用threading.active_count()见 metrics.py。直方图分桶为获得更准确的分位数配置了自定义桶边界操作时长分桶秒0.1, 0.25, 0.5, 0.75, 1.0, 2.0, 3.0, 5.0, 7.5, 10.0, 15.0, 20.0, 30.0, 60.0, 120.0LLM 时长分桶秒0.1, 0.25, 0.5, 1.0, 2.0, 3.0, 5.0, 10.0, 15.0, 30.0, 60.0, 120.0HTTP 时长分桶秒0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0, 30.0这三组分桶常量直接定义在 metrics.py并通过ExplicitBucketHistogramAggregation视图在初始化时注册操作桶在 0–30 秒区间大多数操作完成的范围提供细粒度LLM 桶针对更快的调用细化HTTP 桶则细化到毫秒级以覆盖快速端点。Prometheus 抓取配置scrape_configs: - job_name: hindsight static_configs: - targets: [localhost:8888]生产抓取时参考 scripts/dev/monitoring/prometheus.yml 中现成的写法metrics_path: /metrics、5 秒抓取间隔、单独为 worker 增加一个 job目标端口 8889并按需开启scrape_native_histograms。示例 PromQL 查询按类型统计平均操作延迟rate(hindsight_operation_duration_sum[5m]) / rate(hindsight_operation_duration_count[5m])各提供商每分钟 LLM 调用数rate(hindsight_llm_calls_total[1m]) * 60P95 LLM 延迟histogram_quantile(0.95, rate(hindsight_llm_duration_bucket[5m]))按模型统计总 token 消耗sum by (model) (hindsight_llm_tokens_input_total hindsight_llm_tokens_output_total)内部 vs API recall 操作sum by (source) (rate(hindsight_operation_total{operationrecall}[5m]))按端点统计每秒 HTTP 请求数sum by (endpoint) (rate(hindsight_http_requests_total[1m]))HTTP 错误率5xxsum(rate(hindsight_http_requests_total{status_class5xx}[5m])) / sum(rate(hindsight_http_requests_total[5m]))P95 HTTP 延迟histogram_quantile(0.95, sum by (le) (rate(hindsight_http_duration_seconds_bucket[5m])))数据库连接池利用率hindsight_db_pool_size / hindsight_db_pool_max活跃数据库连接数hindsight_db_pool_size - hindsight_db_pool_idleCPU 使用率rate(hindsight_process_cpu_seconds{typeuser}[1m])Grafana 仪表盘预置仪表盘位于 monitoring/grafana/dashboards/包含三个 JSON 文件hindsight-operations.json、hindsight-llm.json、hindsight-api-service.json。将它们导入 Grafana 实例即可仪表盘说明Hindsight Operations操作速率、延迟分位数、按银行统计的指标Hindsight LLM MetricsLLM 调用、token 使用、按 scope/提供商统计的延迟Hindsight API ServiceHTTP 请求、错误率、数据库连接池、进程指标使用监控栈脚本时仪表盘会通过 grafana-dashboards.yaml 自动 provisioning——该文件先声明 LGTM 自带的 RED Metricsclassic 与 native 直方图与 JVM Metrics 仪表盘随后声明三个 Hindsight 仪表盘foldersFromFilesStructure: false全部放在根目录。分布式追踪Hindsight 支持针对记忆操作与 LLM 调用的 OpenTelemetry 分布式追踪遵循 GenAI 语义约定 v1.37。追踪由 tracing.py 实现默认关闭与DEFAULT_OTEL_TRACES_ENABLED False对应见 config.py启用时通过 OTLP HTTP 导出器导出到任意兼容后端。配置环境变量见 Configuration - OpenTelemetry Tracing表格摘录环境变量说明默认值HINDSIGHT_API_OTEL_TRACES_ENABLED为 LLM 调用启用分布式追踪falseHINDSIGHT_API_OTEL_EXPORTER_OTLP_ENDPOINTOTLP 端点 URL如 Grafana LGTM、Langfuse 等-HINDSIGHT_API_OTEL_EXPORTER_OTLP_HEADERSOTLP 导出器请求头格式key1value1,key2value2-HINDSIGHT_API_OTEL_SERVICE_NAME追踪的服务名。适用于 API 与独立 worker——未设置时 worker 默认上报为hindsight-workerhindsight-apiHINDSIGHT_API_OTEL_DEPLOYMENT_ENVIRONMENT部署环境名如 development、staging、productiondevelopment快速开始# 启用追踪 export HINDSIGHT_API_OTEL_TRACES_ENABLEDtrue export HINDSIGHT_API_OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318 # 使用 Grafana LGTM 查看追踪本地开发 ./scripts/dev/start-monitoring.sh # 打开 http://localhost:3000 → Explore → Tempo支持任何 OTLP 兼容后端Grafana LGTM、Langfuse、OpenLIT、DataDog、New Relic、Honeycomb、Pydantic Logfire 等。从实现细节看initialize_tracing() 会自动为不以/v1/traces结尾的端点补上该路径后缀解析key1value1,key2value2格式的请求头并使用BatchSpanProcessor批量导出initialize_tracing_from_config()保证 APIFastAPI 生命周期与独立 worker 两个进程入口走同一套初始化逻辑让设置了HINDSIGHT_API_OTEL_*的部署能从每个干活的进程拿到追踪issue #3614且初始化失败只记录日志、绝不让进程无法启动——tracing 绝不能阻碍进程启动。shutdown_tracing()会强制冲刷BatchSpanProcessor避免进程退出时丢弃仍在队列中的 span——这对单条合并 span 可能长达数分钟的 worker 尤其重要。Span 层级父 Span操作hindsight.retain- 记忆摄取hindsight.recall- 记忆检索hindsight.recall_embedding- 查询嵌入hindsight.recall_retrieval- 并行搜索语义、BM25、图、时间hindsight.recall_fusion- 倒数排名融合RRFhindsight.recall_rerank- 交叉编码器重排hindsight.reflect- 智能体推理hindsight.reflect_tool_call- 工具执行recall、lookup 等hindsight.consolidation- 观察综合hindsight.mental_model_refresh- 心智模型更新子 SpanLLM 调用按 scope 命名如hindsight.memory、hindsight.reflect以事件形式包含完整提示词/补全属性遵循 GenAI 语义约定父操作 span 由 create_operation_span() 创建命名规则为hindsight.{operation}并设置hindsight.operation与hindsight.bank_id属性。LLM 子 span 由LLMSpanRecorder.record_llm_call()在调用完成后以显式时间戳创建end_on_exitFalse 手动span.end()以适配现有的同步指标记录模式。Span 属性操作 Spanhindsight.operation- 操作类型hindsight.bank_id- 记忆银行 IDhindsight.query- 查询文本截断到 100 字符hindsight.fact_types- recall 的事实类型hindsight.thinking_budget- 预算分配hindsight.max_tokens- token 上限LLM SpanGenAI 语义约定gen_ai.operation.name- 恒为chatgen_ai.provider.name- 提供商openai、anthropic、google等gen_ai.request.model- 模型名gen_ai.usage.input_tokens- 输入 tokengen_ai.usage.output_tokens- 输出 tokenhindsight.scope- LLM 调用用途memory、reflect、consolidation等事件gen_ai.client.inference.operation.details- 完整提示词与补全在实现中提供商名通过PROVIDER_NAME_MAPPING映射为 GenAI 语义约定的值如gemini→google、openai-codex→openai消息以 JSON 数组写入事件属性超长内容截断到MAX_CONTENT_LENGTH 100_000字符并附截断说明工具调用会记录gen_ai.tool_calls.count/gen_ai.tool_calls.names属性与逐条gen_ai.tool_call.{i}事件出错时设置错误状态、error.type属性并调用record_exception。此外CompositeSpanRecorder会把同一 LLM 调用扇出给所有注册的 recorder如 OpenTelemetry span 导出器与按银行落库的 DB tracer单个 recorder 失败绝不影响其他 recorder 与 LLM 调用本身。追踪上下文传播Hindsight 会融入你已有的追踪而不是另起一套并行的追踪。当调用方发送 W3C 追踪上下文标准的traceparent头大多数 OpenTelemetry HTTP 客户端插桩都会自动添加时Hindsight 会继续该追踪API 请求作为调用方下的一个 server span 出现其触发的每个记忆操作与 LLM 调用都嵌套在其下。没有携带追踪上下文的请求仍然会开启自己的追踪因此未插桩的调用方行为不变。健康与指标端点被排除在追踪之外这样探针流量不会淹没真正的工作。可通过OTEL_PYTHON_FASTAPI_EXCLUDED_URLS设置为逗号分隔的 URL 模式列表来覆盖此行为默认值为health,metrics见 configuration.md。值得一提的实现细节是异步任务队列与追踪的打通inject_task_trace_context()会把当前 W3C traceparent 写入任务 payload键为_traceparentworker 侧再由extract_task_trace_context()重建出队时请求的追踪上下文并包裹任务执行——否则 API 的 enqueue span 与 worker 的hindsight.retainspan 就是两条互不相干的追踪API 那半条里只有入队动作。Worker 进程独立 worker 进程遵循与 API 相同的HINDSIGHT_API_OTEL_*变量并导出自己的 span。这对部署了专用 worker 的环境很重要因为合并、后台 retain 与心智模型刷新——大部分长时工作与 token 开销——都发生在那里。为 worker 设置独立的HINDSIGHT_API_OTEL_SERVICE_NAME以便在追踪后端中将其与 API 区分。未设置时worker 默认上报为hindsight-worker。worker 的 span 目前是独立的追踪后台操作不会链接到将其入队的请求因为它在该请求返回后很久才执行。小结把本文的要点压缩成一份可操作的核对清单本地开发./scripts/dev/start-monitoring.sh一条命令拉起 Grafana LGTM通过HINDSIGHT_API_OTEL_TRACES_ENABLEDtrueHINDSIGHT_API_OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4318启用追踪健康探针liveness 永远指向/health/live零 I/Oreadiness 指向/healthSELECT 1检查数据库seconds_since_last_poll只用于告警、永不改变状态码指标告警no_facts占比告警监控 retain mission 过度排除failure_classfail_fast告警捕获 schema 拒绝导致的静默清理失效hindsight.operation.total{sourceworker,successfalse}与hindsight_async_operations{statusfailed}组合使用以获得权威的异步失败追踪API 与 worker 共用一套HINDSIGHT_API_OTEL_*配置为 worker 单独命名服务以区分生产环境务必调用shutdown_tracing()冲刷 span避免丢失长 span。仓库中的三个仪表盘 JSON、prometheus.yml抓取模板与 Helm 探针配置都可以直接作为生产部署的起点。【免费下载链接】hindsightHindsight: Agent Memory That Learns项目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考