Jul 15 2018

云原生应用监控体系构建：从Prometheus到Grafana的全链路可观测性实践

作者： 绝缘体..   发布： 2018-07-15 12:11   分类： 未分类   阅读：   抢沙发  
 
更多

云原生应用监控体系构建：从Prometheus到Grafana的全链路可观测性实践

随着微服务架构和容器化技术的普及，云原生应用的复杂性显著增加。传统的监控手段已难以满足现代分布式系统对**可观测性（Observability）的需求。可观测性不仅关注系统的“是否正常运行”，更强调通过指标（Metrics）、日志（Logs）和追踪（Traces）**三大支柱，深入理解系统的内部状态，快速定位问题并进行性能优化。

本文将围绕云原生环境下的监控体系建设，详细介绍如何基于 Prometheus、Grafana、ELK（Elasticsearch、Logstash、Kibana） 和 OpenTelemetry/Jaeger 构建一个完整的全链路可观测性平台。我们将涵盖架构设计、组件集成、配置实践及最佳建议，帮助开发者和运维团队实现高效、可扩展的监控体系。

一、云原生监控的挑战与可观测性三要素

1.1 云原生环境的监控挑战

在传统的单体应用中，系统拓扑简单，监控主要集中在服务器资源（CPU、内存、磁盘）和应用日志。然而，云原生环境下，应用通常由多个微服务组成，部署在 Kubernetes 集群中，服务之间通过 API 或消息队列通信，具有以下特点：

  • 高动态性：Pod 动态创建/销毁，IP 地址频繁变更
  • 服务拓扑复杂：调用链路长，跨服务调用频繁
  • 异构技术栈：不同服务可能使用不同语言、框架
  • 弹性伸缩：实例数量动态变化，传统静态监控难以覆盖

这些特性使得传统的监控方式难以有效追踪问题根源，亟需构建一个统一、自动化、可扩展的可观测性平台。

1.2 可观测性三大支柱

根据 CNCF（云原生计算基金会）定义，可观测性由三大核心数据类型构成：

类型 描述 工具示例
Metrics（指标） 数值型时间序列数据，用于监控系统状态（如 CPU 使用率、请求延迟） Prometheus、VictoriaMetrics
Logs（日志） 文本记录，记录事件发生的时间、上下文和详细信息 ELK、Loki、Fluentd
Traces（追踪） 分布式调用链路追踪，展示请求在多个服务间的流转路径 Jaeger、Zipkin、OpenTelemetry

三者相辅相成：Metrics 提供宏观趋势，Logs 提供具体事件细节，Traces 揭示调用关系。结合使用，可实现从“发现异常”到“定位根因”的完整闭环。

二、Prometheus：云原生指标监控的核心

2.1 Prometheus 架构与核心特性

Prometheus 是 CNCF 毕业项目，专为云原生环境设计的开源监控系统，具备以下核心特性：

  • 多维数据模型：基于时间序列，支持标签（labels）进行维度切片
  • Pull 模型采集：主动从目标服务拉取指标（通过 /metrics 接口）
  • 强大的查询语言 PromQL：支持复杂聚合、预测、告警
  • 服务发现机制：支持 Kubernetes、Consul、DNS 等动态发现目标
  • 高可用与联邦机制：支持多实例部署与数据聚合

2.2 部署 Prometheus（Kubernetes 环境）

使用 Helm 快速部署 Prometheus：

# 添加 Prometheus Helm 仓库
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 安装 Prometheus Stack（包含 Prometheus、Alertmanager、Grafana）
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
  --set grafana.adminPassword=yourpassword

该 Chart 部署了完整的监控栈，包括：

  • Prometheus Server
  • Alertmanager（告警管理）
  • Grafana（可视化）
  • Node Exporter（主机指标）
  • kube-state-metrics（Kubernetes 资源状态）

2.3 自定义指标暴露（Go 示例）

在应用中暴露自定义指标，需集成 Prometheus 客户端库。以 Go 为例：

package main

import (
	"net/http"
	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
	httpRequestsTotal = prometheus.NewCounterVec(
		prometheus.CounterOpts{
			Name: "http_requests_total",
			Help: "Total number of HTTP requests.",
		},
		[]string{"method", "endpoint", "status"},
	)

	httpRequestDuration = prometheus.NewHistogramVec(
		prometheus.HistogramOpts{
			Name:    "http_request_duration_seconds",
			Help:    "Histogram of HTTP request duration.",
			Buckets: prometheus.DefBuckets,
		},
		[]string{"method", "endpoint"},
	)
)

func init() {
	prometheus.MustRegister(httpRequestsTotal)
	prometheus.MustRegister(httpRequestDuration)
}

func handler(w http.ResponseWriter, r *http.Request) {
	start := prometheus.NewTimer(httpRequestDuration.WithLabelValues(r.Method, r.URL.Path))
	defer start.ObserveDuration()

	// 业务逻辑
	w.Write([]byte("Hello, Observability!"))

	httpRequestsTotal.WithLabelValues(r.Method, r.URL.Path, "200").Inc()
}

func main() {
	http.HandleFunc("/", handler)
	http.Handle("/metrics", promhttp.Handler())
	http.ListenAndServe(":8080", nil)
}

该代码暴露了两个指标：

  • http_requests_total：按方法、路径、状态码统计请求数
  • http_request_duration_seconds：请求耗时分布

2.4 ServiceMonitor 配置（Kubernetes）

为了让 Prometheus 自动发现并抓取应用指标，需创建 ServiceMonitor：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
    - port: web
      interval: 15s
      path: /metrics
  namespaceSelector:
    matchNames:
      - default

确保应用 Service 包含对应标签：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  ports:
    - name: web
      port: 8080
      targetPort: 8080
  selector:
    app: myapp

三、Grafana：统一可视化与告警平台

3.1 Grafana 的核心能力

Grafana 是开源的可视化平台，支持多数据源（Prometheus、Elasticsearch、Loki 等），提供：

  • 丰富的仪表盘（Dashboard）模板
  • 强大的查询与图形化能力
  • 告警规则配置（Alert Rules）
  • 多租户与权限管理

3.2 集成 Prometheus 数据源

在 Grafana 中添加 Prometheus 数据源：

  1. 进入 Configuration > Data Sources
  2. 选择 Prometheus
  3. URL 填写 http://prometheus-operated.monitoring.svc.cluster.local:9090
  4. 测试连接并保存

3.3 创建自定义仪表盘

使用 PromQL 查询指标并构建可视化图表。例如：

  • QPS（每秒请求数）：

    sum(rate(http_requests_total[1m])) by (endpoint)

  • P99 延迟：

    histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, method, endpoint))

  • 错误率：

    sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m]))

推荐使用 Grafana Dashboard 模板库 导入预置模板，如：

  • Kubernetes / Compute Resources / Cluster（集群资源）
  • Prometheus / Service Discovery（服务发现状态）

3.4 告警规则配置

在 Prometheus 中定义告警规则（通过 prometheusRules 或直接配置）：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: myapp-alert-rules
  namespace: monitoring
spec:
  groups:
    - name: myapp.rules
      rules:
        - alert: HighRequestLatency
          expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "High latency on {{ $labels.endpoint }}"
            description: "P99 latency is above 1s for more than 5 minutes."

告警将通过 Alertmanager 发送到邮件、Slack、企业微信等渠道。

四、日志收集与分析：ELK 栈实践

4.1 ELK 架构概述

ELK 是经典的日志处理栈：

  • Elasticsearch：分布式搜索引擎，存储和索引日志
  • Logstash：日志处理管道，支持过滤、转换
  • Kibana：日志可视化平台

在云原生环境中，更推荐使用 EFK（Elasticsearch + Fluentd + Kibana） 或 Loki + Promtail + Grafana，以降低资源开销。

4.2 部署 EFK（Helm 方式）

# 添加 Elastic Helm 仓库
helm repo add elastic https://helm.elastic.co
helm repo update

# 安装 Elasticsearch
helm install elasticsearch elastic/elasticsearch \
  --namespace logging \
  --create-namespace \
  --set replicas=1 \
  --set resources.requests.memory="1Gi"

# 安装 Kibana
helm install kibana elastic/kibana \
  --namespace logging \
  --set service.type=NodePort

# 安装 Fluentd（使用 Fluent Bit 更轻量）
helm install fluent-bit fluent/fluent-bit \
  --namespace logging \
  --set backend.type=es \
  --set backend.es.host=elasticsearch.logging.svc.cluster.local

4.3 日志格式标准化

建议应用输出结构化日志（JSON 格式），便于解析：

{
  "timestamp": "2024-04-05T10:00:00Z",
  "level": "INFO",
  "service": "user-service",
  "trace_id": "abc123",
  "message": "User login successful",
  "user_id": "12345"
}

Go 中可使用 zap 或 logrus 输出 JSON：

logger, _ := zap.NewProduction()
logger.Info("User login successful", zap.String("user_id", "12345"))

4.4 Kibana 查询示例

在 Kibana 中使用 KQL（Kibana Query Language）查询：

  • 查找错误日志：

    level: "ERROR"

  • 按服务过滤：

    service: "order-service"

  • 关联 trace_id：

    trace_id: "abc123"

五、分布式追踪：OpenTelemetry 与 Jaeger

5.1 分布式追踪原理

在微服务架构中，一个请求可能经过多个服务。分布式追踪通过 Trace ID 和 Span 记录调用链路：

  • Trace：一次完整请求的调用链
  • Span：单个服务内的操作单元
  • Context Propagation：跨服务传递追踪上下文（通过 HTTP Header）

5.2 部署 Jaeger

使用 Helm 安装 Jaeger：

helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm install jaeger jaegertracing/jaeger \
  --namespace tracing \
  --create-namespace \
  --set provisionDataStore.cassandra=false \
  --set storage.type=memory  # 生产环境建议使用 Elasticsearch

5.3 应用集成 OpenTelemetry（Go 示例）

package main

import (
	"context"
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/exporters/jaeger"
	"go.opentelemetry.io/otel/sdk/resource"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
	semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
)

func initTracer() (*sdktrace.TracerProvider, error) {
	exporter, err := jaeger.New(jaeger.WithAgentEndpoint())
	if err != nil {
		return nil, err
	}

	tp := sdktrace.NewTracerProvider(
		sdktrace.WithBatcher(exporter),
		sdktrace.WithResource(resource.NewWithAttributes(
			semconv.SchemaURL,
			semconv.ServiceNameKey.String("myapp"),
		)),
	)
	otel.SetTracerProvider(tp)
	return tp, nil
}

在 HTTP 请求中注入追踪头：

req, _ := http.NewRequest("GET", "http://service-b/api", nil)
req = req.WithContext(ctx)

// OpenTelemetry 自动注入 traceparent 头
client := http.DefaultClient
resp, _ := client.Do(req)

5.4 在 Grafana 中集成 Jaeger

Grafana 支持直接添加 Jaeger 作为数据源：

  • URL：http://jaeger-query.tracing.svc.cluster.local:16686
  • 支持在 Grafana 仪表盘中嵌入追踪面板，实现 Metrics + Traces 联动分析。

六、全链路可观测性平台整合

6.1 统一数据关联：Trace ID 贯穿三要素

为了实现“Metrics → Logs → Traces”联动，需在三者之间建立关联：

  • Metrics：在指标中添加 trace_id 标签（可选）
  • Logs：记录 trace_id
  • Traces：天然包含 trace_id

在 Grafana 中，可通过 Variable 或 Explore 模式联动查询：

  1. 在 Metrics 面板中发现高延迟请求
  2. 复制 trace_id
  3. 切换到 Jaeger 数据源，搜索该 trace_id
  4. 查看完整调用链
  5. 切换到 Loki 或 Elasticsearch，搜索该 trace_id 的日志

6.2 使用 Loki 替代 ELK（轻量级方案）

对于资源受限环境，推荐使用 Loki：

# values.yaml
loki:
  enabled: true
promtail:
  enabled: true
  lokiAddress: http://loki:3100/loki/api/v1/push

部署：

helm install loki grafana/loki-stack --namespace logging -f values.yaml

Loki 优势：

  • 仅索引日志元数据，不索引全文，节省存储
  • 与 Grafana 深度集成，查询语法类似 PromQL（LogQL）

LogQL 示例：

{namespace="default", container="myapp"} |= "ERROR" | json | user_id="12345"

七、最佳实践与运维建议

7.1 监控体系设计原则

  • 自动化发现：利用 Kubernetes 服务发现，避免手动配置
  • 分层监控：
    • 基础设施层（Node Exporter）
    • 平台层（kube-state-metrics）
    • 应用层（自定义指标）
  • 告警去重与分级：避免告警风暴，设置 warning 和 critical 级别
  • 长期存储：Prometheus 默认保留 15 天，生产环境建议对接 Thanos 或 Mimir 实现长期存储与查询

7.2 性能优化建议

  • 指标命名规范：使用 snake_case，前缀表示服务名，如 myapp_http_requests_total
  • 避免高基数标签：如 user_id 不应作为标签，否则导致时间序列爆炸
  • 合理设置 scrape interval：一般 15s，关键服务可设为 5s
  • 启用压缩与 TLS：保障传输安全与带宽效率

7.3 安全与权限

  • Prometheus 和 Grafana 启用身份认证（OAuth、LDAP）
  • 敏感指标打码或脱敏
  • 网络策略限制 Prometheus 只能访问特定端口

八、总结

构建云原生应用的可观测性体系，不仅是技术选型的组合，更是对系统稳定性、可维护性和快速响应能力的全面提升。通过 Prometheus + Grafana + ELK/Loki + OpenTelemetry/Jaeger 的组合，我们能够实现：

  • 全面的指标监控：实时掌握系统性能
  • 高效的日志分析：快速定位异常事件
  • 清晰的调用追踪：还原分布式请求路径
  • 统一的可视化平台：实现多维度数据联动分析

未来，随着 OpenTelemetry 成为标准，可观测性将更加标准化、自动化。建议团队尽早引入可观测性实践，将监控作为“一等公民”纳入 CI/CD 流程，真正实现“可观测即代码”（Observability as Code）。

延伸阅读：

  • Prometheus 官方文档
  • Grafana Labs 博客
  • OpenTelemetry 规范
  • 《Site Reliability Engineering》——Google SRE 实践

标签：云原生, 监控, Prometheus, Grafana, 可观测性

本文来自极简博客，作者：温柔守护，转载请注明原文链接：云原生应用监控体系构建：从Prometheus到Grafana的全链路可观测性实践

打赏

本文固定链接: https://www.cxy163.net/archives/9268 | 绝缘体

该日志由 绝缘体.. 于 2018年07月15日 发表在 未分类 分类下， 你可以发表评论，并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 云原生应用监控体系构建：从Prometheus到Grafana的全链路可观测性实践 | 绝缘体
关键字: , , , ,
【上一篇】
【下一篇】

您可能还会对这些文章感兴趣！

  1. CVE-2021-35042
  2. 身份认证种类及攻击
  3. go语言编译过程概述
  4. golang内存对齐分析(转载)
  5. DOS攻击(一)
  6. python安全脚本
  7. docker进阶_dockerswarm
  8. CDN绕过
  9. sqlmap源码分析(一)
  10. python黑帽子(第二章)
  11. docker基础_网络模式
  12. php的password_hash方法详解
  13. Python selenium ,一定要会用selenium的等待，三
  14. BUUCTF-[WebLogic]CVE-2018-2894（任意
  15. BUUCTF-[WebLogic]CVE-2017-10271（反
  16. 蜜罐学习

云原生应用监控体系构建：从Prometheus到Grafana的全链路可观测性实践：等您坐沙发呢！

发表评论


快捷键：Ctrl+Enter