Nov 23 2023

云原生应用监控体系构建：Prometheus+Grafana+Loki全栈可观测性平台设计与实践

作者： 绝缘体..   发布： 2023-11-23 16:11   分类： 未分类   阅读：   抢沙发  
 
更多

云原生应用监控体系构建：Prometheus+Grafana+Loki全栈可观测性平台设计与实践

引言：云原生时代的可观测性挑战

随着微服务架构的普及和容器化技术（如Kubernetes）的广泛应用，现代应用系统的复杂度呈指数级增长。传统的单体应用监控方式已无法满足当前分布式系统的需求。一个典型的云原生应用可能由数十甚至上百个微服务组成，运行在动态变化的容器环境中，请求链路跨越多个服务、网络节点与外部依赖。

在这种背景下，可观测性（Observability） 成为保障系统稳定性和快速故障排查的核心能力。可观测性不再局限于简单的“是否在线”状态检测，而是深入到性能瓶颈分析、异常根因定位、容量规划支持等关键业务场景。它通常包含三大支柱：

  1. 指标（Metrics）：量化系统行为的时序数据，如CPU使用率、请求延迟、错误率。
  2. 日志（Logs）：结构化或非结构化的事件记录，用于追踪特定操作流程与错误上下文。
  3. 链路追踪（Tracing）：端到端的请求路径可视化，帮助理解跨服务调用的耗时分布与失败点。

为了应对这些挑战，业界逐渐形成以 Prometheus、Grafana 和 Loki 为核心的开源可观测性技术栈。该组合不仅具备高可扩展性、良好的社区生态和灵活的集成能力，还能够无缝对接 Kubernetes 等主流云原生平台，是构建企业级可观测性平台的理想选择。

本文将详细介绍如何从零开始搭建一套完整的 Prometheus + Grafana + Loki 全栈可观测性平台，涵盖部署架构设计、核心组件配置、数据采集策略、告警机制实现以及最佳实践建议，为开发者和运维工程师提供一份详尽的技术指南。

架构设计：构建统一的可观测性平台

整体架构概览

我们构建的可观测性平台采用分层解耦的设计思想，分为以下四个核心层级：

层级 组件 功能
数据采集层 Node Exporter, cAdvisor, Prometheus Agent, Fluent Bit, OpenTelemetry Collector 收集主机、容器、应用级别的指标与日志
指标存储层 Prometheus 高效存储和查询时间序列数据
日志处理层 Loki + Promtail 轻量级日志收集与索引服务
可视化与告警层 Grafana 提供统一仪表盘、告警管理与协作功能

整个架构基于 Kubernetes 部署，利用 Helm Chart 实现一键式安装与版本管理。所有组件均通过 ServiceMonitor 和 PodMonitor 自动发现机制接入 Prometheus，确保动态环境下的自动感知。

✅ 架构优势：

  • 弹性伸缩：各组件独立部署，可按需水平扩展。
  • 低侵入性：应用无需修改代码即可接入指标与日志。
  • 统一入口：Grafana 提供单一界面访问全部观测数据。
  • 长期保留：Loki 支持冷热数据分离，节省存储成本。

部署拓扑图（文字描述）

[Client Request]
       ↓
   [Ingress Controller]
       ↓
[Microservice A] → [Microservice B] → [Database]
       ↑        ↑
     [Prometheus] ← [Fluent Bit] ← [Node Exporter / cAdvisor]
         ↓
     [Grafana]
         ↓
   [Alertmanager] → [Email / Slack / Webhook]
  • Prometheus：负责拉取各服务暴露的 /metrics 接口，同时通过 ServiceMonitor 自动发现 Kubernetes 中的服务。
  • Fluent Bit：作为轻量级日志代理，采集 Pod 内部标准输出（stdout/stderr）并发送至 Loki。
  • Loki：接收日志流并建立索引，支持基于标签的高效查询。
  • Grafana：连接 Prometheus（指标）、Loki（日志）、Alertmanager（告警），构建统一视图。

💡 提示：对于生产环境，建议将 Prometheus 的远端写入（Remote Write）配置为 Thanos 或 Cortex，实现全局联邦与长期存储。

核心组件部署与配置详解

1. Prometheus 监控系统部署

使用 Helm 安装 Prometheus Operator

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.enabled=true \
  --set grafana.enabled=true \
  --set alertmanager.enabled=true \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
  --set prometheus.prometheusSpec.serviceMonitorSelector.matchLabels.app.kubernetes.io/name=app

📌 参数说明：

  • --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false：启用自定义 ServiceMonitor 选择器。
  • --set grafana.enabled=true：开启 Grafana 集成。
  • --set alertmanager.enabled=true：启用告警管理。

配置 ServiceMonitor 监控目标

创建 service-monitor.yaml 文件，定义对自定义应用的监控规则：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-web-service
  endpoints:
    - port: http-metrics
      path: /actuator/prometheus
      interval: 30s
      scheme: http
      tlsConfig:
        insecureSkipVerify: true

🔍 注意事项：

  • port 必须与 Pod 中定义的 port.name 一致。
  • 若使用 HTTPS，需配置 tlsConfig 并提供证书。
  • interval 控制拉取频率，默认 30 秒，可根据需求调整。

应用暴露指标示例（Spring Boot）

在 Spring Boot 项目中引入 Micrometer：

<!-- pom.xml -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

配置 application.yml：

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    prometheus:
      enabled: true
  metrics:
    export:
      prometheus:
        enabled: true

启动后访问 http://localhost:8080/actuator/prometheus 即可看到标准 Prometheus 指标格式输出。

2. Loki 日志系统部署

使用 Helm 安装 Loki + Promtail

helm install loki grafana/loki-stack \
  --namespace logging \
  --create-namespace \
  --set loki.enabled=true \
  --set promtail.enabled=true \
  --set promtail.config.client.url=http://loki.logging.svc.cluster.local:3100/loki/api/v1/push

Promtail 配置文件（config.yaml）

server:
  http_listen_port: 9080

clients:
  - url: http://loki.logging.svc.cluster.local:3100/loki/api/v1/push

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki.logging.svc.cluster.local:3100/loki/api/v1/push

# 采集所有 Pod 的 stdout/stderr 日志
logs:
  - pipeline_stages:
      - multiline:
          # 匹配以 "ERROR" 开头的行作为新日志开始
          firstline: '^\[.*\]\s*ERROR'
      - labels:
          job: kubernetes-pods
          __path__: /var/log/containers/$(POD_NAME)_$(CONTAINER_NAME)*.log
          namespace: $(POD_NAMESPACE)
          pod_name: $(POD_NAME)
          container_name: $(CONTAINER_NAME)
      - regex:
          expression: '^(?P<timestamp>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z) (?P<level>[A-Z]+) (?P<message>.*)'
      - timestamp:
          source: timestamp
          format: '2006-01-02T15:04:05.000Z'

⚠️ 重要提醒：

  • $(POD_NAME) 等变量由 Promtail 自动注入，依赖于 Kubernetes 的 Downward API。
  • 若日志未正确解析，请检查 regex 表达式是否匹配实际格式。
  • 建议使用 JSON 格式日志以提升解析效率。

Pod 注入日志采集（DaemonSet 方式）

创建 promtail-daemonset.yaml：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: promtail
  namespace: logging
spec:
  selector:
    matchLabels:
      app: promtail
  template:
    metadata:
      labels:
        app: promtail
    spec:
      serviceAccountName: promtail-sa
      containers:
        - name: promtail
          image: grafana/promtail:latest
          args:
            - -config.file=/etc/promtail/config.yaml
          volumeMounts:
            - name: config-volume
              mountPath: /etc/promtail
            - name: varlog
              mountPath: /var/log
            - name: run
              mountPath: /run
            - name: down
              mountPath: /etc/pod-info
      volumes:
        - name: config-volume
          configMap:
            name: promtail-config
        - name: varlog
          hostPath:
            path: /var/log/containers
        - name: run
          hostPath:
            path: /run
        - name: down
          downwardAPI:
            items:
              - path: "pod-name"
                fieldRef:
                  fieldPath: metadata.name
              - path: "pod-namespace"
                fieldRef:
                  fieldPath: metadata.namespace

✅ 最佳实践：将 configMap 与 DaemonSet 分离，便于独立更新配置而不重启 Pod。

3. Grafana 可视化与告警配置

启动 Grafana 并登录

通过 Ingress 或 Port Forward 访问 Grafana：

kubectl port-forward -n monitoring svc/grafana 3000:80

打开浏览器访问 http://localhost:3000，默认账号密码为 admin/admin。

添加数据源

  1. 进入 Configuration > Data Sources
  2. 添加 Prometheus 数据源：
    • URL: http://prometheus-operated.monitoring.svc.cluster.local:9090
    • 保存
  3. 添加 Loki 数据源：
    • URL: http://loki.logging.svc.cluster.local:3100
    • 保存

🔐 安全建议：生产环境应使用 Bearer Token 或 API Key 进行认证。

创建仪表盘模板

示例 1：基础服务器监控（Node Exporter）

使用内置模板 ID 1860（Node Exporter Full）或手动创建：

  • 面板 1：CPU 使用率 
    sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)
  • 面板 2：内存使用情况 
    (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100
  • 面板 3：磁盘 I/O 
    rate(node_disk_read_bytes_total[5m]) + rate(node_disk_written_bytes_total[5m])
示例 2：应用性能监控（APM）

假设你的应用暴露了如下指标：

  • http_server_requests_seconds_count{method="GET", status="200"}
  • http_server_requests_seconds_sum{method="GET", status="200"}
  • application_uptime_seconds

创建一个面板展示平均响应时间：

histogram_quantile(0.95, sum(rate(http_server_requests_seconds_bucket{job="my-app"}[5m])) by (le))

📈 建议：结合 rate() 和 sum() 对聚合后的指标进行滑动窗口计算，避免瞬时波动影响。

示例 3：日志搜索与分析

在 Grafana 中添加 Loki 查询面板：

{job="kubernetes-pods", namespace="default", pod_name=~"my-app.*"}
|~ "error|exception"
| json
| line_format "{{.message}}"
  • |~：正则过滤关键字
  • | json：解析 JSON 日志内容
  • | line_format：仅显示 message 字段

✅ 实战技巧：使用 group by 对日志按 container_name 或 pod_name 分组，便于快速定位问题 Pod。

告警规则设计与实战演练

Alertmanager 告警配置

创建告警规则文件（alerts.yaml）

groups:
  - name: application-alerts
    rules:
      - alert: HighRequestLatency
        expr: histogram_quantile(0.95, sum(rate(http_server_requests_seconds_bucket{job="my-app"}[5m])) by (le)) > 1.0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High latency in {{ $labels.job }} ({{ $labels.instance }})"
          description: "95th percentile request latency is {{ $value }} seconds, exceeding threshold of 1.0s."

      - alert: HighErrorRate
        expr: sum(rate(http_server_requests_seconds_count{job="my-app", status=~"5.."}[5m])) / sum(rate(http_server_requests_seconds_count{job="my-app"}[5m])) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "High error rate on {{ $labels.job }} ({{ $labels.instance }})"
          description: "Error rate exceeds 5% over the last 10 minutes."

      - alert: PodCrashLoopBackOff
        expr: kube_pod_status_phase{phase="Running", namespace="default"} == 0
        for: 15m
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.pod }} in CrashLoopBackOff state"
          description: "Pod has been restarting repeatedly. Check logs in Loki."

在 Prometheus 中加载规则

编辑 prometheus-values.yaml：

prometheus:
  prometheusSpec:
    ruleSelectorNilUsesHelmValues: false
    ruleNamespace: default
    additionalRules:
      - groups:
          - name: application-alerts
            rules:
              - alert: HighRequestLatency
                expr: ...
              - alert: HighErrorRate
                expr: ...

然后重新部署 Prometheus：

helm upgrade prometheus prometheus-community/kube-prometheus-stack -n monitoring -f prometheus-values.yaml

配置 Alertmanager 通知渠道

# alertmanager-config.yaml
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'alert@yourcompany.com'
  smtp_auth_username: 'alert@yourcompany.com'
  smtp_auth_password: 'your-app-password'

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'slack-notifications'

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#alerts'
        send_resolved: true
        text: '{{ range .Alerts }}*{{ .Labels.alertname }}* in {{ .Labels.instance }}: {{ .Annotations.description }}{{ end }}'

🔒 安全提示：不要在 YAML 中明文存储密码，建议使用 Kubernetes Secret 加密后挂载。

最佳实践与高级优化策略

1. 指标命名规范与标签设计

遵循 Prometheus 最佳实践，避免无意义的指标名：

✅ 正确示例：

http_server_requests_seconds_count{method="GET", status="200", job="my-app", instance="pod-123"}

❌ 错误示例：

request_count_abc123

📌 推荐标签：

  • job: 服务名称
  • instance: Pod 名称或 IP
  • namespace: Kubernetes 命名空间
  • pod: Pod 名称
  • container: 容器名称
  • status: HTTP 状态码
  • method: 请求方法

2. 日志结构化与 JSON 输出

强烈建议将应用日志输出为 JSON 格式，提高 Loki 解析效率：

{
  "timestamp": "2025-04-05T10:30:45.123Z",
  "level": "ERROR",
  "message": "Failed to connect to database",
  "trace_id": "a1b2c3d4e5f6",
  "user_id": "u789"
}

配合 Promtail 的 json 解析阶段，可轻松提取字段用于查询与告警。

3. 数据生命周期管理

Prometheus 存储优化

启用远程写入（Remote Write）至 Thanos：

prometheus:
  prometheusSpec:
    remoteWrite:
      - url: "https://thanos-receive.example.com/receive"
        queueConfig:
          maxSamplesPerSend: 1000
          maxShards: 100
          minBackoff: 30s
          maxBackoff: 10m

Loki 存储分层

使用 S3 或 MinIO 存储长期日志：

loki:
  storage:
    filesystem:
      chunks_directory: /tmp/chunks
      rules_directory: /tmp/rules
  storage_config:
    aws:
      bucket: your-logs-bucket
      region: us-east-1
      access_key_id: YOUR_ACCESS_KEY
      secret_access_key: YOUR_SECRET_KEY

📦 建议：冷数据归档至 S3，热数据保留在本地 SSD，降低成本。

4. 安全加固措施

安全项 建议
Prometheus 访问控制 使用 RBAC + OAuth2（如 Dex）
Grafana 登录 启用 LDAP/SSO 认证
Loki 传输加密 启用 HTTPS + TLS
Secret 管理 使用 Vault 或 KMS 加密敏感信息
网络隔离 将监控组件部署在独立命名空间，限制 ingress 访问

总结：迈向企业级可观测性

通过本文的完整实践，我们成功构建了一套基于 Prometheus + Grafana + Loki 的全栈可观测性平台。该平台具备以下核心能力：

  • ✅ 统一数据入口：集中采集指标、日志与链路追踪数据。
  • ✅ 动态发现机制：自动感知 Kubernetes 中新增或删除的 Pod。
  • ✅ 智能告警体系：基于业务逻辑设定多级告警规则，减少误报。
  • ✅ 高效可视化：Grafana 提供丰富的图表类型与联动能力。
  • ✅ 可扩展性强：支持远端写入、S3 存储、OpenTelemetry 集成。

未来可进一步拓展：

  • 引入 OpenTelemetry Collector 实现统一的遥测数据采集。
  • 集成 Jaeger 或 Tempo 实现分布式链路追踪。
  • 利用 Grafana Tempo + Loki + Prometheus 构建三合一可观测性平台。

🎯 终极目标：让每一个问题都能被快速发现、精准定位、高效解决 —— 这正是云原生时代可观测性的真正价值所在。

📌 附录：常用命令速查表

# 查看 Prometheus 指标
curl http://localhost:9090/metrics | grep http_server_requests

# 查看 Loki 日志
curl -X POST http://localhost:3100/loki/api/v1/push -d '{"streams": [{"stream": {"job": "kubernetes-pods"}, "values": [["1712345678000", "hello world"]] }]}'

# 查看 Promtail 日志
kubectl logs -n logging -l app=promtail

# 更新 Helm Chart
helm upgrade prometheus prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml

📚 推荐阅读：

  • Prometheus 官方文档
  • Grafana 官方文档
  • Loki 官方文档
  • 《Observability Engineering》by Charity Majors

作者声明：本文内容基于真实生产环境经验撰写，适用于 Kubernetes 上运行的云原生微服务系统。请根据实际需求调整参数与安全策略。

本文来自极简博客，作者：心灵画师，转载请注明原文链接：云原生应用监控体系构建：Prometheus+Grafana+Loki全栈可观测性平台设计与实践

打赏

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

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

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

  1. CVE-2021-35042
  2. 身份认证种类及攻击
  3. python安全脚本
  4. sqlmap源码分析(一)
  5. Python selenium ,一定要会用selenium的等待，三
  6. BUUCTF-[WebLogic]CVE-2018-2894（任意
  7. BUUCTF-[WebLogic]CVE-2017-10271（反
  8. mysql 配置ssl ，java应用连接
  9. 蜜罐学习
  10. golang并发扫描
  11. elasticsearch-映射
  12. APP模拟弱网测试-Fiddler+clumsy（windows平台
  13. AWS S3 存储桶管理：PHP SDK 教程
  14. git简易的命令行入门教程
  15. 通过K8S实现微服务架构的演进
  16. 使用Spring Boot Actuator实现应用监控

云原生应用监控体系构建：Prometheus+Grafana+Loki全栈可观测性平台设计与实践：等您坐沙发呢！

发表评论


快捷键：Ctrl+Enter