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 连接”），而不是只写“服务慢了”。
