17370845950

Prometheus + Grafana 是 Python 微服务监控的黄金组合：前者采集存储指标，后者可视化与告警；需理清数据链路——从 Python 应用用 prometheus-client 暴露指标，到 Prometheus 抓取配置，再到 Grafana 建看板与 Alertmanager 设精准报警。

Prometheus + Grafana 是 Python 微服务监控的黄金组合：前者专注高效采集和存储指标，后者负责直观展示与灵活告警。关键不在堆功能，而在理清数据链路——从 Python 应用暴露指标，到 Prometheus 抓取，再到 Grafana 建图与设阈值报警。

让 Python 服务“说”出自己的状态

Python 微服务需主动暴露指标，最常用的是 prometheus-client 库。它不依赖框架，Flask、FastAPI、甚至纯 HTTP 服务都能快速接入。

• 安装：pip install prometheus-client
• 在服务启动时启动一个独立的指标暴露端点（如 :8001/metrics）：

from prometheus_client import start_http_server, Counter, Histogram
start_http_server(8001)  # 单独端口，不影响主业务

• 定义核心指标：请求计数（Counter）、响应延迟（Histogram）、错误率（用 Counter 或 Gauge 统计异常次数）
• 避免在请求处理路径中做耗时操作（如 DB 查询）来更新指标；优先用异步或预聚合方式

Prometheus 配置抓取你的 Python 服务

Prometheus 不自动发现服务，需手动配置 scrape_configs。微服务动态部署时，建议结合 Consul 或 Kubernetes Service Discovery，但起步可先写死：

scrape_configs:
  - job_name: 'python-api'
    static_configs:
      - targets: ['192.168.1.10:8001', '192.168.1.11:8001']

• 确保网络可达：Prometheus 能 curl 通目标 /metrics 端点，且返回格式为标准 Prometheus 文本协议
• 加 honor_labels: true 避免标签冲突；设 scrape_interval: 15s 平衡实时性与开销
• 用 Prometheus UI 的 Targets 页面 实时查看抓取状态和最近错误

Grafana 中建真正有用的看板

别一上来就套模板。从三个基础维度入手，每张图解决一个明确问题：

• 健康概览：显示各实例 up 状态（up{job="python-api"}），标红即失联
• 请求吞吐与延迟：用 rate(http_requests_total[5m]) 看 QPS，用 histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) 看 P95 延迟
• 错误突增：对比成功/失败请求数，例如 rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) 计算错误率

所有图表开启 Legend 显示服务名或实例 IP，避免“这根线是谁？”的困惑。

报警不是越多越好，而是要准、要可行动

用 Prometheus Alertmanager 管理报警，规则写在 alert.rules 文件里。只设三类真正需要人工介入的规则：

• 实例宕机：up == 0 for 2m —— 连续 2 分钟不可达才触发
• 延迟恶化：histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1.5 and avg_over_time(up[5m]) == 1 —— P95 延迟超 1.5 秒，且服务在线
• 错误率飙升：rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05 for 3m —— 错误率持续 3 分钟超 5%

每条报警 rule 必须带 summary 和 description 字段，说明影响范围和初步排查方向（如“检查下游 Redis 连接”），而不是只写“服务慢了”。