手把手教程：利用 OpenTelemetry 监控微服务

针对一个完整的微服务系统，如何利用 OpenTelemetry 快速搭建一个覆盖数据采集、收集、存储、展示、分析全流程的可观测性系统，crossoverJie 撰写的教程，值得仔细阅读。

原文链接：https://mp.weixin.qq.com/s/f_aohbXsKTKzug1MjJSKQg

前言

OpenTelemetry 作为可观测性的权威组织：

• 定义了 metrics、logs、traces 的标准规范和相应的 API，实现了针对各种语言的 SDK，有效解决了可观测性数据生成难、覆盖不全的问题；
• 围绕着 OpenTelemetry，业界发展和建立了完善的可观测性的软件工具生态，解决了 telemetry 数据在不同软件工具之间的互通性问题；
• 借助OpenTelemetry，高效的解决了 metrics、logs、traces 各个维度数据的关联性问题；

本位就来介绍一下使用 OpenTelemetry 如何实战部署应用，同时在一个可视化页面查看 trace、metric 等信息。

项目介绍

我们参考官方文档构建几个 Spring boot 、Golang 项目，再配合 Agent 其实也可以很方便的集成 OpenTelemetry。但是要完整的体验 OpenTelemetry 的所有功能，包含 trace、logs、metrics，还有社区这么多语言的支持其实还是比较麻烦的。

我们需要单独部署 collector、存储的 backend service 等组件（包括展示 trace 所需要的 Jaeger，展示 metric 所需要的 Grafana 等）。

这些所有东西都自己从头弄的话还是比较费时，不过好在社区已经将这些步骤都考虑到了。特地为大家写了一个 opentelemetry-demo。这个项目模拟了一个微服务版本的电子商城，主要包含了以下一些项目：

可以发现在这个 demo 中提供了许多的服务，而且包含了几乎所有主流的语言，可以很好的模拟我们实际的使用场景了。

整体来说前端所有的请求都会通过 frontend-proxy 这个组件代理，最终再由 frontend 这个服务进行转发到不同的后端服务中。

除了上面项目的架构图之外，还有一个关于 OpenTelemetry 的数据流转图，如下：

在 OpenTelemetry 中数据流转是它的特点也是非常重要的核心，这点在上一篇文章中讲过，用户可以自由定制数据的流转以及任意的处理数据，在这个图中就将数据流转可视化了。

1. 客户端可以通过 OTLP 协议或者是 HTTP 协议将数据上传到 OTel Collector 中；
2. 在 collector 中会根据我们配置的 Process pipeline 处理数据；
3. Metric 数据通过 OTLP HTTP exporter 将数据导出到 Prometheus 中（Prometheus 已经于 2023 年 7 月份支持 OTLP 格式的 metric 数据导入了）；
4. Trace 数据则是通过 OTLP Exporter 写入到 Jaeger 中进行存储，最后通过 Jaeger 的 UI 进行查询展示；
5. 存入 Prometheus 中的 metric 数据则是由 Grafana 进行展示；

关于 collector 的配置会在后文讲解。

部署

接下来便是安装 opentelemetry-demo 了，我更推荐使用 helm 安装。

这里的版本要求是：

• Kubernetes 1.24+
• Helm 3.9+

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
helm install my-otel-demo open-telemetry/opentelemetry-demo

这样就可以很简单的将 demo 所涉及到的所有组件和服务都安装到 default 命名空间中。

helm show values open-telemetry/opentelemetry-demo > demo.yaml

不过在安装前还是建议先导出一份 value.yaml，之后可以使用这个 yaml 定制需要安装的组件。

在这个 yaml 中我们可以看到有哪些组件和服务可以定制：

可以看到这里包含了我们刚才提到的所有服务，以及这些服务所依赖的 Kafka、redis、Prometheus 等中间件，都可以自己进行定制修改。

当所有的 Pod 都成功运行之后表示安装成功。

正常情况下安装不会有什么问题，最大可能的问题就是镜像拉取失败，此时我们可以先在本地手动 docker pull 下来镜像后再上传到私服，然后修改 deployment 中的镜像地址即可。

暴露服务

为了方便我们用这个 demo 进行测试，还需要将 frontend-proxy 的服务暴露出来可以在本地访问：

kubectl port-forward svc/my-otel-demo-frontendproxy 8080:8080

正常情况下就可以打开这些页面进行访问了。

不过使用 port-forward 转发的方式只是临时方案，使用 ctrl+c 就会停止暴露服务，所以如果想要一个稳定的访问链接时便可以配置一个 ingress。

components:
  frontendProxy:
    ingress:
      enabled: true
      annotations: {}
      hosts:
        - host: otel-demo.my-domain.com
          paths:
            - path: /
              pathType: Prefix
              port: 8080

在之前的 helm 的 value.yaml 中配置即可，本地测试的话需要将这个 host 和 ingress 暴露出来的 IP 进行绑定才可以使用这个域名机进行访问。

当然简单起见也可以直接将 front-proxy 的 service 类型改为 LoadBalancer（默认是 ClusterIP 只可以在集群内访问）

这样就可以直接通过这个 service 的 IP 进行访问了。

components:
  frontendProxy:
    service:
      type: LoadBalancer

不过需要注意的是如果 demo 安装完成之后是不可以再次修改 service 的类型的，需要手动删掉这个 service 之后再次新建才可以。

临时测试使用的话还是推荐直接使用 port-forward 进行转发。

查看 Trace

通过之前的项目架构图可以得知，我们在项目首页刷新会直接请求 AdService 来获取广告。

为了简单起见我们只查询这一链路的调用情况：

打开 http://localhost:8080/jaeger/ui/search Jaeger 的 UI 页面便可以筛选"service"，之后点击查找 Traces 就可以列出一段时间内的访问 trace。

可以看到这个请求链路是从前端访问到 adService 中的 getAds() 接口，然后在这个接口中再访问了 getAdsByCategory 函数。

最终在源码中也可以看到符合链路的调用代码：

在刚才的链路图的右下角有一个 spanID，整个 trace 是由这些小的 span 组成，每一个 span 也会有唯一 spanID；trace 也会有一个 traceID 将这些 span 串联起来；更多关于 trace 的内容会在后面的文章进行分析。

查看 Metrics

我们再打开 Grafana 便可以看到刚才访问的 adService 的延迟和接口的 QPS 情况：

在opentelemetry-collector-data-flow 面板中还可以看到 OpenTelemetry 的数据流转：

更多监控信息可以查看其它的面板。

而刚才面板中的数据流转规则则是在我们的 collector 中进行配置的：

receivers:
  otlp:
    protocols:
      grpc:
      http:
        cors:
          allowed_origins:
            - "http://*"
            - "https://*"
  httpcheck/frontendproxy:
    targets:
      - endpoint: http://frontendproxy:${env:ENVOY_PORT}

exporters:
  debug:
  otlp:
    endpoint: "jaeger:4317"
    tls:
      insecure: true
  otlphttp/prometheus:
    endpoint: "http://prometheus:9090/api/v1/otlp"
    tls:
      insecure: true
  opensearch:
    logs_index: otel
    http:
      endpoint: "http://opensearch:9200"
      tls:
        insecure: true

processors:
  batch:

connectors:
  spanmetrics:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp, debug, spanmetrics]
    metrics:
      receivers: [httpcheck/frontendproxy, otlp, spanmetrics]
      processors: [batch]
      exporters: [otlphttp/prometheus, debug]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [opensearch, debug]

重点的就是这里的 service.piplines，可以进行任意的组装。

更多关于 collector 的配置也会在后续文章中继续讲解。

我们也可以继续访问这个 demo 网站，模拟加入购物车、下单等行为，再结合 trace 和 metric 观察系统的变化。

这样一个完整的 OpenTelemetry-Demo 就搭建完毕了，我们实际在生产环境使时完全可以参考这个 demo 进行配置，可以少踩很多坑。

参考链接

• https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/adservice/Dockerfile
• https://github.com/open-telemetry/opentelemetry-demo
• https://github.com/prometheus/prometheus/pull/12571
• https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otelcollector/otelcol-config.yml

致谢

• 作者：crossoverJie
• 原文链接：https://mp.weixin.qq.com/s/f_aohbXsKTKzug1MjJSKQg

关于快猫星云和夜莺

夜莺 (Nightingale) 是一款开源云原生监控工具，是中国计算机学会接受捐赠并托管的第一个开源项目，在GitHub上有9000颗星，有数千家企业用户使用。快猫星云以开源夜莺为内核打造的“Flashcat平台”，是国内顶级互联⽹公司可观测性实践的产品化落地，我们致力于让可观测性技术更好的落地和发挥价值。你可以通过Flashcat平台，有效改善以下问题：

• 希望整个公司统一用一个工具，就可以支持指标、日志、链路追踪数据的采集、可视化、告警，免去搭建和维护多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
• 如果有在用多云，并且在多个公有云监控控制台来回切换不方便，希望监控数据、监控视图都是统一的，有更一致的用户体验，同时降低给所有的工程师开通公有云控制台权限带来的安全隐患。
• 告警太多，工作老被打断， 可以利用我们提供的 OnCall 值班平台（类似于 PagerDuty），支持告警聚合、降噪、认领、升级、排班，可以在飞书、钉钉、企微中接收和处理告警。

👉官方网站: https://flashcat.cloud

👉产品PPT: https://sourl.cn/LGYUyc

👉查看更多可观测性白皮书：https://flashcat.cloud/blog/whitepapers/