可观测性（从系统外部输出理解系统正在做什么的能力）已经从事后考虑演变为生产工程的核心部分。以下是当前实践状态以及真正重要的事情。
三大支柱
日志：单个事件的结构化记录——发生了什么、何时发生，以及与之关联的数据。关键原则：结构化日志记录（JSON输出）而非纯文本现在是生产系统的默认选项。结构化日志是可查询的；纯文本不是。日志条目应包含：时间戳、日志级别（DEBUG/INFO/WARN/ERROR）、服务名称、请求ID、用户ID（如适用）和事件数据。反模式：过于详细的日志记录（在生产中记录每个SQL查询）产生成本而没有洞察力；日志记录过少意味着你无法调试生产问题。实际级别：INFO用于重要事件（接收到请求、下单）、WARN用于可恢复问题（重试成功）、ERROR用于不可恢复失败（付款失败）。指标：随时间变化的数值测量——请求率、错误率、延迟百分位数、资源使用。关键洞察：指标在规模上存储和处理成本低廉；它们能快速回答”是否有什么不对劲？”。标准指标：请求率（每秒请求数）、错误率（返回5xx的请求百分比）、延迟（p50、p95、p99——不是平均值，它隐藏了异常值），以及饱和度（你是否接近容量？）。这四个（通常称为RED指标——速率、错误、持续时间——和USE——利用率、饱和度、错误）涵盖了任何服务的基础。追踪：请求通过分布式系统路径的记录，显示它经过了哪些服务、每个服务花了多长时间以及错误发生在哪里。微服务的关键工具：当请求在通过8个服务后失败时，追踪告诉你哪个服务导致了失败以及每个步骤花了多长时间。OpenTelemetry现在是标准：一个供应商中立的SDK，用于从应用程序收集和导出追踪、指标和日志。
2026年的工具栈
对于中小型组织，最实用的栈：Grafana（仪表板和可视化，免费开源）+ Prometheus（指标收集和存储，开源）+ Loki（日志聚合，Grafana的日志产品）+ Tempo（分布式追踪，Grafana的追踪产品）。这个”Grafana栈”是生产级别的，有活跃的开源社区，避免了专有锁定。云原生替代方案：AWS CloudWatch + X-Ray、Google Cloud Monitoring + Trace、Azure Monitor + Application Insights——与各自的云提供商集成，设置更省力，但专有且在规模上可能昂贵。商业可观测性平台（Datadog、New Relic、Honeycomb、Dynatrace）：增加自动异常检测、AI辅助故障排除和更好的用户界面等功能，但成本显著。Datadog在标准定价下每主机每月约23美元——对于50台主机的机群，每月1,150美元。在规模上，可观测性成本管理本身成为一门学科。
实践中真正重要的事情
一开始就进行仪器化：将可观测性添加到现有系统比从一开始就构建它更难。在项目开始时添加OpenTelemetry SDK；从第一天起就添加结构化日志记录。SLO优先于仪表板：服务级别目标（SLO）是你服务可靠性的目标（”99.9%的请求在200毫秒内成功”）。在构建仪表板之前定义SLO，使你专注于重要的事情，而不是有趣的事情。值班手册：每个警报都应该有一个运行手册——描述警报含义以及解决它的步骤的文档。没有运行手册的警报是噪音。警报疲劳：太多警报=工程师学会忽视它们。只对需要人工操作的事情发出警报；使用基于SLO的警报（当你的错误预算快速消耗时发出警报）而不是简单的阈值警报（当错误率>1%时发出警报——太嘈杂）。关联：可观测性的价值在于能够将指标异常与解释它的追踪和日志相关联。链接日志和追踪的请求ID是基本机制。
