监控和可观察性经常被混为一谈，但实际上是不同的——监控告诉你什么时候出了问题，可观察性告诉你为什么。两者对于生产系统都是必不可少的。以下是对三大支柱的清晰解释。
日志
日志是你系统中发生的事件的不可变、带时间戳的记录。每个Web请求、错误、用户操作和内部状态变化都产生日志条目。挑战：高容量系统每小时产生数百万条日志行，找到相关的需要结构化日志记录（JSON格式，一致的字段名：user_id、request_id、action）而非非结构化文本字符串。工具：使用Elasticsearch/Kibana（ELK堆栈）、Loki + Grafana或Datadog日志、Sumo Logic、Papertrail等托管服务的集中式日志记录。
指标
指标是随时间的数值测量——请求速率、错误率、延迟百分位数（p50、p95、p99）、队列深度、CPU/内存使用率。与日志（记录单个事件）不同，指标聚合模式。关键指标框架是资源的USE方法（利用率、饱和度、错误）和服务的RED方法（速率、错误、持续时间）。Prometheus（开源）配Grafana仪表板是指标的主流技术栈；替代方案包括Datadog、New Relic和InfluxDB。
追踪
分布式追踪跟踪一个请求在多个服务中移动——从前端HTTP请求通过API网关、到服务A、数据库查询、服务B、再返回。每个步骤是一个带时间的”跨度”（span）；一个请求的所有跨度的集合是一个”追踪”（trace）。追踪对于微服务是必不可少的，在那里用户投诉（”我的结账很慢”）需要在5到10个服务中调试。OpenTelemetry（开放标准）配Jaeger或Tempo是当前的最佳实践；Datadog APM和New Relic是托管替代方案。
实际最小配置
对于小团队：结构化日志记录到中央存储（Papertrail免费版，或自托管时使用Loki）、来自你的应用框架的请求速率和错误率指标（大多数会自动暴露这些），以及正常运行时间监控（UptimeRobot，免费），当你的服务无法访问时发出警告。只有当跨服务延迟调试成为反复出现的问题时，才添加分布式追踪。
