关于应用的可观测性探索

abstiger大约 7 分钟observabilitymonitoringopentelemetrygrafanaspring bootmicrometer

可观测性（Observability）一词最早出现在控制论领域，有着几十年的历史。随着云原生时代的到来，2018年，CNCF率先将可观测性open in new window一词引入IT领域，并称可观测性是云原生时代必须具备的能力。自此，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。

原理背景

可观测性是根据外部输出了解复杂系统内部状态的能力。当一个系统具备可观测性时，用户可以通过查看它产生的观测数据来定位问题的根本原因，而无需额外的测试或编码。

可观测性与传统监控

可观测性（Observability）与传统监控（Monitoring）的区别，参考：Observability VS Monitoringopen in new window

observability-vs-monitoring

Monitoring and observability are two ways to identify the underlying cause of problems. Monitoring tells you when something is wrong, while observability can tell you what’s happening, why it’s happening and how to fix it.

总结：可观测性是监控的超集，包含了监控的所有功能。监控一般面向运维人员，而可观测性则同时面向开发人员与运维人员。

观测协议制定者 OpenTelemetry

基于上面可观测性的定义，要想做到应用的可观测性，需要应用本身吐各种观测信号数据出来，然后将这些信号加工处理后，统一送到观测平台。

这就牵扯到不同语言应用端的采集规范及各种平台端的协议兼容问题，随后社区分别出现了OpenTracingopen in new window和OpenCensusopen in new window，最终他们达成一致，于 2019 年 5 月合并open in new window形成了 OpenTelemetryopen in new window（简称 OTel）。

OpenTelemetry 的目标是制定规范并提供一组标准化的与供应商无关的 SDK、API 和工具，用于摄取、转换数据并将应用观测数据发送到可观测性后端（开源或商业供应商）。

组件构成

目前 OpenTelemetry 基本由以下组件构成：

Cross-language specification
The OpenTelemetry Collector
Per-language SDKs
Per-language instrumentation libraries
Per-language Automatic Instrumentation
K8s Operator

遥测信号

Traces
Metrics
Logs
Baggage

除了各信号本身提供的信息外，OpenTelemetry 还特别关注信号间的协同处理。试想一个生产问题排查过程可能如下：运维人员收到某个应用的指标 Metric 告警信息（比如服务响应大量异常），通知到该应用的开发人员，开发人员打开观测平台的指标面板后，通过异常指标的采样数据 Exemplar 关联 Trace 找到其中某笔具体的异常交易，分析其完整链路，找到报错的 Span，再根据TraceID和SpanID关联到具体的交易日志 Log ，根据日志报错详情，定位到本次告警的根本原因。

观测信号消费者（之一） Grafana Stack

Grafana Website: https://grafana.com/open in new window

Grafana

https://grafana.com/docs/grafana

Grafana Loki

https://grafana.com/docs/loki

Grafana Tempo

https://grafana.com/docs/tempo

Grafana Mimir

https://grafana.com/docs/mimir

Grafana Agent

https://grafana.com/docs/agent

观测信号生产者（之一） Spring Boot

Micrometer Website: https://micrometer.io/open in new window
Spring Boot Actuator Metrics: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#actuator.metricsopen in new window
Observability with Spring Boot 3: https://www.baeldung.com/spring-boot-3-observabilityopen in new window

动手实践

了解完相关原理背景后，我们尝试搭建一个可观测性的端到端环境，实际感受下可观测性的方方面面。总体架构如下：

搭建观测平台

基于 Grafana 开源全家桶的观测平台搭建，目前官方对 Kubernetes + Helmopen in new window 容器化方式安装的支持更好，但我们本次还是尝试采用 Ubuntu + Aptopen in new window 安装包方式安装。

增加Grafana仓库源

echo "deb https://apt.grafana.com stable main" | tee /etc/apt/sources.list.d/grafana.list
wget -q -O - https://apt.grafana.com/gpg.key | apt-key add -

安装配置 Loki

sudo apt install loki

安装配置 Tempo

sudo apt install tempo

安装配置 Mimir

sudo apt install mimir

安装配置 Grafana

sudo apt install grafana

配置数据源 Datasource 及配置面板 Dashboard 过程不再赘述。

稍微关注下各数据源的关联协作配置：

metrics-to-traces: https://grafana.com/docs/grafana/latest/datasources/prometheus/#configuring-exemplarsopen in new window
traces-to-metrics: https://grafana.com/docs/grafana/latest/datasources/tempo/#trace-to-metricsopen in new window
traces-to-logs: https://grafana.com/docs/grafana/latest/datasources/tempo/#trace-to-logsopen in new window
logs-to-traces: https://grafana.com/docs/grafana/latest/datasources/loki/#derived-fieldsopen in new window

安装配置 Grafana Agent

sudo apt install grafana-agent

配置 Apache 反向代理

配置 Apache 反向代理 Grafana Agent 的 Http2，最终 Grafana Agent Http2 入口地址为：https://oltp.krproject.org:443

需要说明的是这种 otelcol 的部署形式类似 gatewayopen in new window ,如果服务在本地windows上运行，推荐还是在本地安装 otelcol 并已 agentopen in new window 方式运行，将信息采集并 export 到 gateway 中

本地应用接入

本地Windows环境java应用接入

直接接入

应用直接接入观测平台：

java -javaagent:opentelemetry-javaagent.jar `
    -D"otel.service.name"="octopus-archetype-admin" `
    -D"otel.logs.exporter"="otlp" `
    -D"otel.traces.exporter"="otlp" `
    -D"otel.metrics.exporter"="otlp" `
    -D"otel.exporter.otlp.endpoint"="https://otlp.krproject.org:443" `
    -jar octopus-archetype-admin-2.0.0-SNAPSHOT.jar

间接接入

windows本地下载的 otelcol.exe 后，执行：.\otelcol.exe --config=otelcol-config.yaml, 其中otelcol-config.yaml配置如下：

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: localhost:4317

exporters:
  logging:
    verbosity: normal # detailed
  otlp:
    endpoint: https://otlp.krproject.org:443

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [logging, otlp]
    traces:
      receivers: [otlp]
      exporters: [logging, otlp]
    logs:
      receivers: [otlp]
      exporters: [logging, otlp]

应用通过本地 otelcol 间接接入观测平台：

java -javaagent:opentelemetry-javaagent.jar `
    -D"otel.service.name"="octopus-archetype-admin" `
    -D"otel.logs.exporter"="otlp" `
    -D"otel.traces.exporter"="otlp" `
    -D"otel.metrics.exporter"="otlp" `
    -D"otel.exporter.otlp.endpoint"="http://127.0.0.1:4317" `
    -jar octopus-archetype-admin-2.0.0-SNAPSHOT.jar

容器应用接入

Kubernetes容器环境java应用接入

效果展示

Dashboard
MetricsToTraces
TracesToLogs
LogsToTraces

总结展望

OpenTelemetry 已然成为可观测性领域的事实标准，不管是开发人员还是运维人员都应当学习了解 OpenTelemetry 的规范及各信号 Signal 的目的与含义。

当然角色不同，关注的侧重点可能会有些差异：

作为开发人员

作为应用负责人，应当能够通过可视化大屏迅速了解应用运行情况，定位发现运行问题
作为应用开发者，了解如何通过 opentelemetry-instrumention 自动及手动织入应用，进行观测信号采集
作为应用开发者，考虑引入 opentelemetry-sdk 依赖进程序，通过配置驱动，可导出应用内部观测数据至观测平台
作为框架开发者，考虑集成 opentelemetry-api 进框架，定制框架中指标采集和链路处理

作为运维人员

搭建配置信号采集处理器 opentelemetry-collector，从应用程序中采集观测信号，进行加工处理，导出至观测平台
搭建并维护能够支持 otlp 协议的观测平台，包括各观测信号的存储查询及可视化展现与报警处理等

未来展望

目前日志信号 Logs 的状态尚未 stable，采集器 Collector 尚未 1.0.0，OpenTelemetry 规范和各厂家实现还需要些语义转换conversion和垫片处理shim
堆栈跟踪 Profiles 有望被纳入为新的signalopen in new window，grafana已有布局phlareopen in new window
opentelemetry-ebpfopen in new window 作为可观测的另一个方向也在进行中，关于ebpf，是一个大领域了，不在本文赘述了

写在最后

本文旨在对目前应用可观测性的现状做一些粗浅的调研探索，诸多细节并未深入。关注这个生态也有段时间了，社区活跃度蛮高，期待规范早日落地，期待开源方案更加完善，也期待各供应商迅速跟进（请卷起来好吗 😄 ）。

关于应用的可观测性探索

# 原理背景

# 可观测性与传统监控

# 观测协议制定者 OpenTelemetry

# 组件构成

# 遥测信号

# 观测信号消费者（之一） Grafana Stack

# Grafana

# Grafana Loki

# Grafana Tempo

# Grafana Mimir

# Grafana Agent

# 观测信号生产者（之一） Spring Boot

# 动手实践

# 搭建观测平台

# 增加Grafana仓库源

# 安装配置 Loki

# 安装配置 Tempo

# 安装配置 Mimir

# 安装配置 Grafana

# 安装配置 Grafana Agent

# 配置 Apache 反向代理

# 本地应用接入

# 直接接入

# 间接接入

# 容器应用接入

# 效果展示

# 总结展望

# 作为开发人员

# 作为运维人员

# 未来展望

# 写在最后