2.3　可观察性

面对复杂的应用环境和不断扩展的业务需求，即使再完备的测试也难以覆盖所有场景，无法保证服务不会出现故障。因此，系统才需要“可观察性”，对服务的运行时状态进行监控、上报、分析，以提高服务可靠性。具有可观察性的系统，可以在服务出现故障时大大降低问题定位的难度，甚至可以在出现问题之前及时发现问题以降低风险。具体来说，可观察性可以做到以下3点。

•及时反馈异常或风险，使得开发人员可以及时关注、修复和解决问题（告警）。

•在出现问题时，能够快速定位问题根源并解决问题，以减少服务损失（减损）。

•收集并分析数据，以帮助开发人员不断调整和改善服务（持续优化）。

在微服务治理中，随着服务数量大大增加，服务拓扑日益复杂，可观察性也越来越重要。Istio自然也不可能缺少对可观察性的支持。它会为所有的服务间通信生成详细的遥测数据，使得网格中每个服务请求都可以被观察和跟踪。开发人员可以凭此定位故障，维护和优化相关服务。而且，这一特性的引入无须侵入被观察的服务。

Istio一共提供了3种不同类型的数据，从不同的角度支持可观察性。

•指标（Metrics）：指标本质上是时间序列上的一系列具有特定名称的计数器的组合。不同计数器用于表征系统中的不同状态并将之数值化。完成数据聚合之后，指标可以用于查看一段时间内系统状态的变化情况，甚至预测未来一段时间内系统的行为。例如，系统可以使用一个计数器对所有请求进行计数，并且周期性（周期越短，实时性越好，开销越大）地将该数值输出到时间序列数据库（如Prometheus）中。由此得到的一组数值，经过数据处理，可以直观地展示系统中单位时间内的请求数及其变化趋势，也可以用于实时监控系统中的流量大小并预测未来的流量趋势。而具体到Istio中，指标基于4类不同的监控标识（响应延迟、流量大小、错误数量和饱和度）生成了一系列观测不同服务的监控指标，用于记录和展示网格中的服务状态。除此之外，它还提供了一组默认的基于上述指标的网格监控仪表板，对指标数据进行聚合和可视化。借助指标，开发人员可以快速了解当前网格中流量大小、是否频繁地出现异常响应、性能是否符合预期等关键状态。但是，如前所述，指标本质上是计数器的组合和系统状态的数值化表示，所以往往缺失细节内容，是从一个相对宏观的角度来展现整个网格或系统状态随时间发生的变化及趋势的。在一些情况下，指标也可以辅助定位问题。

•日志（Access Logs）：日志是软件系统中记录软件执行状态及内部事件最常用、有效的工具。在可观测性的语境之下，日志是具有相对固定结构的一段文本或二进制数据（区别于运行时日志），并且和系统中需要关注的事件一一对应。当系统中发生一个新的事件时，指标只会进行几个相关的计数器自增，而日志则会记录该事件具体的上下文。因此，日志包含了系统状态更多的细节部分。在分布式系统中，日志是定位复杂问题的关键手段。同时，由于每个事件都会产生一条对应的日志，因此日志往往作为数据源被用于计费系统。其相对固定的结构，为开发人员提供了日志解析和快速搜索的可能，开发人员在对接ELK等日志分析系统后，可以快速地筛选出具有特定特征的日志，以分析系统中某些特定的或需要关注的事件。在Istio 网格中，当请求流入网格的任何一个服务中时，Istio都会生成该请求的完整记录，包括请求源、请求目标，以及请求本身的元数据等。日志使网格开发人员可以在单个服务实例级别中观察和审计流经该实例的所有流量。

•分布式追踪（Distributed Traces）：尽管日志记录了各个事件的细节，但是在分布式系统中，日志仍然存在不足之处。虽然日志记录的事件是孤立的，但是在实际的分布式系统中，不同组件中发生的事件往往存在因果关系。例如，组件A接收外部请求之后，会调用组件B，而组件B会继续调用组件C。在组件A、B、C中，分别有一个事件发生，还各自产生了一条日志，但是3条日志并没有将3个事件的因果关系记录下来。分布式追踪正是为了解决该问题而存在的。分布式追踪通过额外数据（Span ID等特殊标记）记录不同组件中事件之间的关联，并由外部数据分析系统重新构造出事件的完整事件链路及因果关系。在服务网格的一次请求中，Istio会为途径的所有服务生成分布式追踪数据并上报。通过Zipkin等追踪系统重构服务调用链，开发人员可以借此了解网格内服务的依赖关系和调用流程，构建整个网格的服务拓扑。在未发生故障时，可以借此分析网格性能瓶颈或热点服务；而在发生故障时，则可以通过分布式追踪快速定位故障点。

本节只简单介绍了Istio中可观察性的相关概念，而未深入讲解具体的细节，希望读者能够基于这些建立起对可观察性的初步印象。