OpenTelemetry 實戰：從零實現應用指標監控
前言
在上一篇文章：OpenTelemetry 實戰：從零實現分布式鏈路追蹤講解了鏈路相關的實戰，本次我們繼續跟進如何使用 OpenTelemetry 集成 metrics 監控。
建議對指標監控不太熟的朋友可以先查看這篇前菜文章：從 Prometheus 到 OpenTelemetry：指標監控的演進與實踐
名稱 | 作用 | 語言 | 版本 |
java-demo | 發送 gRPC 請求的客戶端 | Java | opentelemetry-agent: 2.4.0/SpringBoot: 2.7.14 |
k8s-combat | 提供 gRPC 服務的服務端 | Golang | go.opentelemetry.io/otel: 1.28/ Go: 1.22 |
Jaeger | trace 存儲的服務端以及 TraceUI 展示 | Golang | jaegertracing/all-in-one:1.56 |
opentelemetry-collector-contrib | OpenTelemetry 的 collector 服務端，用于收集 trace/metrics/logs 然后寫入到遠端存儲 | Golang | otel/opentelemetry-collector-contrib:0.98.0 |
Prometheus | 作為 metrics 的存儲和展示組件，也可以用 VictoriaMetrics 等兼容 Prometheus 的存儲替代。 | Golang | quay.io/prometheus/prometheus:v2.49.1 |
快速開始
以上是加入 metrics 之后的流程圖，在原有的基礎上會新增一個 Prometheus 組件，collector 會將 metrics 指標數據通過遠程的 remote write 的方式寫入到 Prometheus 中。
Prometheus 為了能兼容 OpenTelemetry 寫入過來的數據，需要開啟相關特性才可以。
如果是 docker 啟動的話需要傳入相關參數：
docker run -d -p 9292:9090 --name prometheus \
-v /prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
quay.io/prometheus/prometheus:v2.49.1 \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/prometheus \
--web.console.libraries=/etc/prometheus/console_libraries \
--web.console.templates=/etc/prometheus/consoles \
--enable-feature=exemplar-storage \
--enable-feature=otlp-write-receiver--enable-feature=otlp-write-receiver 最主要的就是這個參數，用于開啟接收 OTLP 格式的數據。
但使用這個 Push 特性就會喪失掉 Prometheus 的許多 Pull 特性，比如服務發現，定時抓取等，不過也還好，Push 和 Pull 可以同時使用，原本使用 Pull 抓取的組件依然不受影響。
修改 OpenTelemetry-Collector
接著我們需要修改下 Collector 的配置:
exporters:
debug:
otlp:
endpoint: "jaeger:4317"
tls:
insecure: true
otlphttp/prometheus:
endpoint: http://prometheus:9292/api/v1/otlp
tls:
insecure: true
processors:
batch:
service:
pipelines:
traces:
receivers:
- otlp
processors: [batch]
exporters:
- otlp
- debug
metrics:
exporters:
- otlphttp/prometheus
- debug
processors:
- batch
receivers:
- otlp這里我們在 exporter 中新增了一個 otlphttp/prometheus 的節點，用于指定導出 prometheus 的 endpoint 地址。
同時我們還需要在 server.metrics.exporters 中配置相同的 key: otlphttp/prometheus。
需要注意的是這里我們一定得是配置在 metrics.exporters 這個節點下，如果配置在 traces.exporters 下時，相當于是告訴 collector 講 trace 的數據導出到 otlphttp/prometheus.endpoint 這個 endpoint 里了。
所以重點是需要理解這里的配對關系。
運行效果
這樣我們只需要將應用啟動之后就可以在 Prometheus 中查詢到應用上報的指標了。
java -javaagent:opentelemetry-javaagent-2.4.0-SNAPSHOT.jar \
-Dotel.traces.exporter=otlp \
-Dotel.metrics.exporter=otlp \
-Dotel.logs.exporter=none \
-Dotel.service.name=java-demo \
-Dotel.exporter.otlp.protocol=grpc \
-Dotel.propagators=tracecontext,baggage \
-Dotel.exporter.otlp.endpoint=http://127.0.0.1:5317 -jar target/demo-0.0.1-SNAPSHOT.jar
# Run go app
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:5317 OTEL_RESOURCE_ATTRIBUTES=service.name=k8s-combat
./k8s-combat因為我們在 collector 中開啟了 Debug 的 exporter，所以可以看到以下日志：
2024-07-22T06:34:08.060Z info MetricsExporter {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 18, "data points": 44}此時是可以說明指標上傳成功的。
然后我們打開 Prometheus 的地址：http://127.0.0.1:9292/graph便可以查詢到 Java 應用和 Go 應用上報的指標。
圖片
OpenTelemetry 的 javaagent 會自動上報 JVM 相關的指標。
而在 Go 程序中我們還是需要顯式的配置一些埋點：
func initMeterProvider() *sdkmetric.MeterProvider {
ctx := context.Background()
exporter, err := otlpmetricgrpc.New(ctx)
if err != nil {
log.Printf("new otlp metric grpc exporter failed: %v", err)
}
mp := sdkmetric.NewMeterProvider(
sdkmetric.WithReader(sdkmetric.NewPeriodicReader(exporter)),
sdkmetric.WithResource(initResource()),
) otel.SetMeterProvider(mp)
return mp
}
mp := initMeterProvider()
defer func() {
if err := mp.Shutdown(context.Background()); err != nil {
log.Printf("Error shutting down meter provider: %v", err)
}
}()和 Tracer 類似，我們首先也得在 main 函數中調用 initMeterProvider() 函數來初始化 Meter，此時它會返回一個 sdkmetric.MeterProvider 對象。
OpenTelemetry Go 的 SDK 中已經提供了對 go runtime 的自動埋點，我們只需要調用相關函數即可：
err := runtime.Start(runtime.WithMinimumReadMemStatsInterval(time.Second))
if err != nil {
log.Fatal(err)
}之后我們啟動應用，在 Prometheus 中就可以看到 Go 應用上報的相關指標了。
圖片
圖片
runtime_uptime_milliseconds_total Go 的運行時指標。
Prometheus 中展示指標的 UI 能力有限，通常我們都是配合 grafana 進行展示的。
圖片
手動上報指標
當然除了 SDK 自動上報的指標之外，我們也可以類似于 trace 那樣手動上報一些指標；
比如我就想記錄某個函數調用的次數。
var meter = otel.Meter("test.io/k8s/combat")
apiCounter, err = meter.Int64Counter(
"api.counter",
metric.WithDescription("Number of API calls."),
metric.WithUnit("{call}"),
)
if err != nil {
log.Err(err)
}
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
defer apiCounter.Add(ctx, 1)
return &pb.HelloReply{Message: fmt.Sprintf("hostname:%s, in:%s, md:%v", name, in.Name, md)}, nil
}只需要創建一個 Int64Counter 類型的指標，然后在需要埋點處調用它的函數 apiCounter.Add(ctx, 1) 即可。
圖片
之后便可以在 Prometheus 中查到這個指標了。
除此之外 OpenTelemetry 中的 metrics 定義和 Prometheus 也是類似的，還有以下幾種類型：
- Counter：單調遞增計數器，比如可以用來記錄訂單數、總的請求數。
- UpDownCounter：與 Counter 類似，只不過它可以遞減。
- Gauge：用于記錄隨時在變化的值，比如內存使用量、CPU 使用量等。
- Histogram：通常用于記錄請求延遲、響應時間等。
在 Java 中也提供有類似的 API 可以完成自定義指標：
messageInCounter = meter
.counterBuilder(MESSAGE_IN_COUNTER)
.setUnit("{message}")
.setDescription("The total number of messages received for this topic.")
.buildObserver();對于 Gauge 類型的數據用法如下，使用 buildWithCallback 回調函數上報數據，OpenTelemetry 會在框架層面每 30s 回調一次。
public static void registerObservers() {
Meter meter = MetricsRegistration.getMeter();
meter.gaugeBuilder("pulsar_producer_num_msg_send")
.setDescription("The number of messages published in the last interval")
.ofLongs()
.buildWithCallback(
r -> recordProducerMetrics(r, ProducerStats::getNumMsgsSent));
private static void recordProducerMetrics(ObservableLongMeasurement observableLongMeasurement, Function<ProducerStats, Long> getter) {
for (Producer producer : CollectionHelper.PRODUCER_COLLECTION.list()) {
ProducerStats stats = producer.getStats();
String topic = producer.getTopic();
if (topic.endsWith(RetryMessageUtil.RETRY_GROUP_TOPIC_SUFFIX)) {
continue;
} observableLongMeasurement.record(getter.apply(stats),
Attributes.of(PRODUCER_NAME, producer.getProducerName(), TOPIC, topic));
}}更多具體用法可以參考官方文檔鏈接：https://opentelemetry.io/docs/languages/java/instrumentation/#metrics
如果我們不想將數據通過 collector 而是直接上報到 Prometheus 中，使用 OpenTelemetry 框架也是可以實現的。
我們只需要配置下環境變量:
export OTEL_METRICS_EXPORTER=prometheus這樣我們就可以訪問 http://127.0.0.1:9464/metrics 獲取到當前應用暴露出來的指標，此時就可以在 Prometheus 里配置好采集 job 來獲取數據。
scrape_configs:
- job_name: "k8s-combat"
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ["k8s-combat:9464"]這就是典型的 Pull 模型，而 OpenTelemetry 推薦使用的是 Push 模型，數據由 OpenTelemetry 進行采集然后推送到 Prometheus。
這兩種模式各有好處：
Pull模型 | Push 模型 | |
優點 | 可以在一個集中的配置里管理所有的抓取端點，也可以為每一個應用單獨配置抓取頻次等數據。 | 在 OpenTelemetry 的 collector中可以集中對指標做預處理之后再將過濾后的數據寫入 Prometheus，更加的靈活。 |
缺點 | 1. 預處理指標比較麻煩，所有的數據是到了 Prometheus 后再經過relabel處理后再寫入存儲。 2. 需要配置服務發現 | 1. 額外需要維護一個類似于 collector 這樣的指標網關的組件 |
比如我們是用和 Prometheus 兼容的 VictoriaMetrics 采集了 istio 的相關指標，但里面的指標太多了，我們需要刪除掉一部分。
就需要在采集任務里編寫規則：
apiVersion: operator.victoriametrics.com/v1beta1
kind: VMPodScrape
metadata:
name: isito-pod-scrape
spec:
podMetricsEndpoints:
- scheme: http
scrape_interval: "30s"
scrapeTimeout: "30s"
path: /stats/prometheus
metricRelabelConfigs:
- regex: ^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum|istio_request_bytes_count|istio_response_bytes_sum|istio_request_bytes_sum|istio_request_duration_milliseconds_sum|istio_response_bytes_count|istio_request_duration_milliseconds_count|^ostrich_apigateway.*|istio_request_messages_total|istio_response_messages_total
action: drop_metrics
namespaceSelector:
any: true換成在 collector 中處理后，這些邏輯都可以全部移動到 collector 中集中處理。
總結
metrics 的使用相對于 trace 更簡單一些，不需要理解復雜的 context、span 等概念，只需要搞清楚有哪幾種 metrics 類型，分別應用在哪些不同的場景即可。
參考鏈接：
- https://prometheus.io/docs/prometheus/latest/feature_flags/#otlp-receiver
- https://opentelemetry.io/docs/languages/java/instrumentation/#metrics
- https://opentelemetry.io/docs/languages/go/instrumentation/#metrics
