一、技术选型与架构设计

1.1 Prometheus与Kubernetes的天然适配性

Prometheus采用Pull-Based的拉取模式，完美契合Kubernetes动态容器环境。其Service Discovery机制支持通过Kubernetes API自动发现Pod、Service等资源，无需手动维护监控目标列表。通过ServiceMonitor CRD（Custom Resource Definition），可实现监控配置的声明式管理，与Kubernetes的Operator模式高度契合。

1.2 飞书告警的集成优势

飞书机器人提供丰富的消息格式支持（文本、卡片、富文本），支持@指定成员、群组，可实现告警的精准触达。其Webhook机制兼容Prometheus Alertmanager的HTTP POST通知方式，无需复杂中间件即可完成集成。相比传统邮件告警，飞书在移动端响应速度和交互体验上具有显著优势。

二、Kubernetes环境部署实践

2.1 核心组件部署方案

2.1.1 Prometheus Operator部署

# 使用kube-prometheus-stack Helm Chart部署
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \
  --set alertmanager.enabled=true

该方案自动部署Prometheus、Alertmanager、Grafana等组件，并预置常用监控规则。

2.1.2 Node Exporter与cAdvisor配置

通过DaemonSet在每个Node部署Node Exporter，采集主机级指标（CPU、内存、磁盘等）。cAdvisor作为kubelet内置组件，自动采集容器级指标（CPU、内存、网络等）。需注意：

• 配置--collector.filesystem.ignored-mount-points排除无关挂载点
• 为cAdvisor设置--housekeeping_interval=30s优化采集频率

2.2 服务发现高级配置

2.2.1 动态服务发现

# ServiceMonitor示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-ingress
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

通过selector匹配Service的Label，自动发现后端Pod的metrics端口。

2.2.2 自定义Relabeling

# 在ServiceMonitor中配置metricRelabelings
metricRelabelings:
- sourceLabels: [__name__]
  regex: 'nginx_ingress_controller_requests.*'
  action: keep

通过正则表达式过滤特定指标，减少数据存储压力。

三、飞书告警集成全流程

3.1 飞书机器人创建与配置

1. 在飞书群设置中创建自定义机器人
2. 获取Webhook URL（格式：https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx）
3. 设置签名校验（可选，增强安全性）

3.2 Alertmanager配置优化

3.2.1 基础Webhook配置

# alertmanager.yml配置示例
receivers:
- name: 'feishu-webhook'
  webhook_configs:
  - url: 'https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxxx'
    send_resolved: true
    http_config:
      tls_config:
        insecure_skip_verify: true

3.2.2 高级消息模板

# 使用Go模板自定义消息格式
templates:
- '/etc/alertmanager/template/feishu.tmpl'
# feishu.tmpl内容示例
{{ define "feishu.default.message" }}
{
  "msg_type": "interactive",
  "card": {
    "elements": [
      {
        "tag": "div",
        "text": {
          "tag": "lark_md",
          "content": "**告警类型**: {{ .Alerts.Firing | len }}个活跃告警\n"
        }
      },
      {{ range .Alerts.Firing }}
      {
        "tag": "action",
        "actions": [
          {
            "tag": "button",
            "text": {
              "tag": "plain_text",
              "content": "查看详情"
            },
            "type": "primary",
            "url": "{{ .GeneratorURL }}"
          }
        ]
      },
      {{ end }}
    ]
  }
}
{{ end }}

3.3 告警路由策略设计

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'feishu-webhook'
  routes:
  - receiver: 'feishu-critical'
    match:
      severity: 'critical'
    continue: true
  - receiver: 'feishu-warning'
    match:
      severity: 'warning'

通过多级路由实现告警分级处理，避免重要告警被淹没。

四、告警规则设计最佳实践

4.1 基础资源监控规则

4.1.1 Node资源告警

# 节点CPU使用率告警
- alert: NodeCPUUsageHigh
  expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "节点 {{ $labels.instance }} CPU使用率过高"
    description: "当前使用率: {{ $value }}%, 持续10分钟"

4.1.2 内存告警

- alert: NodeMemoryPressure
  expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 15
  for: 5m
  labels:
    severity: critical

4.2 Kubernetes组件监控

4.2.1 Pod状态告警

- alert: PodNotReady
  expr: sum by(namespace, pod) (kube_pod_status_phase{phase="Pending"}) > 0
  for: 15m
  labels:
    severity: critical

4.2.2 部署异常告警

- alert: DeploymentReplicasMismatch
  expr: kube_deployment_status_replicas_available / kube_deployment_spec_replicas * 100 < 90
  for: 5m
  labels:
    severity: warning

4.3 应用层监控规则

4.3.1 HTTP错误率告警

- alert: HighErrorRate
  expr: rate(nginx_ingress_controller_requests{status=~"5.."}[1m]) / rate(nginx_ingress_controller_requests[1m]) * 100 > 5
  for: 2m
  labels:
    severity: critical

4.3.2 延迟告警

- alert: HighRequestLatency
  expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by(le)) > 1.5
  for: 10m
  labels:
    severity: warning

五、高级优化技巧

5.1 告警降噪策略

1. 聚合告警：通过group_by将相同指标的告警合并
2. 抑制机制：配置inhibit_rules避免重复告警
3. 静默期：对已知问题设置静默规则

5.2 性能优化建议

1. 调整--storage.tsdb.retention.time（默认15d）平衡存储与查询性能
2. 为频繁查询的指标设置recording rules
3. 使用--web.enable-admin-api监控Prometheus自身状态

5.3 故障排查指南

1. 告警未触发：检查Alertmanager配置与Prometheus规则匹配
2. 飞书未接收：验证Webhook URL与网络策略
3. 指标缺失：确认ServiceMonitor的端口与路径配置

六、企业级实践建议

1. 多集群监控：通过Thanos或Prometheus Federation实现跨集群监控
2. 告警升级机制：结合PagerDuty等工具实现On-Call轮班
3. 历史数据分析：将告警数据导入ELK或ClickHouse进行趋势分析
4. 合规性要求：对敏感告警设置审批流程与审计日志

本方案已在多个生产环境验证，可支撑每日百万级指标的采集与处理。实际部署时建议先在测试环境验证告警规则的准确性，再逐步推广到生产环境。通过持续优化告警阈值与通知策略，可显著提升运维效率与系统稳定性。