可观测性调研

可观测性调研

可观测性概念与理解

1、可观测性的定义

可观测性是通过检查其输出来衡量系统内部状态的能⼒。

该术语起源于⼏⼗年前的控制理论（它是关于描述和理解⾃我调节系统的）。然⽽，它越来越多地应⽤于提⾼分布式 IT 系统的性能。在这种情况下，可观测性使⽤三种类型的遥测数据⸺指标、⽇志和跟踪（metrics, logs and traces）⸺来提供对分布式系统的深⼊可⻅性，并允许团队找到⼤量问题的根本原因并提⾼系统性能。

在过去⼏年中，企业以微服务、⽆服务器和容器技术的形式迅速采⽤了云原⽣基础设施服务，例如AWS。在这些分布式系统中追踪事件的起源需要在云上、本地或两者上运⾏的数千个进程。但是传统的监控技术和⼯具很难跟踪这些分布式架构中的许多通信路径和相互依赖关系。

可观测性使团队能够更有效地监控现代系统，并帮助他们找到并连接复杂链中的影响，并将其追溯到原因。此外，它还使系统管理员、IT 运营分析师和开发⼈员能够了解他们的整个架构。

谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。

2、可观测的数据及解释

可观测性中使用的主要数据类是：

• 日志 logs
• 指标 metrics
• 跟踪 traces

通常来说 Metrics 监控侧重于技术指标的收集与观测，如服务调用 QPS、响应时间、错误率和资源使用率；Logging 侧重于运行日志的采集、存储与检索；而 Tracing 则偏向于调用链的串联、追踪与 APM 分析。

• Metric的特点是，它是可累加的：他们具有原子性，每个都是一个逻辑计量单元，或者一个时间段内的柱状图。 例如：队列的当前深度可以被定义为一个计量单元，在写入或读取时被更新统计； 输入HTTP请求的数量可以被定义为一个计数器，用于简单累加； 请求的执行时间可以被定义为一个柱状图，在指定时间片上更新和统计汇总。

• logging的特点是，它描述一些离散的（不连续的）事件。 例如：应用通过一个滚动的文件输出debug或error信息，并通过日志收集系统，存储到Elasticsearch中； 审批明细信息通过Kafka，存储到数据库（BigTable）中； 又或者，特定请求的元数据信息，从服务请求中剥离出来，发送给一个异常收集服务，如NewRelic。

• tracing的最大特点就是，它在单次请求的范围内，处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。 例如：一次调用远程服务的RPC执行过程；一次实际的SQL查询语句；一次HTTP请求的业务性ID。

在这三个功能域中，metric倾向于更节省资源，因为他会“天然的”压缩数据。相反，日志倾向于无限增加的，会频繁的超出预期的容量。

下面是阿里对于三种数据的定义解释：

• Logs：我们对于Logs是更加宽泛的定义：记录事/物变化的载体，对于常见的访问日志、交易日志、内核日志等文本型以及包括GPS、音视频等泛型数据也包含在其中。日志在调用链场景结构化后其实可以转变为Trace，在进行聚合、降采样操作后会变成Metrics。
• Metrics：是聚合后的数值，相对比较离散，一般有name、labels、time、values组成，Metrics数据量一般很小，相对成本更低，查询的速度比较快。
• Traces：是最标准的调用日志，除了定义了调用的父子关系外（一般通过TraceID、SpanID、ParentSpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过Trace能够代替一部分Logs的功能，通过Trace的聚合也能得到每个服务、方法的Metrics指标。

一、可观测方案

1、三种数据各自方案

Logs：

ELK（Elasticsearch , Logstash, Kibana）、Splunk、SumoLogic、Loki、Loggly

1.1、Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
1.2、Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
1.3、Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
1.4、Filebeat隶属于Beats。目前Beats包含四种工具：
①Packetbeat（搜集网络流量数据）
②Topbeat（搜集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
③Filebeat（搜集文件数据）
④Winlogbeat（搜集 Windows 事件日志数据）

filebeats->elasticsearch->kibana；
filebeats->kafka->logstash->elasticsearch->kibana;
fluentd->elasticsearch->kibana；
fluentd->kafka->fluentd->elasticsearch->kibana 。

Metrics：

Zabbix、Nagios、Prometheus、InfluxDB、OpenFalcon、OpenCensus

Metrics 比较火的方案就是 Prometheus + Grafana，思路就是通过应用内埋入SDK，选择 Pull 或者 Push 的方式将数据收集到 prometheus 中，然后通过 Grafana 实现可视化

Traces （APM）：

Jaeger、Zipkin、SkyWalking、OpenTracing、OpenCensus

1、Google Dapper （闭源）
Google很早就已经为微服务化了，并在2010年发表了《Dapper - a Large-Scale Distributed Systems Tracing Infrastructure》论文介绍他们的分布式系统跟踪技术。Dapper论文中对实现一个分布式跟踪系统提出了如下几个需求：

• 性能低损耗：分布式跟踪系统对服务的性能损耗应尽可能做到可以忽略不计，尤其是对性能敏感的应用不能产生损耗
• 对应用透明：即要求尽可能用非侵入的方式来实现跟踪，尽可能做到业务代码的低侵入，对业务开发人员应该做到透明化
• 可伸缩性：高伸缩性是指不能随着微服务和集群规模的扩大而使分布式跟踪系统瘫痪
• 跟踪数据可视化和迅速反馈：即要有可视化的监控界面，从跟踪数据收集、处理到结果的展现尽量做到快速，就可以对系统的异常状况作出快速的反应
• 持续的监控：即要求分布式跟踪系统必须是7x24小时工作的，否则将难以定位到系统偶尔抖动的行为

2、Zipkin （开源）

Twitter基于Google的Dapper论文开发了Zipkin并提供了通过Java程序中引入客户端，可隐式拦截Http、Thrift等形式服务调用。通过Http、Kafka、Scribe等方式同步监控数据到服务端，ZipKin带有Web UI，但没有告警功能。

3、Jaeger （开源）

Uber公司的技术团队受Dapper 和 OpenZipkin启发用Go语言也开发了一款链路追踪平台Jaeger。

4、Apache SkyWalking （国产开源主流）

Skywalking 是一个开源APM系统，为微服务架构和云原生架构系统设计。它通过探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM会感知应用间关系和服务间关系，并进行相应的指标统计。

5、OpenTracing

随着链路追踪工具越来越多，开源领域主要分为两派，一派是以 CNCF技术委员 会为主的 OpenTracing 的规范，例如 jaeger zipkin 都是遵循了OpenTracing 的规范。而另一派则是谷歌作为发起者的 OpenCensus，而且谷歌本身还是最早提出链路追踪概念的公司，后期连微软也加入了 OpenCensus。

开源社区也启动了OpenTracing计划，旨在将各种语言和平台间的链路追踪名词和概念进行标准化。OpenTracing制定了一套平台无关、厂商无关的Trace协议，使得开发人员能够方便的添加或更换分布式追踪系统的实现。 OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。

OpenTracing 的优势
OpenTracing 已进入 CNCF，正在为全球的分布式追踪，提供统一的概念和数据标准。
OpenTracing 通过提供平台无关、厂商无关的 API，使得开发人员能够方便的添加（或更换）追踪系统的实现。

6、OpenCensus

大家可能会想，既然有了OpenTracing，OpenCensus又来凑什么热闹？对不起，你要知道OpenCensus的发起者可是谷歌，也就是最早提出Tracing概念的公司，而OpenCensus也就是Google Dapper的社区版。OpenCensus和OpenTracing最大的不同在于除了Tracing外，它还把Metrics也包括进来，这样也可以在OpenCensus上做基础的指标监控；还一点不同是OpenCensus并不是单纯的规范制定，他还把包括数据采集的Agent、Collector一股脑都搞了。OpenCensus也有众多的追随者，最近最大的新闻就是微软也宣布加入，OpenCensus可谓是如虎添翼。 也就是说，这两者在tracing的原理上是一致的，都是基于谷歌的tracing来实现的，但是，opencensus包含了更多的基本功能，比如metrics，数据采集的模块等。因此，opencensus更像是一种大而全的框架，而opentracing只是定义了一种追踪的规范。

其他方案

• PinPoint 韩国开源的一个功能完备的APM系统，支持JVM性能数据采集、服务Trace、告警等功能。它具有应用程序无侵入的应用特性。
• Hawkular是一个功能完备的APM系统，应用程序中嵌入Hawkular客户端，主动将采集数据通过Http或者Kafka传递给Hawkular。Hawkular支持JVM性能数据采集、服务Trace、告警等功能。其中JVM性能数据采集使用JMX，服务Trace使用Zipkin客户端。
• CAT是美团点评开源的功能完备的APM系统，支持JVM性能数据采集、服务跟踪、告警等功能，但需要写监控代码。（最后一个稳定版本是2014年1月，之后已经失去维护。）
• 京东-hydra与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以无缝接入。对于细粒度的兴趣点，需要业务人员手动添加。

2、整合开源方案

但是目前的方案组合或多或少可以解决针对性的一类或者几类问题，但真正应用起来你会发现各种问题：
1、多套方案交织：可能要使用至少Metrics、Logging、Tracing3种方案，维护代价巨大
2、数据不互通：虽然是同一个业务组件，同一个系统，产生的数据由于在不同的方案中，数据难以互通，无法充分发挥数据价值
3、在这种多套方案组合的场景下，问题排查需要和多套系统打交道，若这些系统归属不同的团队，还需要和多个团队进行交互才能解决问题，整体的维护和使用代价非常巨大。因此我们希望能够使用一套系统去解决所有类型可观测性数据的采集、存储、分析的功能。

OpenTelemetry（主角）

有了OpenTracing和OpenCensus，都各自有优劣，那么统一就势在必行。为此，Opentelemetry 横空出世，它出现的第一宗旨是：兼容OpenTracing和OpenCensus。对于使用OpenTracing或OpenCensus的应用不需要重新改动就可以接入OpenTelemetry

针对数据孤岛问题，目前行业内的一大趋势是：拥抱 OpenTelemetry。OpenTelemetry 是由一组 API 和库构成的标准，由 OpenTracing 和 OpenCensus 项目的合并而来，服务于可观测技术的底层数据采集，最早由微软和 Google 发起，当下已经成为美国可观测行业研发的事实标准 —— 微软、Google、Datadog、Splunk 等企业全部采用 OpenTelemetry 完成底层的数据采集，而 OpenTelemetry 的主要贡献者也来自这些公司。

OpenTelemetry 的特点在于制定统一的协议数据格式，并提供底层数据采集器。OpenTelemetry 的数据采集器，目标是兼容所有的语言、所有的系统。OpenTelemetry的终态就是实现Metrics、Tracing、Logging的融合，作为CNCF可观察性的终极解决方案。这三者在可观察性上缺一不可：基于Metrics的告警发现异常，通过Tracing定位问题（可疑）模块，根据模块具体的日志详情定位到错误根源，最后再基于这次问题调查经验调整Metrics（增加或者调整报警阈值等）以便下次可以更早发现/预防此类问题。

但OpenTelemetry的核心工作主要集中在3个部分：

• 规范的制定，包括概念、协议、API，除了自身的协议外，还需要把这些规范和W3C、GRPC这些协议达成一致；
• 相关SDK、Tool的实现和集成，包括各类语言的SDK、代码自动注入、其他三方库（Log4j、LogBack等）的集成；
• 采集系统的实现，目前还是采用OpenCensus的采集架构，包括Agent和Collector。

主要组成

https://blog.csdn.net/DaoCloud_daoke/article/details/122682509

Specification：这个组件是语言无关的，主要是定义了规范，如 API 的规范，SDK 的开发规范，数据规范。使用不同开发源于开发具体 SDK 的时候会按照标准开发，保证了规范性。

Proto：这个组件是语言无关的，主要是定义了 OpenTelemetry 的 OTLP 协议定义，OTLP 协议是 OpenTelemetry 中数据传输的重要部分。如 SDK 到Collector，Collector 到 Collector，Collector 到 Backend这些过程的数据传输都是遵循了 OTLP 协议。

Instrumentation Libraries：是根据 SDK 的开发规范开发的支持不同语言的 SDK，如 java，golang，c 等语言的 SDK。客户在构建观测性的时候，可以直接使用社区提供的已经开发好的 SDK 来构建观测能力。社区也在此基础上提供了一些工具，这些工具已经集成了常见软件的对接。

Collector：负责收集观测数据，处理观测数据，导出观测数据。

架构介绍：
Application： 一般的应用程序，同时使用了 OpenTelemetry 的 Library (实现了 API 的 SDK)。

OTel Libraty：也称为 SDK，负责在客户端程序里采集观测数据，包括 metrics，traces，logs，对观测数据进行处理，之后观测数据按照 exporter 的不同方式，通过 OTLP 方式发送到 Collector 或者直接发送到 Backend 中。

OTel Collector：负责根据 OpenTelemetry 的协议收集数据的组件，以及将观测数据导出到外部系统。这里的协议指的是 OTLP (OpenTelemetry Protocol)。不同的提供商要想能让观测数据持久化到自己的产品里，需要按照 OpenTelemetry 的标准 exporter 的协议接受数据和存储数据。同时社区已经提供了常见开源软件的输出能力，如 Prometheus，Jaeger，Kafka，zipkin 等。图中看到的不同的颜色的 Collector，Agent Collector 是单机的部署方式，每一个机器或者容器使用一个，避免大规模的 Application 直接连接 Service Collector；Service Collector 是可以多副本部署的，可以根据负载进行扩容。

Backend： 负责持久化观测数据，Collector 本身不会去负责持久化观测数据，需要外部系统提供，在 Collector 的 exporter 部分，需要将 OTLP 的数据格式转换成 Backend 能识别的数据格式。目前社区的已经集成的厂商非常多，除了上述的开源的，常见的厂商包括 AWS，阿里，Azure，Datadog，Dynatrace，Google，Splunk，VMWare 等都实现了 Collector 的 exporter 能力。

OpenTelemetry 的 java sdk 中，应用可以无需修改 code，只需要引用对应的 jar 包就可以完成对很多常见观测能力的集成。目前支持的集成已经比较广泛，包含常见的软件集成。主要包含，akka，camel，dubbo，httpclient，cassandra，couchbase，elasticsearch，finatra，geode，grails，grizzly，grpc，guava，get，hibernate，hystrix，jaxrs，jaxws，jdbc，jedis，jetty，jms，jsf，jsp，kafka，kubernetes，log4j，logback，mongo，netty，quartz，rabbitmq，reactor，redisson，rmi，rocketmq，scala，servlet，spark，spymemcached，struts，spring，tomcat，vertx等。使用了 OpenTelemetry 的 java 的 SDK，就可以自带这些软件的调用分析能力。

OpenTelemetry 的 golang sdk 中开始支持 http，grpc，beego，mongo，sarama (kakfa)，host (程序所在主机的内存，网络，CPU使用)，runtime (程序本身的资源使用，如 heap memory 的使用，gc 的情况)，gocql，mux，gin，go-kit，go-restful，gomemcache 等，使用了 OpenTelemetry 的 go 的 sdk，就可以自带这些软件的调用分析能力。

3、商业方案

• Datadog

• dynatrace

• datatrace

• splunk

• ARMS
  阿里应用实时监控服务 (Application Real-Time Monitoring Service) 作为一款云原生可观测产品平台，包含前端监控、应用监控、云拨测、Prometheus监控、Grafana服务等子产品。

  同时阿里SkyWalking和Elasticsearch实现全链路监控

• EagleEye
  阿里的鹰眼是Google 的分布式调用跟踪系统 Dapper 在淘宝的Java实现，现在已经被作为中间件平台应用到阿里内部的各个业务线了。目前已经不提这个产品了

• Tencent OpenTelemetry OTeam
  腾讯天机阁2.0，基于开源的opentelemetry。

• Bytemap
  Bytemap 是字节跳动内基于主机⽹络监控数据打造的数据中⼼⽹络可观测平台，为各业务侧、及数据中⼼整体的⽹络基础设施提供多维度的⽹络质量监控。在具体实现上，我们通过主机内核的 eBPF 采集机制来获取基于连接层⾯细粒度的内核⽹络监控指标，通过实时数仓储存数据和对接流式分析平台。在产品层，我们通过与应⽤、主机的监控指标串联形成统⼀的监控产品。同时通过 API 和数据消费的形式，为多种运维场景提供⽀持。系统上线两年多时间运⾏稳定，多次为业务排障、业务流量容量规划预估提供了完备的数据⽀持，并且与多个运维场景相结合，解决其他场景中遇到的痛点问题，发挥价值。

二、eBPF应用方案

1、开发工具

BCC [开发工具]：是一个建立在 eBPF 基础上的高效内核跟踪和操作程序的工具包，它包括几个有用的命令行工具和例子。BCC 简化了用 C 语言编写 BPF 程序的过程，包括一个围绕 LLVM 包装器，以及 Python 和 Lua 的前端绑定。

BPFTrace [开发工具] ：是一个用于 Linux eBPF 的高级跟踪语言，语法类似 awk 脚本语言。bpftrace使用 LLVM 作为后端，将脚本编译成BPF 字节码，并可使用现有的Linux 跟踪能力和附件点进行交互的库

2、可观测方案

eBPF Exporter [可观测]：CloudFlare公司开源，将 eBPF技术与 Prometheus 结合。 Prometheus exporter for custom eBPF metrics。

Pixie: [可观测] New Relic公司开源， CNCF 沙盒项目。 Pixie 是一个开源的 Kubernetes 应用程序的可观察性工具。Pixie 使用 eBPF来自动捕获遥测数据，而不需要手动装置。

ilogtail: [可观测] 学习的pixel！ iLogtail 为可观测场景而生，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，在阿里巴巴以及外部数万家阿里云客户内部广泛应用。你可以将它部署于物理机，虚拟机，Kubernetes等多种环境中来采集遥测数据，例如logs、traces和metrics。 opentelemetry 的 collector 的一种实现。

Kindling [可观测]国内开源的基于 eBPF的云原生可观测性开源项目，旨在帮助用户理解从内核到代码堆栈的应用程序行为。目前，它提供了一种简单的方法来获取 Kubernetes 环境中的网络流视图，以及许多内置的网络监视仪表板，如重传、 DNS、吞吐量、 TPS等。

WaveScope: [可观测] Weave Scope自动生成应用程序的地图，使您能够直观地理解、监视和控制基于微服务的容器化应用程序。

Hubble: [可观测] 是一个完全分布式的网络和安全观察平台，用于云本地工作负载。它构建在Cilium和eBPF之上，以完全透明的方式深入了解服务的通信和行为以及网络基础设施。

ilogtail: [可观测] 学习的pixel！ iLogtail 为可观测场景而生，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，在阿里巴巴以及外部数万家阿里云客户内部广泛应用。你可以将它部署于物理机，虚拟机，Kubernetes等多种环境中来采集遥测数据，例如logs、traces和metrics。

3、网络安全方案

Cilium [网络，安全，可观测]

Cilium Tetragon [安全] Tetragon 提供了基于 eBPF的完全透明的安全可观测性能力以及实时的运行时增强（runtime enforcement）能力。由于基于 eBPF的内核级收集器中直接内置了智能内核过滤能力和聚合逻辑，Tetragon 无需更改应用程序即可以非常低的开销实现深度的可观测性。

Tracee [安全]：由 Aqua Security安全公司开源，是一个用于 Linux 的运行时安全和取证工具。它使用 Linux eBPF 技术在运行时跟踪系统和应用程序，并分析收集的事件以检测可疑的行为模式。

Falco [安全]：Sysdig公司开源，为云原生运行时安全项目，是事实上的Kubernetes 威胁检测
引擎。Falco 是第一个作为孵化级项目加入CNCF 的运行时安全项目。Falco 就像一个安全摄像
头，实时检测意外行为、入侵和数据盗窃。

Elkeid [安全]是一个云原生的基于主机的安全（入侵检测与风险识别）解决方案，字节开源。

eHIDS[安全]是美团的一个 HIDS的雏形。HIDS全称是 Host-based Intrusion Detection System，即基于主机型入侵检测系统，部署在主机内的，主要是对主机的异常行为进行检测，比如新建文件，创建进程，连接等。

参考链接：

https://www.splunk.com/en_us/data-insider/what-is-observability.html
https://www.infoq.cn/article/j1qeF8L1MoGzFWXCcmbF
https://blog.csdn.net/piaobeizu2011/article/details/121101400
https://zhuanlan.zhihu.com/p/163806366
https://zhuanlan.zhihu.com/p/74930691
https://blog.csdn.net/DaoCloud_daoke/article/details/122682509
https://help.aliyun.com/document_detail/161783.html
https://www.infoq.cn/video/jBlhX7NDADzg1KPXtBwN
https://www.bilibili.com/video/BV18K4y1M7bL/?vd_source=8a390ae80d8701fc4895d2201055fb6b
https://www.infoq.cn/video/G1jGty6ZxClzpjDAvSML