Prometheus：少走三年弯路

▌ 技术引导
Prometheus 在大规模微服务监控场景下，绝对不是拿来主义。我见过太多人直接用它，结果数据采集失灵、存储爆炸、告警误报，最后把整个监控系统折腾成渣。关键是没搞懂它的数据模型和采集机制，配置成一个万能的监控工具，反而成了系统负担。真实场景中，要根据服务类型、数据量、可用性要求定制采集策略，比如用 scrape_configs 配置 interval、bearer_token、relabel_configs，而不是一股脑全开。别想着用它简单监控，它本质上是采集+存储+查询三位一体的系统，需要从底层开始规划，否则监控数据就是一场狼人杀。还有，别用默认的 remote_write，它对网络吞吐和延迟敏感，建议配合 Loki 或 MinIO 做日志聚合，这样既节省资源又提升可追溯性。最后，别忘了 Prometheus 自带的 Alertmanager，它比第三方方案更稳定，但配置起来要小心别踩到传播机制的坑。

▌ 技术参考

一
Prometheus 的核心在于拉取式监控与时间序列数据库，适合容器化、Kubernetes、微服务场景。在部署时，记住 scrape_configs 的 interval 是关键参数，推荐根据服务健康状态设置为 10s 到 1m，高频率采集会加重服务负载。如果服务是 gRPC 或 HTTP，要用 prometheus_http_sd 指标发现，而不是静态配置，这样可以自动适应动态服务实例。某些服务需要 bearer_token 权限，比如 Kubernetes API，要通过 --bearer-token-file 参数挂载到 Prometheus 的配置中，否则会一直拉取失败。别用默认的 metrics 路径，有些服务可能配置在 /custom/metrics，要提前确认。

二
数据模型方面，Prometheus 使用标签（labels）来区分指标，但标签太多会导致存储膨胀，所以要控制标签数量。比如，在 Kubernetes 的 kube_pod_status_phase 指标中，标签如 namespace、pod、container 等是必须的，但像 node、host、ip 这些可选标签，如果服务正常节点信息足够，可以考虑在 relabel_configs 中过滤掉。同时，注意指标名称的标准化，避免重复。比如，同一服务的 CPU 使用率指标用 node_cpu_seconds_total 会更清晰，而不是随意命名。在 Prometheus 的配置中，设置 scrape_timeout 到 5s 能避免因网络抖动导致的采集失败，减少误报。

三
告警配置是 Prometheus 的核心痛点之一。我见过很多人直接用 alertmanager 配置发送邮件，结果没设置正确的 receiver 导致告警丢失，或者没用 group_by 把相同问题的告警合并，反而让监控人员被淹没。告警规则中，expr 一定要精确，比如用 rate(http_requests_total{job="api"}[1m]) > 0.5 来判断异常，而不是用简单的 increase(http_requests_total{job="api"}[1m])。另外，静默（silence）机制要提前配置好，比如当某个服务连续 5 分钟无响应时，自动静默告警，避免重复触发。Prometheus 的 expr 模板也要熟悉，比如用 avg_over_time 代替 avg，防止采集延迟导致的误判。

四
在 Kubernetes 环境中，Prometheus 的部署方式也需慎重。最好是用 prometheus-operator 来管理，它能自动发现服务，配置 serviceMonitor，这样就不需要手动写 scrape_configs。不过，serviceMonitor 的 selector 要精确，否则会采集到其他服务的数据。如果涉及多集群，可以使用 prometheus federation 来聚合数据，但要注意 federation 的性能瓶颈，比如查询延迟和 CPU 使用率。另外，Prometheus 的 storage 机制是本地磁盘，如果数据量太大，建议用 remote_write 指向 Loki 或 MinIO，这样可以做数据归档，节省存储空间，同时不影响查询性能。

五
数据存储方面，Prometheus 默认使用 TSDB，但它的吞吐能力有限，尤其在高并发场景下，本地磁盘写入可能会成为瓶颈。所以，要提前规划 remote_write 的配置，比如在 prometheus.yml 中设置 remote_write: [ { url: 'http://loki:3100/loki/api/v1/write', write_relabel_configs: [ { source_labels: [ '__name__', 'job' ], regex: '.', target_label: 'stream' } ] }, ]。Loki 的标签策略需要和 Prometheus 保持一致，否则无法正确归档。此外，Prometheus 的 retention 要根据业务需求设置，比如设置为 14d，如果业务数据量小，可以直接延长到 90d，但别贸然改，容易导致磁盘满。监控数据的生命周期管理要和团队的 SLA 对接，别让数据堆积到不可控。

六
如果服务是 gRPC 类型，Prometheus 的采集方式与 HTTP 不同，需要使用 grpc_server_stats 指标，但不是所有 gRPC 服务都支持。某些服务需要额外的依赖，比如 gRPC server 模块，或者修改服务代码，添加 metrics 注解。另外，gRPC 的监控指标往往会包含延迟、QPS、错误率等，要根据这些指标做告警。采集时建议用 grpc 作为 scrape_interval，同时设置 content_type 为 application/grpc。如果服务是 streaming 类型，要确保 Prometheus 能正确接收流式数据，避免采集中断。

七
在监控 Docker 容器时，Prometheus 的 container 指标可能不够全面，建议结合 node exporter 和 docker exporter 来补充。比如，用 docker_info 和 docker_container_cpu_usage_seconds_total 来获取容器的 CPU 使用情况。但 docker exporter 的采集方式是 push，对网络波动敏感，所以要确保它能稳定发送数据。此外，容器的标签和命名要统一，这样在 relabel_configs 中可以方便地过滤或合并数据。比如，用 job="docker" 来统一所有容器的采集，然后用 instance 标签来区分不同主机或节点。

八
对于高可用场景，Prometheus 的集群部署是必须的。使用 Prometheus Remote Write 和 Remote Read 能实现数据的多节点读写，但要注意其一致性模型，比如使用 raft 保证数据同步。配置时要确保所有节点的 scrape_configs 一致，避免数据不一致导致的误判。另外，Prometheus 的内存使用要监控，某些场景下，如果采集频率过高，会导致内存暴涨，进而触发 OOM。这时候可以调整 scrape_interval 到 30s 或 1m，或者用 prometheus 的 --storage.tsdb.min-block-duration 参数来平衡精度和资源消耗。

九
在用 Prometheus 监控日志时，要结合 Loki 的日志聚合能力，避免日志量过大导致数据丢失。Prometheus 本身不处理日志内容，所以需要在 Loki 中设置日志格式，比如用正则提取日志中的错误码、请求路径等，然后通过 Loki 的 label 机制来分类查询。比如在 Loki 的配置中，设置 scrape_config 为 { job_name: 'prometheus', honor_labels: true, relabel_configs: [ { source_labels: [ 'job', 'instance' ], target_label: 'cluster' } ] }，这样可以将日志统一归类到不同集群。同时，Loki 的 retention 和 query 的性能要根据日志量预估，避免查询慢导致的体验差。

十
在 Prometheus 的告警规则中，要避免使用过多的表达式嵌套，这会严重影响查询效率。比如，用 sum by (job) (avg_over_time(http_requests_total{job="api"}[1m])) 会比单独使用 avg_over_time 更加高效，因为减少了数据聚合的层级。同时，要合理设置 for 参数，比如 for: 5m，这样可以过滤掉短暂的波动，减少误报。对于 Kubernetes 的服务，可以结合 prometheus 的 serviceMonitor 和 kube-state-metrics 来获取节点状态，但要确保 serviceMonitor 的标签和 kube-state-metrics 的指标对齐，否则会采集到错误的数据。

十一
如果你在使用 Prometheus 的 Prometheus Pushgateway，必须注意它的数据保留和采集方式。pushgateway 是用来采集短生命周期任务的，比如 CronJob，但它的存储机制是内存，所以一旦服务重启，数据就会丢失。要避免在关键业务中使用 pushgateway，除非任务确实无法长期运行。另外，pushgateway 的 metrics 格式必须符合 Prometheus 的标准，否则采集失败。比如，用 pushgateway 的 curl 命令时，必须带上 --data-binary 参数，并指定正确的格式，或者用 prometheus 的 pushgateway 服务端来统一处理。

十二
对于 Prometheus 的可视化，Grafana 是最常用的选择，但要设置好数据源。在 Grafana 中，添加 Prometheus 数据源后，配置正确的 url 和 scrape_interval，确保数据能正常查询。某些场景下，Prometheus 的查询可以通过 PromQL 实现，比如用 topk(5, rate(http_requests_total{job="api"}[5m])) 来找出前五高并发的请求。但别忘记，PromQL 的性能与数据量有关，如果数据量太大，查询会变慢，甚至卡死。这时候可以考虑用 Prometheus 的预计算指标，比如在 remote_write 时添加预聚合的 metric，减少查询压力。

十三
Prometheus 的采集方式分为 pull 和 push，但 pull 是主流，因为更稳定。在 Kubernetes 环境中，确保每个服务都有对应的 serviceMonitor，这样 Prometheus 能自动发现服务并采集指标。如果服务没有暴露 metrics 端点，就只能用 pushgateway，但这样会增加部署复杂度。另外，Prometheus 的 scrape_configs 中，要使用 diskio 或 networkio 的指标，比如 node_disk_io_time_seconds_total，来监控磁盘和网络性能。这些指标需要在 node exporter 中配置，否则无法获取。

十四
在部署 Prometheus 时，要避免使用默认的目录结构，比如 /prometheus。这可能与主机的文件系统权限冲突，导致无法写入数据。建议手动指定 data_dir 参数，比如 --storage.tsdb.path=/data/prometheus，同时确保该目录有足够空间，并且是持久化存储。另外，Prometheus 的配置文件中，要开启 scrape_configs 的 metrics_path 和 scheme，比如 metrics_path: /metrics，scheme: http，避免因路径错误导致采集失败。如果服务使用 HTTPS，要配置 scrape_configs 的 basic_auth 或 bearer_token，否则会一直返回 401。

十五
别忽略 Prometheus 的内存管理，尤其是当采集量大的时候。默认配置下，Prometheus 会占用大量内存，甚至导致 OOM。这时候可以调整 --storage.tsdb.retention 和 --storage.tsdb.min-block-duration 参数，控制数据存储周期和块大小。对于长期存储，建议搭配 Loki 或 Cortex，但切换时要注意指标的兼容性。比如，Loki 的日志指标无法直接转换为 Prometheus 的 metric，需要额外的转换层。另外，在 Prometheus 的配置中，设置 --web.enable-admin-api=false 可以防止未授权访问，增强安全性和稳定性。