简介
软件系统的性质异常复杂，因此在这些系统中发生故障是不可避免的。与试图在不发生故障的前提下使系统完美相比，更为实际的方法是采取必要措施，在故障发生后及时作出响应并解决问题，因为前者无比困难且昂贵。术语"可观测性"并非由软件开发人员新创的词汇。
"可观测性"是一个源自"控制理论"的术语，用于描述通过检查系统的外部输出来推断系统内部状态的系统属性。
同样的定义也可以应用在企业软件系统中。在这种系统中，我们利用以下外部输出来推断系统内部状态：
- 日志
- 指标
- 跟踪
日志是记录企业应用程序输出的最常见方式。这些日志通常被存储在文件中，一段时间后轮换以保持一定的存储期限。
指标则是与应用程序行为相关的统计信息。
而跟踪则非常有助于深入了解系统在细粒度级别上发生的情况。通常，这些跟踪记录了系统中每条消息的传递情况。
实施可观测性
通常情况下，开发人员并未给予实施可观测性足够的关注，因为这需要在开发阶段投入额外的工作。受限于时间压力和其他各种挑战，他们常常将此视为发布后的任务或一项似乎永远无法完成的待办事项，直到出现严重的生产问题，支持工程师不得不苦苦寻找根本原因。而这时，问题已经发生，由于系统缺乏可观测性，浪费了大量时间。
实施可观测性的四个主要步骤包括：
- 仪表化
- 相关性
- 自动化
- 洞察与预测
仪表化是实施可观测性的首要步骤，其中应用程序需要从源代码生成必要的遥测数据，以便数据收集器可以接收和聚合这些数据，以供进一步分析。
一旦数据被收集和聚合，必须有一种机制来关联不同应用程序中来自不同事件的遥测数据，以排查问题并确定根本原因。重要的是要在不同应用程序之间采用通用方法以关联这些事件。
分配资源来审查每个遥测事件并根据其进行决策是不切实际的任务。相反，我们需要尽可能自动化分析这些事件的过程，只有需要关注的事件才会触发人工干预。
此外，除了应对关键事件，我们还可以使用可观测性数据来分析用户行为，生成见解和预测，以支持业务决策以提高系统性能和业务。
使用日志实现可观测性
日志是解决企业应用程序问题的最常用和最流行的方法。应用程序可以通过仪表化将不同类型的日志条目，如错误、警告、调试消息和信息详细信息，输出到这些日志文件中。下图显示了使用日志进行可观测性的典型模式。
正如前图所展示的，不同类型的应用程序都会通过日志条目将其内部状态作为外部输出进行公开。这些日志可以被运行在应用程序旁边的代理程序进行聚合或读取。这些代理的主要任务是读取这些日志条目并将它们发布到日志收集器中。日志收集器将负责汇总这些日志条目并在进一步分析之前进行预处理。通过日志分析器，用户可以选择直接使用某种查询语言来分析这些日志，或者可以使用外部仪表板组件来进行分析。一些受欢迎的日志分析工具包括：
- ELK（Elasticsearch、Logstash、Kibana）
- Grafana Labs（Promtail、Loki 和 Grafana）
- Splunk
- New Relic
- Sumo Logic
我们可以使用ELK堆栈来实现如下所示的可观测性模式。
正如前图所示，位于应用程序旁的Beats代理程序负责读取日志文件，并将这些日志条目传送至充当日志聚合器的Logstash。随后，Logstash将这些汇总后的日志存储在其独特存储中，并对日志文件中的数据进行索引、搜索和分析。Elasticsearch是一款强大的工具，能够分析各种类型的数据，包括结构化数据、非结构化数据以及数字、文本和地理空间数据，使用户能够从数据中提取有价值的见解和背景信息。而Kibana则让用户能够以交互方式探索、可视化、分享见解，并通过可视仪表板监视系统。
使用跟踪实现可观测性
跟踪是实施企业应用程序可观测性的另一种方法。在这种情况下，我们采用通用标准，如OpenTelemetry或OpenTracing，发布有关通过应用程序传输的数据的详细信息。
Jaeger是一个开源的分布式跟踪平台，用于实施现代云原生应用程序的可观测性解决方案。它协助运维团队捕获跨多个应用程序的跟踪数据，并利用此信息来排查问题并提升系统性能。下图展示了如何使用Jaeger实现跟踪的可观测性。
在上图中，描述了一种使用情况，其中一个应用程序正在智能利用基于OpenTelemetry的SDK，将应用程序进行仪表化，并将遥测数据发布为一系列"跨度"到Jaeger收集器。在这个过程中，Jaeger收集器会在存储数据之前验证和转换这些数据。可用的存储后端包括内存存储、Elasticsearch、Kafka或数据库。当数据一旦存储在后端存储中，Jaeger查询组件将被用于执行搜索和查询操作，以检索跟踪数据，随后这些数据将在Jaeger用户界面中以可视化的方式展示。