引言
我们将会学习关于可观测性的一些知识，坐好，心沉淀下来。
本篇将会分享超过 20 个常见的关于可观测性的常见问题，你准备好了吗？
我们开始了.
开始
1. 什么是可观测性？
可观测性是指能够通过
系统的外部输出（如日志、指标、追踪）推断出系统内部状态的能力。它帮助工程师理解系统的行为，快速定位故障并进行调优。可观测性通常包括以下三个主要方面：日志（Logging）：记录事件和系统状态信息，用于调试和排查问题。指标（Metrics）：定期收集的系统运行数据，用于分析性能、负载和资源使用情况。追踪（Tracing）：跟踪请求或事务在系统中的流动，帮助分析性能瓶颈和系统间的依赖关系。
2. 日志、指标和追踪的区别是什么？
日志：记录系统事件的详细信息，通常是文本格式，包含错误、警告、信息等类型。适合用来进行故障排查和事件审计。指标：定期收集的数字数据，通常以时间序列的方式呈现，用于分析系统健康和性能，像是 CPU 使用率、内存使用情况等。追踪：通过在请求或事务流中插入追踪信息来监控它们的路径，帮助理解服务间的依赖关系、延迟和性能瓶颈。
3. 什么是日志聚合工具，举例说明？
日志聚合工具用于收集和集中存储来自不同服务或组件的日志，帮助用户进行统一管理和分析。常见的日志聚合工具有：
ELK Stack（Elasticsearch, Logstash, Kibana）：Logstash 用于收集和解析日志，Elasticsearch 用于存储和查询，Kibana 用于可视化。Fluentd：一个用于收集和转发日志的开源工具，通常与 Elasticsearch 和其他存储工具结合使用。Graylog：一个开源日志管理平台，支持日志聚合、存储、搜索和可视化。
4. 你如何监控和收集指标？
通常使用以下工具来监控和收集系统的指标：
Prometheus：一个开源的监控和报警系统，专注于时序数据的收集和查询。Prometheus 通过抓取配置好的目标的暴露的指标端点来收集数据。Grafana：与 Prometheus 或其他监控系统结合使用，用于可视化监控数据，展示图表和仪表盘。CloudWatch（AWS）：AWS 提供的云原生监控服务，用于收集、监控和可视化 AWS 资源及应用程序指标。
5. 你如何实现分布式追踪？
分布式追踪
用于跟踪跨多个微服务的请求流动，帮助我们理解请求的延迟和依赖关系。常见的实现分布式追踪的工具有：Jaeger：一个开源的分布式追踪系统，可以追踪请求在不同服务中的路径，并提供相关的性能数据。Zipkin：另一个开源的分布式追踪系统，提供端到端的请求追踪，帮助识别瓶颈。OpenTelemetry：一个开源的可观测性框架，提供多种 API 和 SDK 用于收集日志、指标和追踪数据，支持与多个后端集成。
6. 如何处理和响应系统报警？
报警是可观测性的一个重要组成部分，能够及时提醒运维人员或开发者关注系统异常。报警可以基于以下内容设置：
阈值报警：当某个指标超过预定义的阈值时触发报警（如 CPU 使用率超过 80%）。异常检测：基于机器学习和历史数据，自动检测异常行为并触发报警。智能报警：结合不同的系统状态（如日志、指标、追踪）和上下文，制定更智能的报警规则，避免噪声报警。
工具：
Prometheus Alertmanager：与 Prometheus 配合，自动发送报警通知。CloudWatch Alarms：AWS 的报警系统，根据 CloudWatch 中的指标设置报警。PagerDuty：一个用于接收和管理报警的自动化系统，能帮助及时响应和解决问题。
7. 什么是“服务级别指标”（SLI）和“服务级别目标”（SLO）？
SLI（Service Level Indicator，服务级别指标）：衡量服务性能的关键指标，如请求成功率、响应时间等。SLI 是对服务质量的定量衡量。SLO（Service Level Objective，服务级别目标）：定义服务期望达到的水平或目标。例如，要求 99.9% 的请求在 1 秒内完成处理，SLO 是对 SLI 的目标值设定。
8. 在微服务架构中，如何实现有效的可观测性？
在微服务架构中，由于服务之间的高度耦合和分布式部署，实施可观测性非常重要。实现有效的可观测性包括：
集中化日志管理：使用日志聚合工具（如 ELK Stack 或 Fluentd）收集和分析各微服务的日志，便于排查问题。统一的指标监控：使用 Prometheus 或类似工具来收集所有服务的指标，进行资源监控和性能分析。分布式追踪：集成 Jaeger 或 Zipkin 等工具，跟踪跨服务的请求流，分析延迟、瓶颈及依赖关系。报警与自动化：设置合适的报警阈值，结合自动化工具来处理报警，确保及时响应和解决问题。
9. 你如何确保报警不会产生过多的噪声？
过多的噪声报警会导致警报疲劳，影响响应效率。可以采取以下措施：
避免冗余报警：配置报警规则时，避免重复触发同一个问题，利用合并和去重功能减少不必要的报警。基于业务和关键指标的报警：将报警焦点放在对业务最重要的指标上，而不是所有可能出现的异常。报警抑制和智能报警：根据历史数据和系统状态，利用机器学习算法检测异常而非每次波动都报警。
10. 什么是指标的“高水位”和“低水位”？它们如何影响报警规则？
高水位和低水位通常用于设置报警阈值。
高水位：指标值超过此阈值时触发报警。例如，CPU 使用率超过 90%。低水位：指标值低于此阈值时触发报警。例如，服务请求数低于预期的最低值，表示可能存在服务故障。
使用高水位和低水位可以帮助确定系统资源瓶颈和服务故障，同时避免过度的报警和无意义的警告。
11. 什么是可观测性（Observability）？与监控（Monitoring）有何区别？
可观测性是通过系统的输出来推断其内部状态的能力，核心目标是理解复杂系统的未知问题。它依赖三大支柱：日志（Logs）、指标（Metrics）和追踪（Traces）。
与监控的区别：
监控：聚焦于已知问题（如预设阈值告警）。可观测性：用于诊断未知问题，提供上下文（如为什么 CPU 使用率高）。
12.解释可观测性的三大支柱（Logs, Metrics, Traces）及其作用
日志（Logs）：离散事件记录，用于记录系统行为的原始信息（如错误堆栈）。指标（Metrics）：聚合的时间序列数据，反映系统状态（如请求速率、错误率）。追踪（Traces）：记录请求在分布式系统中的端到端路径，帮助定位延迟或故障点。
13.你用过哪些可观测性工具？举例说明它们的适用场景
Prometheus：适合指标收集与告警（如监控 Kubernetes 集群资源）。Grafana：可视化工具，可聚合多数据源（如展示 Prometheus + Loki 的仪表盘）。ELK Stack（Elasticsearch, Logstash, Kibana）：日志管理与分析（如排查服务错误日志）。Jaeger/Zipkin：分布式追踪（如分析微服务链路延迟）。OpenTelemetry：统一的观测数据采集标准（跨语言、跨工具集成）。
14.如何在微服务架构中实现分布式追踪？
注入上下文：通过唯一 Trace ID和Span ID 标记请求。传播上下文：在 HTTP Headers 或消息队列中传递 ID（如使用W3C Trace Context）。工具集成：使用 Jaeger、Zipkin 或 OpenTelemetry 收集和关联数据。可视化分析：通过工具查看链路耗时、错误和依赖关系。
15.如何设计有效的告警策略？
分层告警：按严重性分级（如 P0-P3），避免告警疲劳。基于 SLO 告警：围绕服务目标（如 99.9% 可用性）触发告警。动态阈值：使用机器学习（如 Prometheus 的 holt_winters）适应流量波动。告警静默：在已知维护时段静默非关键告警。
16.如何排查一个 API 的高延迟问题？
检查指标：查看请求延迟分位数（如 p99）、CPU/内存使用率。追踪分析：找到链路中最慢的 Span（如数据库查询或外部 API 调用）。日志关联：通过 Trace ID 过滤相关日志，定位错误或慢查询。资源瓶颈：检查是否达到资源限制（如连接池耗尽、磁盘 IO 高）。
17.日志量过大导致存储成本高，如何优化？
采样（Sampling）：对低优先级日志按比例采样（如仅 10% 的 DEBUG 日志）。分级存储：热数据存 SSD，冷数据转存对象存储（如 S3）。结构化日志：使用 JSON 格式，便于过滤和压缩。生命周期策略：自动删除过期日志（如保留 7 天）。
18.解释 OpenTelemetry 的核心组件及其优势
组件：
API：提供语言无关的观测数据生成接口。SDK：实现 API，处理数据采样、导出等逻辑。Collector：统一接收、处理和导出数据（如转存到 Prometheus/Jaeger）。优势： 标准化观测数据格式，避免厂商锁定；支持多语言和工具集成。
19.什么是 Exemplars？它们在可观测性中的作用是什么？
Exemplars 是关联指标与追踪的元数据（如将高延迟指标关联到具体的 Trace ID）。作用：
快速从指标跳转到具体请求的追踪详情。
适用于 Prometheus 等支持 Exemplars 的工具。
20.如何设计一个高可用的可观测性系统？
数据冗余：多副本存储（如 Elasticsearch 集群）。负载均衡：通过 Collector 横向扩展处理流量。降级策略：在数据洪峰时丢弃低优先级数据（如非生产环境日志）。去中心化：避免单点故障（如 Prometheus 的联邦集群）。
21. 如果团队不重视可观测性，你会如何推动改进？
量化价值：展示故障排查时间减少、MTTR 降低的数据。低成本试点：从小规模集成（如关键服务加 Tracing）。培训与文档：分享案例和最佳实践，提升团队认知。
22.举一个你通过可观测性工具解决复杂问题的案例（这边随便给大家一个例子）
案例背景：
我曾在一个微服务架构中工作，系统中有多个服务与数据库交互，提供实时数据处理。随着流量的增加，用户开始报告应用出现延迟，某些请求的响应时间较长，甚至有时会出现超时错误。团队试图定位问题，但由于微服务架构的复杂性，难以通过传统的日志或监控手段迅速找出根本原因。
解决方案：
我们决定使用 可观测性工具 来全面诊断和排查问题，以下是具体步骤：
1. 集成分布式追踪
我们首先使用了 Jaeger，一个开源的分布式追踪工具，来追踪跨服务的请求流动。
在所有微服务中集成了 Jaeger 客户端，并确保所有的请求（特别是慢请求）都能够记录追踪信息。这包括了每个服务的入口、处理逻辑和调用的下游服务。
目标：我们想通过追踪信息找出在哪个服务或调用链中发生了延迟。
2. 设置并查看服务依赖图
利用 Jaeger 收集的数据，我们可以生成服务间的依赖图。这帮助我们直观地看到服务之间的调用链条，识别瓶颈或异常的调用模式。
在查看依赖图后，我们发现某些服务的响应时间异常长，尤其是与数据库交互的服务请求。
3. 结合指标监控分析性能
同时，我们使用 Prometheus 收集系统的实时指标，特别是 CPU 使用率、内存使用情况、数据库连接池的大小、服务的请求数和延迟等。
我们通过 Grafana 将这些指标可视化，并设定了针对关键指标的阈值报警。通过监控仪表盘，我们发现某个特定的数据库服务在高流量时出现了 连接池满 的现象，导致新的请求被阻塞。
4. 深入排查数据库瓶颈
根据追踪和指标，我们锁定了数据库连接池的问题。由于数据库的连接数设置不合理，流量激增时，服务的请求无法及时获得数据库连接，从而导致了请求的延迟。
通过增加数据库连接池的大小，并优化数据库查询性能，解决了瓶颈。
5. 日志分析
在此过程中，我们还利用了 ELK Stack（Elasticsearch、Logstash 和 Kibana）对相关服务的日志进行分析。
日志帮助我们进一步确认了数据库请求的失败模式，并找到了错误的具体原因和堆栈信息。
结果：
通过集成 Jaeger 进行分布式追踪，我们能够快速识别请求延迟的根源，并结合 Prometheus 和 Grafana 的监控指标确定了数据库连接池问题。最后，通过优化数据库配置，延迟问题得到了解决。
总结： 使用可观测性工具（Jaeger、Prometheus、Grafana 和 ELK Stack）帮助我们全面了解了系统的运行状态和服务之间的交互，从而定位了复杂问题的根本原因。通过这种方式，我们提高了系统的可观察性，并能够及时响应和解决潜在的瓶颈问题。
结语
经过上面的一番折腾，对于面试这种情况，可观测性领域你算是明白了，但是这只是个开始，Kepp Going