Opentelemetry-10-接入监控指标

2023-12-01 约 1218 字预计阅读 3 分钟

在之前的文章中，基本完成了opentelemetry可观测中：日志、链路、告警以及周边的类似于存储、拓扑等额外小功能。最重要的监控指标却没有接入opentelemetry，为什么之前没有接入呢，主要是因为在我们的集群中，已经有一套kube-prometheus了，没有那些必要再去接opentelemetry了，自给自足能够完成日常的监控需求。

那为什么现在又要做这个呢，因为我们公司最近的需求正好涉及到了这一块，简单描述一下需求，我们公司的系统今年开始做本地化交付了，那么除了系统本身之外呢，自然是要包含监控日志链路等日常提效的系统的。而我们客户那边大多无法提供我们线上这样庞大的kubernetes集群，支撑业务系统已然是紧紧巴巴了，已经容不下再一个可观测平台了，此时，我的领导遍让我提供对于可观测平台的交付方案，除了提供资源继续本地化以外，就有一种，以线上可观测平台为中心，各地交付的系统将数据集中到我们线上的opentelemetry来，这样一来，本地化需要部署的服务就不多了，为客户节省资源，实不实用再说，本篇就来说说技术实现。

架构图

前面我们知道，日志和链路是由opentelemetry-java-agent来做的，是由javaagent来push数据到opentelemetry，而对于Prometheus来说，则需要使用opentelemetry的一个Prometheus receiver来抓取metrics。在这套架构中，存在两类opentelemetry服务，一个作为中心，承载我们自己的业务可观测数据，其他的作为客户侧的类似于客户端，负责客户本地化的可观测数据的上报，以此来实现通过公网暴露的opentelemetry服务，接受客户侧的可观测数据，以使客户侧不必部署过多的服务占用资源，同时也能够保障客户侧的维护，便于研发排查问题。

配置

下面先看一下两个opentelemetry的配置：

客户侧opentelemetry

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


    receivers:
      prometheus:
        config:
          scrape_configs:
            - job_name: 'node-exporter'
              scrape_interval: 5s
              static_configs:
                - targets: ['node-exporter.monitoring:9100']
                  labels:
                    instance: "xje-new"
    exporters:
      otlphttp:
        endpoint: "http://10.0.0.42:30630"
    service:
      pipelines:
        metrics:
          receivers: [prometheus]
          exporters: [otlp/uptrace]

中心opentelemetry

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


    receivers:
      otlp:
        protocols:
          grpc:
          http:
    exporters:
      logging:
        loglevel: debug
      prometheusremotewrite:
        endpoint: http://10.0.0.42:30735/api/v1/write
    service:
      pipelines:
        metrics:
          receivers: [otlp]
          exporters: [logging, prometheusremotewrite]

remotewrite

因为我是使用的较低版本的kube-prometheus，这个功能还是future版本，需要手动开启，官方文档。

打开部署文件：kube-prometheus/manifests/prometheus-prometheus.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    app.kubernetes.io/component: prometheus
    app.kubernetes.io/instance: k8s
    app.kubernetes.io/name: prometheus
    app.kubernetes.io/part-of: kube-prometheus
    app.kubernetes.io/version: 2.32.1
  name: k8s
  namespace: monitoring
spec:
  alerting:
    alertmanagers:
    - apiVersion: v2
      name: alertmanager-main
      namespace: monitoring
      port: web
  # 这里
  enableFeatures:
  - remote-write-receiver
  externalLabels: {}
  image: quay.io/prometheus/prometheus:v2.32.1
  podMetadata:
    labels:
      app.kubernetes.io/component: prometheus
      app.kubernetes.io/instance: k8s
      app.kubernetes.io/name: prometheus
      app.kubernetes.io/part-of: kube-prometheus
      app.kubernetes.io/version: 2.32.1
  podMonitorNamespaceSelector: {}
  podMonitorSelector: {}
  probeNamespaceSelector: {}
  probeSelector: {}
  replicas: 1
  resources:
    requests:
      memory: 400Mi
  ruleNamespaceSelector: {}
  ruleSelector: {}
  retention: 1w
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceAccountName: prometheus-k8s
  serviceMonitorNamespaceSelector: {}
  serviceMonitorSelector: {}
  version: 2.32.1

这样配置之后，就可以从线上的Prometheus查询到客户侧的指标了

根据预设的label：env，来区分各个环境，由于metrics是一致的，当然也可以集中检阅，如下图：

到此，中心有了客户侧的数据源了，告警自然是水到渠成，可以根据instance分群告警，也可以一视同仁，具体需求，在有数据源的情况下，已经可以为所欲为了。

目录

Opentelemetry-10-接入监控指标

架构图

配置

客户侧opentelemetry

中心opentelemetry

remotewrite