这些是可观测性的三大支柱。它们回答不同的问题:指标告诉你存在问题,日志告诉你发生了什么,追踪告诉你在分布式流中哪里消耗了时间或出现了错误。
三大支柱
text
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
指标将问题范围缩小到一个症状和时间窗口;追踪将其定位到某个服务或调用;日志提供确切原因。不通过指标而直接查看日志就像盲目搜索。
指标是聚合的,即使在大规模情况下也保持成本低廉——非常适合始终开启的仪表板和告警。日志和追踪是按事件计费且成本昂贵的,因此通常会被采样,并在调查期间按需查询。
使用错误的支柱会浪费时间:你无法在原始日志上有效地设置告警(噪音太多,成本太高),也无法从聚合的指标来调试某个特定失败的请求。了解指标用于检测、追踪用于定位、日志用于解释,可以让你从"出问题了"快速、可重复地找到根本原因。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠