WEBKT

打通 Prometheus 与 ELK：告别手动排查，提升问题定位效率

65 0 0 0

Prometheus + ELK 的痛点：信息孤岛

目前很多系统都采用 Prometheus 做指标监控，ELK 做日志收集。但当 Prometheus 告警服务 CPU 飙升时，往往需要手动去 ELK 中搜索相关日志，大海捞针般地猜测是哪个请求导致的，效率低下。如果能从 Prometheus 的告警或图表面板直接跳转到相关的请求链路和日志，问题定位效率将大大提高。

解决方案：指标与日志关联

核心思路是将 Prometheus 的指标与 ELK 的日志关联起来。具体可以采用以下几种方法：

  1. Trace ID 传递： 在请求链路中传递 Trace ID。例如，可以使用 Jaeger、Zipkin 等链路追踪系统生成 Trace ID，并将其添加到 HTTP Header 或 gRPC Metadata 中。应用程序在记录日志时，将 Trace ID 写入日志。Prometheus 监控指标也需要采集这个 Trace ID。

  2. 日志关联字段： 约定一些公共的关联字段，例如服务名、主机名、实例 ID 等。Prometheus 的监控指标和 ELK 的日志都包含这些字段。

  3. Grafana 数据源配置： 利用 Grafana 的数据源配置，将 Prometheus 和 Elasticsearch 作为数据源添加到 Grafana 中。

实现步骤：以 Trace ID 为例

以下以 Trace ID 传递为例，说明如何实现 Prometheus 和 ELK 的联动：

  1. 引入链路追踪： 使用 Jaeger 或 Zipkin 等链路追踪系统，在你的服务中引入链路追踪功能。确保每个请求都有唯一的 Trace ID。

  2. 修改日志格式： 修改你的日志格式，将 Trace ID 写入日志。例如，使用 Logback 或 Log4j 等日志框架，配置 Pattern Layout，添加 %X{traceId}。

    <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg %X{traceId}%n</pattern>

  3. Prometheus 采集 Trace ID： 通过 Prometheus 的 Exporter 或 Client Library，采集包含 Trace ID 的指标。例如，如果你的服务使用 HTTP 接口，可以使用 http_server_requests_seconds 指标，并添加 trace_id label。

  4. 配置 Grafana：

    • 添加 Prometheus 数据源。
    • 添加 Elasticsearch 数据源。
    • 在 Grafana 中创建 Dashboard，使用 Prometheus 数据源展示指标，例如 CPU 使用率。
    • 为 CPU 使用率的图表添加 Drilldown 链接，链接到 Elasticsearch 的 Discover 页面。链接中使用变量 $__data.context.series.labels.trace_id，将 Prometheus 指标中的 Trace ID 传递给 Elasticsearch。
    /app/kibana#/discover?_g=(filters:!((query:(match_all:())),refreshInterval:(pause:!t,value:0))&_a=(columns:!(_source),index:'your_index_pattern',interval:auto,query:(language:lucene,query:'traceId:"${__data.context.series.labels.trace_id}"'),sort:!('@timestamp',desc))

效果

配置完成后，当你在 Grafana 中查看 Prometheus 的 CPU 使用率图表时，可以直接点击图表跳转到 Elasticsearch 中，查看与该 CPU 使用率相关的日志，快速定位问题。

总结

通过将 Prometheus 的指标与 ELK 的日志关联起来，可以大大提高问题定位效率。本文提供了一种基于 Trace ID 的解决方案，你可以根据自己的实际情况选择合适的方案。希望本文能帮助你更好地利用 Prometheus 和 ELK，提升运维效率。

监控侠 PrometheusELK监控告警

评论点评