系统可观测性
可观测性由来和定义
随着分布式架构渐成主流，可观测性（Observability）一词也日益频繁地被人提起。可观测技术被 Gartner 列为 2023 年十大战略技术趋势之一。
最初，它与可控制性（Controllability）一起，是由匈牙利数学家 Rudolf E. Kálmán 针对线性动态控制系统提出的一组对偶属性，原本的含义是:
- 系统可以由其外部输出推断其内部状态的程度。其次，一系统具有可观测性当且仅当：针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别目前的状态
在学术界，虽然”可观测性”这个名词是近几年才从控制理论中借用的舶来概念，不过其内容实际在计算机科学中已有多年的实践积累。学术界一般会将可观测性分解为三个更具体方向进行研究，分别是：事件日志、链路追踪和聚合度量，这三个方向各有侧重，又不是完全独立，它们天然就有重合或者可以结合之处，2017 年的分布式追踪峰会（2017 Distributed Tracing Summit）结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》系统地阐述了这三者的定义、特征，以及它们之间的关系与差异，受到了业界的广泛认可。
其后，Cindy Sridharan在其著作《Distributed Systems Observability》中，进一步讲到指标、追踪、日志是可观测性的三大支柱（three pillars）。云监控领域的领导者，Datadog也在其网站上用三大支柱来阐述可观测性。
- 日志（Logging）：日志的职责是记录离散事件，通过这些记录事后分析出程序的行为，譬如曾经调用过什么方法，曾经操作过哪些数据，等等。输出日志的确很容易，但收集和分析日志却可能会很复杂，面对成千上万的集群节点，面对迅速滚动的事件信息，面对数以 TB 计算的文本，传输与归集都并不简单。对大多数程序员来说，分析日志也许就是最常遇见也最有实践可行性的“大数据系统”了。
- 追踪（Tracing）：单体系统时代追踪的范畴基本只局限于栈追踪（Stack Tracing），调试程序时，在 IDE 打个断点，看到的 Call Stack 视图上的内容便是追踪；编写代码时，处理异常调用了 Exception::printStackTrace()方法，它输出的堆栈信息也是追踪。微服务时代，追踪就不只局限于调用栈了，一个外部请求需要内部若干服务的联动响应，这时候完整的调用轨迹将跨越多个服务，同时包括服务间的网络传输信息与各个服务内部的调用堆栈信息，因此，分布式系统中的追踪在国内常被称为“全链路追踪”（后文就直接称“链路追踪”了），许多资料中也称它为“分布式追踪”（Distributed Tracing）。追踪的主要目的是排查故障，如分析调用链的哪一部分、哪个方法出现错误或阻塞，输入输出是否符合预期，等等。
- 度量（Metrics）：度量是指对系统中某一类信息的统计聚合。譬如，JVM的内存大小、各分代的用量、峰值的线程数、垃圾收集的吞吐量、频率等等。度量的主要目的是监控（Monitoring）和预警（Alert），如某些度量指标达到风险阈值时触发事件，以便自动处理或者提醒管理员介入。
值得注意的是，虽然业界都在依据三大支柱理论来阐述可观测性，但是这并不代表了可观测性就是建设日志、追踪以及度量三套系统，提出者Peter Bourgon本人也在博客中指出，讨论可观测性，需要明确讨论对象，对不同的数据类型应该有不同的优化处理方法。Google Dapper（谷歌的分布式追踪系统）作者Ben Sigelman更是直言，日志、追踪、度量只是三种数据类型。
Gartner权威报告中对于可观测性的描述为：
- 所谓“可观测性”，就是在任何相关方采取任何类型的行动时，都会产生包含了数字化特征的数据，这些数据都可以称之为“可观测数据”，如日志、痕迹、API 调用、停留时间、下载和文件传输等。应用可观测性用一种高度统筹和整合的方式将所有可观测的特征数据进行反馈，创造出一个决策循环，从而提高组织决策的有效性。
可观测性不仅仅来源于学术上的需要，更在于在现代系统中，伴随着微服务、云计算、云原生等技术的运用，技术架构微服务化、运行时环境容器化、业务系统依赖关系复杂化、运行实例生命周期短，规模大。同时传统的容器、应用、业务分层监控边界被打破，研发（Dev）、运维（Ops）、安全（Sec）的分工逐渐模糊。业界开始意识到，IT系统作为一个有机的整体，对IT系统状态的监测与诊断不再是传统监控系统能够完成的任务，因此，可观测性被提出并得以快速发展。
可观测性价值
谷歌在Google SRE book第十二章中对于可观测性的的价值定位非常简单：快速排障（troubleshooting）。
- There are many ways to simplify and speed troubleshooting. Perhaps the most fundamental are:
- Building observability—with both white-box metrics and structured logs—into each component from the ground up
Designing systems with well-understood and observable interfaces between components. - Google SRE Book, Chapter 12
为何快速排障需要可观测性？这是由于IT系统不断增加的复杂度决定的。大量云原生技术的采用，导致IT系统越来越复杂，快速排障变得越来越难。传统的应用监控（APM）和网络监控（NPM）工具，可以发现某个函数调用失败或者某个链路性能下降，却难以在复杂的云环境下找到故障发生的根本原因。
除此之外，可观测性还可以做到：准确评估系统容量、动态展示服务链路、精准优化性能、智能告警、零侵扰、全栈观测、安全建设等等。
如果结合业务来看，可观测性还可以做到用户行为统计分析、用户画像等业务观测来辅助业务决策。
可观测性和传统监控的区别
在我和其他人交流可观测性的时候，很多人都会说：“哦，就是监控啊”。确实，监控和可观测性的界限相对模糊，可观测性并不只是换个名字高大上一点，监控是可观测性的基础之一，可观测性是对传统监控的演进和升华。
从黑盒到白盒
监控更多关注的是具体指标的变化和报警，关注系统的失败因素，多与运维相关，强调从外到内，从外部通过各种技术手段去看到内部，关注的是点。侧重于观察特定指标了解系统概况以及告警2个方面，即感知到“正在发生什么”。
可观测性关注的是应用本身的状态，是对系统的一种自我审视，强调从内到外，站在宏观的角度去聚合分析各种指标，涵盖了系统排错、剖析、依赖分析等方面，具有比监控更广泛、更主动的能力；不但告诉我们系统“正在发生什么”，同时帮助我们了解“为什么会这样”。
控制领域中，研究可观测性的目的是提供基于系统内部状态（白盒），而非系统外部输出（黑盒）进行控制的理论依据。在IT领域中，简单而言，可观测性就是为复杂IT系统寻求白盒监控能力。
从局部到整体
传统监控更多关注于某个特定方向，比如基础设施：主机、网络、内存、进程等基本指标，比如应用性能监控APM、网络性能监控NPM。
可观测性关注的是所有能够反应系统运行状态的数据，包括但不限于云平台、主机、进程、容器、网络、Kubernetes、Serverless、数据库、中间件、服务，以及用户、会话、请求、访问等等，近乎所有软件堆栈。同时贯穿了系统从开发诞生到下线消亡的整个生命周期，包括开发、测试、上线、部署、发布。通过分析系统的 Metrics（指标）、Traces（链路）、Logs（日志）等数据，构建完整的观测模型，从而实现故障诊断、根因分析和快速恢复。
使用主体从运维到全局
传统监控的使用主体是运维，而随着可观测性涵盖了系统从研发到发布的全生命周期，运维、研发、安全、架构等角色都会是可观测性的建设者和使用主体。
- 运维：深入熟悉产品业务和应用服务，定义并关联业务指标、应用服务指标、系统资源指标等。
- 研发：在框架层设计和实现对分布式应用服务运行时的Metric、Trace、Log数据采集。
- 架构师：业务应用系统和可观测性系统的整体架构设计，需要关注无侵入式采集上报、多维度量聚合、错误寻根分析、整体海量数据处理和存储等。
当需要利用可观测性来建设业务层面的需求，比如用户画像时，产品人员也会参与采集指标的定义工作。
技术层面要求更高
- 零侵扰、低功耗
传统监控，要么需要应用程序中埋点插码，要么需要在基础设施中分光镜像，均会对IT系统进行侵扰。可观测性通常要采集各种维度的数据，必然不可能使用传统方式，而是要求零侵扰的去获取数据。零侵扰的另一方面是要求低功耗，不能因为采集数据而影响应用或基础设施性能，例如，通常采集点功耗不能超过业务功耗的1%。 - 实时性
云原生等应用的动态性要求可观测性平台必须具备实时性。如果应用的升级/扩容在分钟级完成，那么监控系统就必须提供秒级的反馈能力。这里的反馈需要对海量指标/追踪/日志数据进行查找分析，因此对可观测性平台的海量数据实时处理能力提出了极高要求。
主流技术方案
主流云厂商和平台企业方案
构建可观测性最快速和高效的方式是使用云厂商或者第三方平台企业提供的解决方案。
各大云计算厂商采用了不同的策略。有些采用多种产品组合的方式，针对不同场景，为客户提供不同的解决方案，比如：
AWS的CloudWatch以及拥抱开源的AMP、AMG、ADOT
CloudWatch一直以来都是AWS最主要的监控服务，包含了监控、告警、日志、事件等功能。
为了应对云原生可观测性场景，CloudWatch推出了Container Insights容器监控功能，并与Grafana Labs合作，推出了AMG和AMP，同时跟进OpenTelemetry项目发布了ADOT。通过ADOT、AMP、AMG的组合，AWS解决了安全性、高可用性、扩展性等问题，让客户在AWS上可以借助开源社区的优势与力量实现云原生可观测性。
阿里云的ARMS、链路追踪Tracing Analysis、日志服务SLS
阿里云ARMS主要能力围绕应用监控构建，包括应用监控、前端监控、Prometheus监控、云拨测、Grafana服务、告警管理等
阿里云ARMS需要与日志服务SLS，链路追踪服务配合使用才能实现完整的可观测性体验。
华为云APM、AOM等
有些厂商则提供了统一的解决方案，比如：
Azure monitor
Azure Monitor是Azure统一的监控服务，支持Metrics, Logs, Traces等多种数据类型接入，为客户提供可视化、分析、告警、洞察等功能。
国内的第三方提供商，目前看到的有观测云、乘云、云杉等。可以看到，各大厂商在提供自有的可观测方案外，都在致力云原生下的可观测建设以及拥抱开源的可观测技术。
采用云厂商或者平台企业主要问题是用户的应用大概率需要跑在公有云上，并且观测数据要由第三方管理并且计费模式相当复杂。因此，对于中小企业这种方式是首选，但对于采用混合云架构，合规性要求高，项目预算制的中大型行业客户来说，很难完全依赖厂商提供可观测性服务。
开源可观测性技术现状
当前，主流可观测性系统主要基于日志、度量、追踪三大数据类型构建，并且紧密拥抱云原生。
下图为CNCF定义的可观测性技术栈：
经过社区的不断分化分类，逐渐细化成了五个大的方向，分别是：
- Monitoring
- Logging
- Tracing
以及最新加入进来的
- Chaos Engineering（混沌工程）
混沌工程是通过主动向系统中引入软件或硬件的异常状态（扰动），制造故障场景，并根据系统在各种压力下的行为表现，确定优化策略的一种系统性稳定性保障手段。
- Continuous Optimization（持续优化）
持续优化本是应用数学中的一个分支，关于持续优化目前没有太多的资料，个人猜测可能和利用可观测性来持续优化系统有关。
利用上述产品的组合，我们可以比较快速的搭建一个可观测性系统。但是真正用起来会发现各种各样的问题。总结起来有如下几点：
- 组件繁多: 针对Metrics, Traces, Logs三种数据，往往需要搭建三套独立的系统，内部涉及的组件更多，维护成本很高。
- 数据不互通：同一个应用不同类型的数据被存储在相互独立的系统，数据不互通，难以发挥数据最大的价值。
- 厂商绑定：一些商业产品没有遵守社区标准，在数据采集、传输、存储、可视化、告警等阶段都可能与厂商绑定。后续更换方案的成本巨大。
我们总是在用三大支柱来描述可观测性，这让我们更容易理解却也让可观测性变的分裂，我们需要的不是三根柱子，而是一根绳子。
中国信通院《可观测性技术发展白皮书》指出，可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力。
针对这个问题，CNCF 推出了 OpenTelemetry 项目。该项目雄心勃勃，旨在统一Metrics、Logs、Traces三种数据类型。
OpenTelemetry
OpenTelemetry 是OpenTracing (OT) 和 OpenCensus (OC)合并而成，最核心的功能是产生、收集可观测性数据，并支持传输到后端各种存储和分析软件中。整体的架构如下图所示，其中：
- OTel API/SDK：用于产生统一格式的可观测性数据。
- OTel Collector：用来接收这些可观测性数据，并支持把数据传输到各种类型的后端系统。
当然OpenTelemetry也有局限性，OpenTelemetry解决了三支柱数据的采集、传输、处理、收集的问题。但在这之后的诸多工作(数据存储、数据计算、数据关联、数据展示)暂时还是依赖各个后端平台自己去实现，目前没有一个统一的解决方案。
此外OpenTelemetry的日志体系目前只能说已经初步完成接近于GA，并不能达到生产使用的程度，想让用户抛弃Filebeat、Logstash这些久经考验的工具，选择尚不成熟的OpenTelemetry收集日志，显然信心不足。
总而言之我很看好OpenTelemetry的明天，社区也非常活跃，天下大势，分久必合，但是目前使用还是需要慎重。
主流开源技术
鉴于开源社区主流技术方案还是围绕三大支柱来做的，所以本章还是按照日志、追踪、度量三方面来描述。
监控（Monitoring）
监控领域的主要技术栈包括：Prometheus，Cortex，ZABBIX，Grafana，sysdig，Prometheus已经成为事实上的监控标准，主流监控技术方案都会围绕Prometheus来做。
Prometheus提供了通用的数据模型和快捷数据采集、存储和查询接口，主要包括以下组件：
- Prometheus server：服务核心组件，采用pull方式收集监控数据，通过http协议传输。并存储时间序列数据。Prometheus server 由三个部分组成：Retrival，Storage，PromQL
- Retrieval：负责在活跃的target主机上抓取监控指标数据。
- Storage：存储，主要是把采集到的数据存储到磁盘中，默认为15天。
- PromQL：是Prometheus提供的查询语言模块。
- client Library：客户端库，目的在于为那些期望原生提供数据展示功能的应用程序提供便捷的开发途径。
- Exporters：指标暴露器，负责收集应用程序或服务的性能指标数据，并通过HTTP接口供Prometheus Server获取。社区提供了丰富的Exporter选型，几乎可以收集一切想要收集的数据，还可以自己编写Exporter。
以Prometheus为中心辐射了很多周边生态组件，比如：
- Service Discovery，用于自动发现target主机
- Alertmanager，独立的告警模块，支持邮件、钉钉、企业微信等主流方式
- Pushgateway，支持以push方式暂存数据
- Grafana，将数据可视化和分析
Prometheus本身也有局限性，比如：
- 不支持集群，当然社区也提供了方案，比如Cortex、thanos
- 不适合存储事件及日志等，它更多地展示的是趋势性的监控，而非精准数据；
- 不长存数据，Prometheus认为度量数据无需长期存储，所有如果有需求，需要自己提供长存储方案。
日志（Logging）
日志领域的主流技术方案除却经典Elastic Stack外，新兴的如Grafana Loki、Graylog。日志的技术方案链路较长，主要分为日志采集、日志缓冲、日志清洗、日志存储、日志可视化。
- 日志采集
- 常见的日志采集工具包括Logstash、Filebeat、Fluentd/Fluent-Bit。
- Logstash由于对cpu、内存、io占用太大已经基本不使用在日志采集上；
- Filebeat非常轻量稳定，主要采集目标是文件；
- Fluentd/Fluent-Bit对传统日志采集的流程进一步的细分，能够将散乱的日志来源统一解析过滤并存储，是容器环境下日志采集的首选。
- 此外Loki使用Promtail采集日志，还有Flume、Loggie等等。
- 日志缓冲
- Kafka等消息队列都可以用作日志缓冲，除非日志数据量过于庞大，否则一般会省去日志缓冲。
- 日志清洗
- 我所知的专门用于日志清洗的组件就是logstash，其他如新兴的日志方案Loki、Graylog等都将日志过滤、清洗功能集成在组件内部。
- 日志存储
- 首当其冲的是使用范围最广的Elasticsearch，基于倒排索引的特性使得ES查询速度快、QPS较高。
- 但是由于大规模建设成本问题，如今人们也在探索新的存储方式，比如clickhouse，吞吐量更高，查询性能更快。
- 而Loki直接使用本地存储或者对象存储。
- 日志可视化
- 可视化上主要有Elastic Stack中的Kibana，Grafana Stack中的Grafana，而Graylog自带可视化模块Graylog-web。
追踪（Tracing）
追踪领域最早可以追溯到Google的Dapper系统，比起日志与度量，追踪这个领域的产品竞争要相对激烈得多。一方面，目前还没有像日志、度量那样出现具有明显统治力的产品，仍处于群雄混战的状态。另一方面，几乎市面上所有的追踪系统都是以 Dapper 的论文为原型发展出来的，基本上都算是同门师兄弟，功能上并没有太本质的差距，却又受制于实现细节，彼此互斥，很难搭配工作。
一个完整的分布式追踪系统应该由数据收集、数据存储和数据展示三个子系统构成，而狭义上讲的追踪则就只是特指链路追踪数据的收集部分。譬如Spring Cloud Sleuth就属于狭义的追踪系统，通常会搭配 Zipkin 作为数据展示，搭配 Elasticsearch 作为数据存储来组合使用。除此之外，下面谈到的大多属于完整的追踪系统。
追踪的数据通常由业务应用产生，主流的收集方式包括：
（1）日志，Dapper系统就是通过从日志中筛选出追踪类型数据进行汇聚。
（2）应用探针，以Java应用为例，通常采用Java Agent字节码增强技术注入应用，对业务零侵入。
（3）服务网格下的SideCar边车代理，技术无关性，通过网络流量采集数据，缺点就是无法深入到方法级别，比如Envoy。
而在存储上大部分组件也都以ES为主，强如SkyWalking支持ES、H2、Mysql、TIDB、Sharding sphere等方式。
追踪领域目前比较成熟、出现较早的的一些组件包括：Twitter开源的Zipkin、Apache的SkyWalking、PinPoint、大众点评开源的CAT。新兴的比如CNCF jaeger、Grafana Tempo。
主流落地方案
ELK/EFK + GPE + SkyWalking
这套方案就是奔着建设三套系统的思路去的，也是最经典的可观测性方案：
- 日志方面Elasticsearch做存储，FileBeat或者Fluentd做采集，Kibana做展现，必要的话接入Logstash进行日志清洗，Kafka做日志缓冲
- 监控方面同样Elasticsearch做存储，Prometheus结合各种sdk、exporter、agent做指标采集和接入，Grafana做展示
- 追踪方面自由度大一些，我个人习惯使用SkyWalking
这套方案能力均衡，如果没有什么特殊需求，选万金油组合总没错的。
OpenTelemetry + Loki + Tempo + Prometheus + Grafana
这套方案算是新兴的轻量化方案，主要围绕Grafana Stack构建。
- 日志使用Loki，日志的收集可以通过loki4j收集应用打印日志，也可以通过Promtail收集其他类型日志
- 监控依然基于Prometheus和Grafana的无缝集成
- 追踪方面使用OpenTelemetry采集器进行数据采集，发送到Tempo存储并集成Grafana进行展示
ElasticSearch + Kibana + Beats + Elastic APM
这套方案主要围绕Elastic Stack构建，数据采集基于Beats家族组件
- 日志还是基于EFK
- 监控指标的采集利用Beats家族的Metricbeat组件
- 追踪使用Elastic APM
- 统一由Kibana进行数据展示
其他
其他的方案就不赘述了，开源技术可选余地较大，组合方案繁多。
技术之外的因素
选取技术方案只是构建可观测性的一部分，要让可观测性更有效我们还需要在数据层面做一些规范和约束，提高采集数据的质量
统一日志
日志数据记录的信息以及质量对于问题发现和问题定位起着关键的作用，然而现状是开发者较随意，都有自己的理解和做法，形成了五花八门的格式、级别、分类，甚至于 error 和 info 都混杂在一起。
对于日志何时打、打什么、怎么打都要订好规范，日志分类、日志格式、日志级别、日志内容也需要有相应的标准，如果有必要提供统一的日志sdk。
下表是OpenTelemetry的LogModel模型
| 字段名 | 描述 | 必选 |
| Timestamp | 日志时间戳 | 是 |
| TraceId | 关联请求的TraceId | 否 |
| SpanId | 关联请求的SpanId | 否 |
| TraceFlags | W3C trace flag. | 否 |
| SeverityText | 日志等级的可读描述. | 否 |
| SeverityNumber | 日志等级. | 否 |
| ShortName | 用于标识日志类型的短语. | 否 |
| Body | 具体的日志内容. | 否 |
| Resource | Log关联的Resource. | 否 |
| Attributes | 额外关联属性. | 否 |
度量指标治理
监控领域主要关注度量（Metrics）数据类型，关于度量指标数据，特点就是面广、量多，单单主机一项，就需要监控：CPU、内存、磁盘、IO、内核参数、网络相关等等十几个维度，每个维度还有几个到上百个不等的具体指标。所以对于度量指标的治理也很重要，搞清哪些有用哪些无用，以下举一些指标分类和指标信息供参考：
- 端监控：针对用户在体验上可以感知的对象进行监控，如网站、App、小程序等。
- 对于端的监控通常在互联网企业或者重视用户体验的公司，在移动客户端的系统中，端监控的对象主要有H5、小程序、Android 系统、iOS 系统等，完善的端监控可以反馈地域、渠道、链接等多维度的用户体验信息；用户终端为传统的 Web 页面时，端监控仍会围绕用户体验采集数据，比如页面打开速度（测速）、页面稳定性（JS）和外部服务调用成功率（API），这 3 个方面的数据反映了 Web 页面的健康度。
- 业务层监控：对于业务层，可按需深度定制监控系统，实现对业务属性的监控告警功能，生成业务数据监控大盘。比如用户访问 QPS、DAU 日活、转化率、业务接口（如登录数、注册数、订单量、支付量、搜索量）等都是常见的监控对象。
- 应用层监控：主要是对分布式应用和调用链应用的性能进行管理和监控，如对 Spring Boot、JVM 信息、服务链路、服务组件等应用在进行诸如 RPC 调用、Trace 链路追踪动作时产生的数据进行监控。
- 中间件监控：监控的主要对象是框架自身的埋点、延迟、错误率等。这里的中间件包括但不限于消息中间件（RabbitMQ、Kafka、RocketMQ 等）、数据库中间件（MySQL、Oracle、PostgreSQL、TIDB、PolarDB 等）、数据库连接池中间件（HikariCP、Druid、BoneCP 等）、缓存中间件（Redis、Memcached 等）和 Web 服务中间件（Tomcat、Jetty 等）。
- 系统层监控：系统层主要包含 CPU、Load、内存、磁盘 I/O、网络相关参数、内核参数、ss 统计输出、端口、核心服务的进程存活情况、关键业务进程资源消耗、NTP offset 采集、DNS 解析采集等指标。这些都可以作为对系统层监控的关键指标。另外，网络监控也是系统监控中很重要的部分，对交换机、路由器、防火墙、VPN 进行的监控都属于网络监控的范畴，内网和外网的丢包率、网络延迟等也都是很重要的监控指标。
指标关联、拓扑、可视化
除却数据治理，另一个很重要的方面也是难点就是指标关联、拓扑、可视化，也是真正体现可观测的方面。指标数据都展示了，但是依然看不出问题；或者指标显示没问题，但是系统出错了，都是不好的结果。
能够提升可观测性的方式就是拆分指标，建立指标关联和拓扑，以订单业务为例，将订单系统-下单接口-节点-接口调用量-相关组件负载等指标关联可以观测下单业务的健康情况。
指标实行可视化能力，采用的方式多是一些监控大盘和图表，拓扑图等形式。关联关系通过线、网、箭头交织在一起，再根据关联关系对链路流量进行染色，当相关指标发生报警时，就可以根据 trace 串联出完整的调用链路。
虽然收起来简单，但是我个人觉得指标关联、拓扑、可视化是可观测系统建设中最难、最繁杂也是最重要的部分。
持续优化改进
针对整个系统的可观测，包括数据收集，视图构建，TAG 体系建⽴，这些步骤均需要时间，不能因为覆盖度或者构建的仪表盘未能在某次事故中发挥作⽤而继续⽤过去的⽅式处理问题，每次未被观测的故障都是进⼀步提升可观测范围的绝佳机会。
未来趋势
OpenTelemetry的完善以及行业标准的制定
可观测性领域缺乏行业统一的标准，虽然出现了OpenTelemetry对数据格式的统一是个好趋势，但是依然存在这从底层数据到上层系统都较为分裂的局面。
当然融合的趋势也在不断的发展，比如大部分追踪组件都适配OpenTracing标准；主流厂商也都在推出统一日志、追踪、度量的总体解决方案。
以应用为中心以及业务至上
可观测性的核心从来不是系统或者软件，而是背后的业务。在基础的技术指标观测成熟后，未来的可观测性会聚焦在业务观测上。同时以应用为中心关联指标、链路与日志逐渐成为主流。
基础可观测性与其他方向的融合
测试
混沌工程和持续优化，混沌工程是否能划分在可观测性里，当前社区依然存在疑议，而CNCF的可观测技术分类中已包含了混沌工程和持续优化。
安全
摩根士丹利《安全分析和可观测性》一文中提到，在国外，以DataDog为代表的公司在上市之后发布的新增功能中有70%都是安全相关的。
可观测性通过收集系统各方面数据可以分析出系统的故障，自然也就能够分析出系统有没有被入侵。比如DataDog就提供了通过分析当前访问请求区分哪些可能是黑客在嗅探的功能，并准备未来做发现DDoS攻击的功能。
安全和可观测性的合并在全球范围内已经成为一种新趋势。
eBPF
eBPF这个不太懂，大意是一种内核技术，可以将代码或函数嵌入内核，在Kubernetes环境下，可以增强内核和网络方面的监控，算是技术上的趋势吧。不懂归不懂，但是个人感觉eBPF更多可以增强可观测性，而不是取代现有的观测技术。
结语
可观测性还处于快速发展时期，我个人认为目前可观测性还处于不断扩展对于系统观测的手段和细节，以及探索数据类型和融合分析的阶段；如果你问我有没有必要建设可观测性，我会回答有必要，都2023年了，还有没用微服务、云原生的吗？对于快速复杂化的生产环境，可观测性是不可或缺的。
作者: zhushiwei
链接: https://pigpi.cn/17779.html
来源: pigpi
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。