prometheus的核心价值在于以清晰职责边界构建低耦合、易定位、可扩展的数据链：采集层通过exporter+pull模式统一拉取指标；存储与查询层依托tsdb和promql支持多维分析；告警层由prometheus定义规则、alertmanager负责路由与通知；可视化层由grafana专注交互呈现。

Prometheus 监控系统的核心价值，不在于堆砌组件，而在于用清晰的职责边界把采集、存储、计算、告警和展示串成一条低耦合、易定位、可扩展的数据链。

采集层：用 Exporter 暴露指标，靠 Pull 模式统一管理

Prometheus 主动拉取数据，应用或基础设施只需暴露一个 /metrics HTTP 接口。不需要在业务代码里埋点或推送，也不依赖客户端稳定性。

• 通用主机指标用 node_exporter（CPU、内存、磁盘、网络）
• 数据库类用专用 Exporter：PostgreSQL 用 postgres_exporter，MySQL 用 mysqld_exporter
• 消息队列如 Kafka，用 kafka_exporter 拉取分区延迟、消费者滞后等关键状态
• 短生命周期任务（如 CronJob）走 Pushgateway 中转，避免指标丢失

所有目标都集中写在 prometheus.yml 的 scrape_configs 里，一目了然。Kubernetes 环境推荐用 Prometheus Operator + ServiceMonitor，自动发现 Pod，无需手动维护 IP 列表。

存储与查询层：TSDB + PromQL 构成分析基础

Prometheus 自带时序数据库（TSDB），按时间序列组织数据：指标名 + 标签集（如 http_requests_total{job="api", status="500"}）。这种结构天然支持多维下钻。

• Counter 类指标（如请求总数）用 rate() 或 increase() 算速率
• Gauge 类（如内存使用量）直接查瞬时值，适合阈值告警
• Histogram（如响应时间）配合 histogram_quantile() 计算 P95/P99 延迟
• 生产环境建议 scrape_interval: 15s，太短会显著增加存储压力和 CPU 开销

告警层：规则定义在 Prometheus，路由分发交给 Alertmanager

告警逻辑写在 Prometheus 的 alert.rules 文件中，用 PromQL 表达业务语义；Alertmanager 负责后续处理，两者解耦。

• 规则示例：100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90 表示 CPU 使用率超 90%
• Alertmanager 支持分组（相同服务的多个实例告警合并为一条）、抑制（如主机宕机时，自动抑制其上所有服务告警）、静默（维护期临时关闭）
• 通知渠道配置在 Alertmanager.yml 中，可同时发邮件、Slack、Webhook，不依赖 Grafana

可视化层：Grafana 连接 Prometheus，专注呈现与交互

Grafana 不存数据，只做查询和渲染。它通过数据源配置直连 Prometheus，仪表盘（Dashboard）本质是一组预设的 PromQL 查询 + 可视化样式。

• 推荐分层设计：顶层看全局 QPS/错误率/延迟，中层按服务或集群下钻，底层关联日志（Loki）或链路（Tempo）
• 变量（Variables）让面板具备交互能力，例如下拉选择 environment 或 service 标签动态刷新图表
• 内置的 Grafana Alerting 可替代 Alertmanager 做轻量告警，但复杂策略（如抑制、分级路由）仍建议用原生 Alertmanager

这套架构不复杂，但容易忽略标签设计和采集间隔这类细节。稳住采集源头，才能让后续每一步都可靠。