Prometheus
Prometheus 是一个开源的监控和报警工具集，它最初是由 SoundCloud 创建的，现在是云原生计算基金会（CNCF）下的一个项目。Prometheus 被设计用于监控和报警在动态容器环境中的多个服务，但它同样适用于传统的硬件和软件监控。
查看更多相关内容
Prometheus 的 Recording Rules 和 Alerting Rules 有什么区别？Prometheus Recording Rules 和 Alerting Rules 的区别和使用：
**Recording Rules（记录规则）**：
- 预先计算并存储常用的查询结果
- 提高查询性能，减少计算开销
- 不会触发告警
**配置示例**：
```yaml
groups:
- name: api_recording_rules
interval: 30s
rules:
- record: job:http_requests:rate5m
expr: sum by (job) (rate(http_requests_total[5m]))
- record: job:request_errors:rate5m
expr: sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
```
**使用场景**：
- 频繁查询的复杂表达式
- 需要聚合多个指标的计算
- 提高仪表盘加载速度
- 减少实时查询压力
**Alerting Rules（告警规则）**：
- 监控指标并触发告警
- 支持告警分组、抑制、静默
- 发送通知到 Alertmanager
**配置示例**：
```yaml
groups:
- name: api_alerting_rules
rules:
- alert: HighErrorRate
expr: job:request_errors:rate5m / job:http_requests:rate5m > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate on {{ $labels.job }}"
description: "Error rate is {{ $value | humanizePercentage }}"
```
**关键区别**：
| 特性 | Recording Rules | Alerting Rules |
|------|----------------|----------------|
| 目的 | 预计算查询结果 | 触发告警通知 |
| 存储 | 生成新的时间序列 | 不存储新序列 |
| 性能 | 提高查询性能 | 可能增加评估开销 |
| 使用 | 仪表盘、查询 | 监控、告警 |
**最佳实践**：
1. **Recording Rules**：
- 使用有意义的命名规范
- 合理设置评估间隔
- 定期审查和清理无用规则
- 使用 `by` 子句进行分组
2. **Alerting Rules**：
- 合理设置 `for` 参数避免误报
- 使用分级告警（info、warning、critical）
- 添加清晰的描述信息
- 使用标签便于分组和路由
3. **规则管理**：
- 使用版本控制管理规则文件
- 使用 `promtool` 检查规则语法
- 测试规则后再部署
- 监控规则评估性能
**验证规则**：
```bash
promtool check rules /path/to/rules.yml
```
服务端 · 2月21日 15:41
如何优化 Prometheus 的存储和性能？Prometheus 存储优化和性能调优策略：
**数据保留策略**：
```yaml
storage:
tsdb:
retention.time: 15d
retention.size: 10GB
```
- 根据磁盘空间和查询需求设置保留时间
- 使用 `retention.size` 限制磁盘使用
**采集优化**：
- 合理设置 `scrape_interval`（推荐 15s-60s）
- 使用 `scrape_timeout` 避免慢查询
- 对不重要的指标设置更长的采集间隔
- 使用 `metric_relabel_configs` 过滤不需要的指标
**查询优化**：
- 避免全量查询，使用标签过滤
- 合理选择时间窗口大小
- 使用 Recording Rules 预计算常用查询
- 分散查询时间，避免高峰期
**内存优化**：
- 调整 `--storage.tsdb.retention.time`
- 使用 `--storage.tsdb.head-chunks.write-queue-size` 控制写入队列
- 监控内存使用，及时清理旧数据
- 考虑使用 Thanos 或 VictoriaMetrics 进行长期存储
**Recording Rules 示例**：
```yaml
groups:
- name: api_rules
rules:
- record: job:http_requests:rate5m
expr: sum by (job) (rate(http_requests_total[5m]))
```
**监控 Prometheus 自身**：
- `prometheus_tsdb_compaction_duration`
- `prometheus_tsdb_head_samples_appended_total`
- `prometheus_target_interval_length_seconds`
**最佳实践**：
- 定期清理不需要的指标
- 使用联邦架构分散负载
- 考虑使用 remote write 分离热冷数据
服务端 · 2月21日 15:40
在生产环境中使用 Prometheus 有哪些最佳实践？Prometheus 在生产环境中的最佳实践：
**架构设计**：
1. **高可用部署**：
- 部署多个 Prometheus 实例
- 使用 Thanos 或 Cortex 实现长期存储
- 配置负载均衡分散查询压力
2. **资源规划**：
```yaml
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "8Gi"
cpu: "4"
```
3. **数据保留策略**：
```yaml
storage:
tsdb:
retention.time: 15d
retention.size: 50GB
```
**监控指标设计**：
1. **命名规范**：
- 使用下划线分隔
- 包含应用名称
- 使用标准单位（bytes、seconds）
- 示例：`http_requests_total`、`memory_usage_bytes`
2. **标签设计**：
- 使用有意义的标签
- 避免高基数标签
- 保持标签一致性
- 示例：`job="api"`, `instance="10.0.0.1:9090"`
3. **指标类型选择**：
- Counter：累计值（请求数、错误数）
- Gauge：瞬时值（内存、CPU）
- Histogram：分布统计（延迟、响应大小）
- Summary：客户端分位数
**告警策略**：
1. **分级告警**：
```yaml
- alert: CriticalError
expr: error_rate > 0.1
labels:
severity: critical
- alert: WarningError
expr: error_rate > 0.05
labels:
severity: warning
```
2. **告警抑制**：
```yaml
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'instance']
```
3. **告警路由**：
```yaml
route:
group_by: ['alertname', 'cluster']
group_wait: 10s
group_interval: 10s
repeat_interval: 12h
receiver: 'default'
routes:
- match:
severity: critical
receiver: 'pagerduty'
```
**安全配置**：
1. **认证和授权**：
```yaml
basic_auth:
username: admin
password: ${PROMETHEUS_PASSWORD}
```
2. **TLS 加密**：
```yaml
tls_config:
cert_file: /etc/prometheus/certs/server.crt
key_file: /etc/prometheus/certs/server.key
client_ca_file: /etc/prometheus/certs/ca.crt
```
3. **网络安全**：
- 使用防火墙限制访问
- 配置 Kubernetes NetworkPolicy
- 使用 VPN 或私有网络
**运维管理**：
1. **配置管理**：
- 使用版本控制（Git）
- 使用 Helm 或 Operator 部署
- 实施变更审核流程
2. **备份策略**：
```bash
# 定期备份配置和数据
promtool tsdb snapshot /var/lib/prometheus/ /backup/
```
3. **监控 Prometheus 自身**：
```promql
# 健康状态
up{job="prometheus"}
# 性能指标
prometheus_tsdb_head_samples_appended_total
prometheus_query_duration_seconds_sum
# 存储指标
prometheus_tsdb_storage_blocks_bytes
```
**性能优化**：
1. **采集优化**：
- 合理设置采集间隔
- 使用 Recording Rules
- 过滤不需要的指标
2. **查询优化**：
- 使用预计算规则
- 限制查询时间范围
- 使用标签过滤
3. **存储优化**：
- 配置数据压缩
- 定期清理旧数据
- 使用外部存储
**文档和培训**：
1. **文档化**：
- 监控架构文档
- 告警规则说明
- 故障处理流程
- 运维手册
2. **培训**：
- 团队培训计划
- 值班轮换制度
- 应急演练
**持续改进**：
1. **定期审查**：
- 审查告警规则
- 优化查询性能
- 清理无用指标
2. **性能监控**：
- 监控资源使用
- 分析查询性能
- 优化存储策略
3. **安全审计**：
- 定期安全检查
- 更新依赖版本
- 审查访问权限
服务端 · 2月21日 15:40
如何在微服务架构中使用 Prometheus 进行监控？Prometheus 在微服务架构中的监控实践：
**服务网格监控（Istio/Linkerd）**：
- 利用 Sidecar 代理收集指标
- 监控服务间调用关系
- 追踪请求链路
- 配置示例：
```yaml
scrape_configs:
- job_name: 'istio-pilot'
kubernetes_sd_configs:
- role: endpoints
namespaces:
names: [istio-system]
relabel_configs:
- source_labels: [__meta_kubernetes_service_name]
action: keep
regex: istio-pilot
```
**分布式追踪集成**：
- 使用 OpenTelemetry 收集指标
- 与 Jaeger/Zipkin 集成
- 关联追踪和监控数据
**服务依赖关系监控**：
```promql
# 服务间调用延迟
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket[5m])) by (le, source, target)
)
# 服务错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/ sum(rate(http_requests_total[5m])) by (service)
```
**金丝雀发布监控**：
- 使用标签区分版本
- 对比新旧版本性能
- 自动回滚告警
**配置示例**：
```yaml
# 使用版本标签
scrape_configs:
- job_name: 'api'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_version]
target_label: version
```
**SLA/SLO 监控**：
```promql
# 错误率 SLO
sum(rate(http_requests_total{status=~"5.."}[30d])) by (service)
/ sum(rate(http_requests_total[30d])) by (service) < 0.01
# 延迟 SLO
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket[30d])) by (le, service)
) < 0.5
```
**最佳实践**：
1. **统一命名规范**：
- 使用标准化的指标名称
- 保持标签一致性
- 文档化指标含义
2. **服务级别指标**：
- RED 方法：Rate（请求率）、Errors（错误率）、Duration（延迟）
- USE 方法：Utilization（利用率）、Saturation（饱和度）、Errors（错误）
3. **自动化监控**：
- 通过注解自动发现服务
- 使用 Operator 自动配置
- 基础设施即代码
4. **告警策略**：
- 分级告警（P0/P1/P2/P3）
- 告警抑制和聚合
- 值班轮换和升级策略
服务端 · 2月21日 15:40
如何在 Kubernetes 环境中部署和使用 Prometheus？Prometheus 在 Kubernetes 环境中的部署和使用：
**部署方式**：
1. **Helm Chart 部署**（推荐）：
```bash
helm install prometheus prometheus-community/kube-prometheus-stack
```
2. **Operator 部署**：
- 使用 Prometheus Operator 简化管理
- 提供 CRD：Prometheus、Alertmanager、ServiceMonitor 等
**关键组件**：
- **Prometheus**：主监控服务
- **Node Exporter**：节点指标采集
- **Kubelet Metrics**：容器和 Pod 指标
- **cAdvisor**：容器资源使用
- **Kube-State-Metrics**：Kubernetes 对象状态
**ServiceMonitor 配置**：
```yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app
spec:
selector:
matchLabels:
app: my-app
endpoints:
- port: metrics
interval: 30s
```
**常用指标**：
- 容器资源：`container_cpu_usage_seconds_total`
- Pod 状态：`kube_pod_status_phase`
- 节点资源：`node_memory_MemAvailable_bytes`
- 网络流量：`container_network_receive_bytes_total`
**自动发现配置**：
```yaml
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
```
**最佳实践**：
- 使用命名空间隔离监控数据
- 配置资源限制避免影响业务
- 使用 PersistentVolume 持久化数据
- 定期备份配置和数据
- 结合 Grafana 创建仪表盘
服务端 · 2月21日 15:40
如何配置 Prometheus 告警规则和 Alertmanager？Prometheus 告警配置和 Alertmanager 使用：
**告警规则配置**：
```yaml
groups:
- name: example_alerts
rules:
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage on {{ $labels.instance }}"
description: "CPU usage is {{ $value }}%"
```
**关键字段**：
- `expr`：告警表达式
- `for`：持续满足条件的时间
- `labels`：告警标签
- `annotations`：告警描述
**Alertmanager 配置**：
```yaml
route:
group_by: ['alertname', 'cluster']
group_wait: 10s
group_interval: 10s
repeat_interval: 12h
receiver: 'default'
receivers:
- name: 'default'
email_configs:
- to: 'alert@example.com'
from: 'prometheus@example.com'
webhook_configs:
- url: 'http://webhook.example.com/alert'
```
**告警分组**：
- `group_by`：按标签分组
- `group_wait`：等待时间，合并同组告警
- `group_interval`：组内告警间隔
- `repeat_interval`：重复通知间隔
**告警抑制**：
```yaml
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'instance']
```
**告警静默**：
- 通过 API 创建静默规则
- 支持时间范围和匹配器
- 适用于维护窗口
**最佳实践**：
- 合理设置告警阈值，避免告警疲劳
- 使用分级告警（info、warning、critical）
- 定期审查和优化告警规则
- 结合 Grafana 进行可视化告警
服务端 · 2月21日 15:40
Prometheus 与 Zabbix、Nagios 等监控系统有什么区别？Prometheus 与其他监控系统的对比：
**与 Zabbix 对比**：
| 特性 | Prometheus | Zabbix |
|------|-----------|--------|
| 架构 | Pull 模式 | Push/Pull 混合 |
| 数据模型 | 时间序列 | 关系型数据库 |
| 查询语言 | PromQL | Zabbix 查询语言 |
| 可视化 | 需配合 Grafana | 内置 |
| 告警 | Alertmanager | 内置 |
| 自动发现 | 丰富 | 丰富 |
| 适用场景 | 云原生、容器化 | 传统 IT 基础设施 |
**与 Nagios 对比**：
- Prometheus：主动采集，适合动态环境
- Nagios：被动检查，适合静态环境
- Prometheus：原生支持容器
- Nagios：需要插件支持
**与 InfluxDB 对比**：
- Prometheus：专注监控，Pull 模式
- InfluxDB：通用时序数据库，Push 模式
- Prometheus：内置服务发现
- InfluxDB：需要外部集成
**与 Datadog 对比**：
- Prometheus：开源免费
- Datadog：商业 SaaS，收费
- Prometheus：需要自行维护
- Datadog：托管服务，开箱即用
- Prometheus：高度可定制
- Datadog：集成度高，使用简单
**与 ELK Stack 对比**：
- Prometheus：数值型指标监控
- ELK：日志分析
- Prometheus：结构化数据
- ELK：非结构化文本
- 两者可互补使用
**选择建议**：
**选择 Prometheus 当**：
- 使用 Kubernetes 或容器化部署
- 需要云原生监控解决方案
- 预算有限，需要开源方案
- 需要灵活的查询和告警
- 团队有运维能力
**选择 Zabbix 当**：
- 监控传统 IT 基础设施
- 需要内置的告警和可视化
- 团队熟悉 Zabbix
- 需要网络设备监控
**选择 Datadog 当**：
- 预算充足
- 需要快速部署
- 需要全栈监控（APM、日志、指标）
- 团队规模较小，运维能力有限
**混合方案**：
- Prometheus + Thanos：长期存储
- Prometheus + Grafana：可视化
- Prometheus + Alertmanager：告警
- Prometheus + Loki：日志关联
服务端 · 2月21日 15:40
如何将 Prometheus 与 Grafana 集成，有哪些最佳实践？Prometheus 与 Grafana 的集成和最佳实践：
**集成配置**：
1. **添加 Prometheus 数据源**：
```json
{
"name": "Prometheus",
"type": "prometheus",
"url": "http://prometheus:9090",
"access": "proxy",
"isDefault": true
}
```
2. **创建仪表盘**：
- 使用变量实现动态查询
- 使用模板变量实现多环境切换
- 配置告警面板
**常用查询示例**：
1. **CPU 使用率**：
```promql
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
```
2. **内存使用率**：
```promql
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
```
3. **磁盘使用率**：
```promql
(1 - (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes)) * 100
```
4. **网络流量**：
```promql
rate(container_network_receive_bytes_total[5m])
```
**变量配置示例**：
```yaml
# 实例变量
instance: label_values(up, instance)
# 命名空间变量
namespace: label_values(kube_pod_info, namespace)
# 时间范围变量
interval: 30s, 1m, 5m, 15m, 1h
```
**告警配置**：
- 在 Grafana 中配置告警规则
- 支持多种通知渠道（邮件、Slack、Webhook）
- 可与 Prometheus Alertmanager 集成
**最佳实践**：
1. **仪表盘组织**：
- 按业务或系统分类
- 使用文件夹管理
- 添加描述和标签
2. **查询优化**：
- 使用 Recording Rules 预计算
- 避免复杂查询
- 合理设置刷新间隔
3. **可视化技巧**：
- 选择合适的图表类型
- 使用阈值标注
- 添加图例和注释
4. **权限管理**：
- 配置基于角色的访问控制
- 限制敏感数据访问
- 使用 API Key 自动化
**导入社区仪表盘**：
- 使用 Grafana 官方仪表盘库
- 搜索关键词：Prometheus、Kubernetes、Node Exporter
- 根据需求自定义修改
前端 · 2月21日 15:40
什么是 Prometheus 的 Remote Write 和 Remote Read？Prometheus Remote Write 和 Remote Read 机制：
**Remote Write（远程写入）**：
将数据从 Prometheus 发送到远程存储系统。
**配置示例**：
```yaml
remote_write:
- url: "http://remote-storage:9201/api/v1/write"
basic_auth:
username: "user"
password: "pass"
queue_config:
capacity: 10000
max_shards: 50
min_shards: 1
max_samples_per_send: 1000
batch_send_deadline: 5s
min_backoff: 30ms
max_backoff: 100ms
write_relabel_configs:
- source_labels: [__name__]
regex: 'expensive_.*'
action: drop
```
**使用场景**：
- 长期数据存储
- 跨集群数据聚合
- 数据分析和报表
- 备份和容灾
**Remote Read（远程读取）**：
从远程存储系统读取数据。
**配置示例**：
```yaml
remote_read:
- url: "http://remote-storage:9201/api/v1/read"
read_recent: true
basic_auth:
username: "user"
password: "pass"
```
**使用场景**：
- 查询历史数据
- 跨数据源查询
- 数据分析
**支持的远程存储**：
- Thanos
- Cortex
- VictoriaMetrics
- InfluxDB
- M3DB
- TimescaleDB
**队列配置参数**：
- `capacity`：队列容量
- `max_shards`：最大分片数
- `min_shards`：最小分片数
- `max_samples_per_send`：每次发送的最大样本数
- `batch_send_deadline`：批量发送超时
- `min_backoff` / `max_backoff`：退避时间
**最佳实践**：
1. 使用 `write_relabel_configs` 过滤不需要的数据
2. 合理配置队列参数避免内存溢出
3. 监控 Remote Write 的性能指标
4. 使用 `read_recent: true` 提高查询性能
5. 考虑数据压缩减少网络传输
**监控指标**：
- `prometheus_remote_storage_queue_length`
- `prometheus_remote_storage_failed_samples_total`
- `prometheus_remote_storage_succeeded_samples_total`
服务端 · 2月21日 15:40
如何配置 Prometheus 的安全认证和访问控制？Prometheus 安全配置和最佳实践：
**认证配置**：
1. **Basic Auth 认证**：
```yaml
scrape_configs:
- job_name: 'prometheus'
basic_auth:
username: 'admin'
password: 'password'
static_configs:
- targets: ['localhost:9090']
```
2. **TLS/SSL 加密**：
```yaml
scrape_configs:
- job_name: 'https'
scheme: https
tls_config:
ca_file: /path/to/ca.crt
cert_file: /path/to/cert.crt
key_file: /path/to/key.key
insecure_skip_verify: false
```
3. **Bearer Token 认证**：
```yaml
scrape_configs:
- job_name: 'kubernetes-apiservers'
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
```
**API 访问控制**：
```yaml
# prometheus.yml
web:
tls_config:
cert_file: /path/to/cert.pem
key_file: /path/to/key.pem
basic_auth_users:
admin: $2b$12$...
```
**网络安全**：
- 使用防火墙限制访问
- 配置网络策略（Kubernetes NetworkPolicy）
- 使用 VPN 或私有网络
- 启用 HTTPS 加密传输
**数据安全**：
- 定期备份配置和数据
- 使用加密存储敏感信息
- 限制日志中的敏感信息
- 实施访问审计
**RBAC 配置（Kubernetes）**：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: prometheus
rules:
- apiGroups: [""]
resources: ["pods", "nodes", "services", "endpoints"]
verbs: ["get", "list", "watch"]
```
**最佳实践**：
1. **最小权限原则**：
- 只授予必要的权限
- 使用服务账号隔离
- 定期审查权限
2. **密钥管理**：
- 使用 Kubernetes Secrets
- 避免硬编码密码
- 定期轮换密钥
3. **监控安全事件**：
- 监控异常访问
- 配置安全告警
- 记录审计日志
4. **更新维护**：
- 及时更新版本
- 关注安全公告
- 定期安全审计
服务端 · 2月21日 15:40