日志与可观测性

配置日志、指标、Prometheus、Top、诊断与 Debug 的边界和成本。

先建立能回答“哪个节点、何时、哪个资源或队列发生变化”的基础观察面，再增加高成本诊断。观察能力本身也消耗 CPU、内存、磁盘与网络，并可能暴露拓扑或请求信息。

能力分层

能力	配置分区	作用	暴露边界
日志	`[log]`	级别、格式、控制台、滚动文件	集中采集，限制保留和读取
Prometheus 指标	`[observability]`	控制 `/metrics` 是否可用	仅采集网络，不对公网开放
Prometheus 服务	`[prometheus]`	可选应用托管子进程或外部查询地址	与节点生命周期和容量分开规划
Top	`[top]`	有界历史的实时节点快照	管理网络，限制调用方
诊断采样	`[diagnostics]`	缓冲、普通/错误/深度采样与慢阈值	按成本逐步提升并设置到期时间
Debug/pprof	`observability.debug_api_enable`	高成本进程诊断	默认关闭，只临时开放给授权人员

生产日志应使用可解析格式，包含节点身份和时间，并集中采集。log.max_size、max_age、max_backups 与 compress 共同限制本地占用；仍需为日志目录设置磁盘告警，避免日志与消息数据相互挤压。

提高到 debug 前评估写入量、敏感信息和性能成本。完成诊断后恢复原级别，并保留变更人、时间范围和关联事件。

启用节点指标：

[observability]
metrics_enable = true
debug_api_enable = false

prometheus.enable = true 会启动应用托管的 Prometheus 子进程；已有独立 Prometheus 时保持为 false，使用 prometheus.query_base_url 让 Manager 查询外部服务。不要同时把两种模式当成同一个所有权模型。

仓库示例为本地应用托管模式预留 127.0.0.1:9099，只是避免常见端口冲突的开发样例，不是生产监听或保留策略。生产采集目标、TSDB 目录、保留时间/容量、抓取间隔和高可用由观察平台负责人确定。

负载均衡器继续使用 /readyz 进行准入；/metrics 和日志用于解释为何未就绪，但不能代替就绪门槛。

Top 的采集间隔和历史窗口形成内存与采样成本。诊断的 buffer_size、采样率、慢阈值、深度采样与调试匹配项需要从低成本开始；大流量和十万成员群组下，过高采样可能放大 CPU、内存与锁竞争。

pprof 仅在 debug_api_enable = true 时开放。临时开启时应限制来源、记录开始/结束时间、设置抓取上限，并在完成后关闭。诊断制品即使经过字段脱敏，也应按内部敏感数据存储和共享。

继续阅读健康检查与监控建立告警边界；上线前还需完成生产检查清单。