| authors | reviewers | ||
|---|---|---|---|
|
|
面对复杂的应用环境和不断扩展的业务需求，即使再完备的测试也难以覆盖所有场景，无法保证服务不会出现故障。正因为如此，才需要“可观察性”来对服务的运行时状态进行监控、上报、分析，以提高服务可靠性。具有可观察性的系统，可以在服务出现故障时大大降低问题定位的难度，甚至可以在出现问题之前及时发现问题以降低风险。具体来说，可观察性可以：
- 及时反馈异常或者风险使得开发人员可以及时关注、修复和解决问题（告警）；
- 出现问题时，能够帮助快速定位问题根源并解决问题，以减少服务损失（减损）；
- 收集并分析数据，以帮助开发人员不断调整和改善服务（持续优化）。
而在微服务治理之中，随着服务数量大大增加，服务拓扑不断复杂化，可观察性更是至关重要。Istio 自然也不可能缺少对可观察性的支持。它会为所有的服务间通信生成详细的遥测数据，使得网格中每个服务请求都可以被观察和跟踪。开发人员可以凭此定位故障，维护和优化相关服务。而且，这一特性的引入无需侵入被观察的服务。
Istio 一共提供了三种不同类型的数据从不同的角度支撑起其可观察性：
-
指标（Metrics）：指标本质上是时间序列上的一系列具有特定名称的计数器的组合，不同计数器用于表征系统中的不同状态并将之数值化。通过数据聚合之后，指标可以用于查看一段时间范围内系统状态的变化情况甚至预测未来一段时间系统的行为。举一个简单的例子，系统可以使用一个计数器来对所有请求进行计数，并且周期性（周期越短，实时性越好，开销越大）的将该数值输出到时间序列数据库（比如 Prometheus）中，由此得到的一组数值通过数学处理之后，可以直观的展示系统中单位时间内的请求数及其变化趋势，可以用于实时监控系统中流量大小并预测未来流量趋势。而具体到 Istio 中，它基于四类不同的监控标识（响应延迟、流量大小、错误数量、饱和度）生成了一系列观测不同服务的监控指标，用于记录和展示网格中服务状态。除此以外，它还提供了一组默认的基于上述指标的网格监控仪表板，对指标数据进行聚合和可视化。借助指标，开发人员可以快速的了解当前网格中流量大小、是否频繁的出现异常响应、性能是否符合预期等等关键状态。但是，如前所述，指标本质上是计数器的组合和系统状态的数值化表示，所以往往缺失细节内容，它是从一个相对宏观的角度来展现整个网格或者系统状态随时间发生的变化及趋势。在一些情况下，指标也可以辅助定位问题。
-
日志（Access Logs）：日志是软件系统中记录软件执行状态及内部事件最为常用也最为有效的工具。而在可观测性的语境之下，日志是具有相对固定结构的一段文本或者二进制数据（区别于运行时日志），并且和系统中需要关注的事件一一对应。当系统中发生一个新的事件，指标只会有几个相关的计数器自增，而日志则会记录下该事件具体的上下文。因此，日志包含了系统状态更多的细节部分。在分布式系统中，日志是定位复杂问题的关键手段；同时，由于每个事件都会产生一条对应的日志，所以日志也往往被用于计费系统，作为数据源。其相对固定的结构，也提供了日志解析和快速搜索的可能，对接 ELK 等日志分析系统后，可以快速的筛选出具有特定特征的日志以分析系统中某些特定的或者需要关注的事件。在 Istio 网格中，当请求流入到网格中任何一个服务时，Istio 都会生成该请求的完整记录，包括请求源和请求目标以及请求本身的元数据等等。日志使网格开发人员可以在单个服务实例级别观察和审计流经该实例的所有流量。
-
分布式追踪（Distributed Traces）：尽管日志记录了各个事件的细节，可在分布式系统中，日志仍旧存在不足之处。日志记录的事件是孤立的，但是在实际的分布式系统中，不同组件中发生的事件往往存在因果关系。举例来说，组件 A 接收外部请求之后，会调用组件 B，而组件 B 会继续调用组件 C。在组件 A B C 中，分别有一个事件发生并各产生一条日志。但是三条日志没有将三个事件的因果关系记录下来。而分布式追踪正是为了解决该问题而存在。分布式追踪通过额外数据（Span ID等特殊标记）记录不同组件中事件之间的关联，并由外部数据分析系统重新构造出事件的完整事件链路以及因果关系。在服务网格的一次请求之中，Istio 会为途径的所有服务生成分布式追踪数据并上报，通过 Zipkin 等追踪系统重构服务调用链，开发人员可以借此了解网格内服务的依赖和调用流程，构建整个网格的服务拓扑。在未发生故障时，可以借此分析网格性能瓶颈或热点服务；而在发生故障时，则可以通过分布式追踪快速定位故障点。
本节内容仅仅简单介绍了 Istio 中可观察性的相关概念，而未深入具体的细节，希望都能能够凭此建立起对可观察性初步的印象。更加详细的相关内容将在本书的实践篇介绍。