当前位置：首页 > news >正文

基于Grafana Loki与Prometheus的日志与指标一体化监控平台实战经验分享

news 2025/9/15 5:41:29

监控平台封面

基于Grafana Loki与Prometheus的日志与指标一体化监控平台实战经验分享

1. 业务场景描述

在某大型互联网金融平台中，服务数量已突破200+，核心业务包括交易撮合、风控审核、结算清算等，日均请求峰值超过10万次/s。传统的指标监控采用Prometheus采集指标，日志分析依赖ELK Stack（Elasticsearch+Logstash+Kibana），两套系统分离，运维和开发团队切换成本高，故障排查效率低。

为提升监控效率，我们在生产环境中引入Grafana Loki，将日志与指标统一在Grafana中展示，实现告警、可视化和排障的一体化监控平台。

2. 技术选型过程

Prometheus：成熟的时序数据库和监控采集方案，支持Alertmanager告警。
Grafana：统一可视化平台，原生支持Prometheus和Loki。
Loki：由Grafana Labs推出的按标签存储日志系统，性能轻量、存储成本低，适合大规模日志采集。

对比分析：

| 特性 | ELK Stack | Grafana Loki | |--------------|-----------------------------------|-----------------------------------| | 存储成本 | 较高，索引占用大量空间 | 较低，无日志全文索引 | | 查询性能 | 高速全文检索，但索引更新消耗大 | 基于标签过滤，定位快速 | | 可视化 | Kibana | Grafana | | 维护成本 | 较高，需要管理Elasticsearch集群 | 较低，只需管理Loki和对象存储卷 |

最终选型：Prometheus + Grafana + Loki组合。

3. 实现方案详解

3.1 整体架构

架构图：

+----------------+        +--------------+        +---------------+
| 业务微服务     | ---->  | Prometheus   |        | Grafana       |
| （Exporters）  |        |              | -----> | (Metrics+Logs)|
+----------------+        +--------------+        +---------------+|                      |                       ^| 日志采集              |                        |v                      v                        |
+----------------+     +----------------+              |
| Promtail       | --> | Loki           |--------------+
+----------------+     +----------------+

Prometheus：对微服务、数据库、中间件等暴露/metrics端点进行抓取。
Promtail：部署在每台主机，tail日志文件并根据标签推送到Loki。
Loki：使用对象存储（如S3或分布式文件系统）持久化日志，按标签组织。
Grafana：统一仪表盘，告警规则基于Prometheus和Loki查询。

3.2 关键配置

3.2.1 Prometheus Scrape 配置 (prometheus.yml)

global:scrape_interval: 15sevaluation_interval: 15sscrape_configs:- job_name: 'microservices'kubernetes_sd_configs:- role: endpointsrelabel_configs:- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]action: keepregex: true- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]target_label: __metrics_path__regex: (.+)- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]target_label: __address__regex: ([^:]+)(?::\d+)?;(.+)replacement: $1:$2

3.2.2 Promtail 配置 (promtail-config.yaml)

server:http_listen_port: 9080grpc_listen_port: 0positions:filename: /var/log/positions.yamlclients:- url: http://loki:3100/loki/api/v1/pushscrape_configs:- job_name: systemstatic_configs:- targets:- localhostlabels:job: varlogs__path__: /var/log/*.log

3.2.3 Grafana 仪表盘示例

新建Dashboard，添加两类Panel：
- Metric 面板：PromQL 查询如 rate(http_requests_total[5m])
- Log 面板：Loki 查询如 {job="varlogs"} |= "ERROR" | logfmt
使用变量 & 关联查询：选中服务名变量${service}, 在面板中同时渲染指标和日志。

3.3 告警与协同

Alertmanager 配置：

groups:
- name: service-alertsrules:- alert: HighErrorRateexpr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05for: 2mlabels:severity: criticalannotations:summary: "{{ $labels.service }} 错误率过高"description: "最近5分钟错误率 > 5%"

警报触发后在Slack/邮件中附上Grafana链接，支持一键跳转到日志视图，快速定位问题。

4. 踩过的坑与解决方案

日志量爆炸：生产环境每分钟日志写入量达10GB，Loki默认内存缓存难以承受。
- 解决：调整Promtail batch_size为500KB，启用流量限制 max_batch_wait 为1s；Loki使用分片与对象存储分层写入。
标签维度过多：Promtail默认将日志文件路径等大量标签附带到日志，导致Loki索引膨胀。
- 解决：对scrape_configs中的labels进行精简，只保留service、instance、environment三类高维度标签。
Grafana仪表盘层级混乱：多个团队共用Dashboard时，Panel命名不规范。
- 解决：统一命名规范：[服务名] - [功能] - [类型]，并使用Grafana文件导入导出管理版本。