16.9.8 日志、监控与告警体系

本节聚焦 Kubernetes 生产环境的日志、监控与告警体系建设，目标是实现“可观测、可追溯、可预警”。体系设计需覆盖控制面与数据面、基础设施与应用层，形成统一标准与落地流程。

体系架构与原则#

  • 分层采集：节点、容器、Pod、Service、应用四层指标与日志完整覆盖。
  • 统一标签：使用 namespace、pod、node、app、version 等统一标签体系便于聚合与检索。
  • 高可用与隔离：日志与监控系统应独立于业务集群或具备资源隔离策略。
  • 数据留存策略：日志、指标、告警数据的保留周期分级，避免成本失控。

原理草图（日志+监控+告警）：

文章图片

日志体系建设#

1) 采集与安装示例（Fluent Bit + Loki）#

创建命名空间与安装：

kubectl create ns observability

helm repo add fluent https://fluent.github.io/helm-charts
helm repo update

helm upgrade --install fluent-bit fluent/fluent-bit \
  -n observability \
  --set backend.type=loki \
  --set backend.loki.url=http://loki.observability:3100/loki/api/v1/push \
  --set service.type=ClusterIP

验证采集器运行：

kubectl -n observability get ds | grep fluent-bit
kubectl -n observability get pods -l app.kubernetes.io/name=fluent-bit

2) 结构化日志规范示例（应用侧）#

{"level":"INFO","ts":"2024-06-01T10:00:00Z","trace_id":"t-001","user_id":"u-9","request_id":"r-77","msg":"login ok"}

3) Loki 查询示例#

# 查询命名空间为 prod 的错误日志
curl -G "http://loki.observability:3100/loki/api/v1/query" \
  --data-urlencode 'query={namespace="prod"} |= "ERROR"' \
  --data-urlencode 'limit=20'

4) 常见排错#

  • 采集器无日志：确认容器有 stdout/stderr 输出
    bash kubectl -n prod logs deploy/app -c app --tail=20
  • Fluent Bit 没有推送：检查后端地址与网络
    bash kubectl -n observability logs ds/fluent-bit --tail=50 kubectl -n observability exec -it ds/fluent-bit -- curl -s http://loki.observability:3100/ready

监控体系建设#

1) Prometheus 安装示例（kube-prometheus-stack）#

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm upgrade --install kube-prometheus prometheus-community/kube-prometheus-stack \
  -n observability \
  --set grafana.enabled=true \
  --set prometheus.prometheusSpec.retention=15d

验证核心组件：

kubectl -n observability get pods | egrep "prometheus|grafana|alertmanager"

2) 自定义指标采集示例（Pod 指标）#

应用暴露 /metrics，配置 ServiceMonitor：

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: prod
  labels:
    app: demo-app
spec:
  selector:
    app: demo-app
  ports:
    - name: http
      port: 8080
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: demo-app
  namespace: observability
spec:
  selector:
    matchLabels:
      app: demo-app
  namespaceSelector:
    matchNames: ["prod"]
  endpoints:
    - port: http
      path: /metrics
      interval: 30s

应用：

kubectl apply -f demo-app-servicemonitor.yaml

3) 监控查询示例（PromQL）#

# 过去5分钟 Pod 重启次数
increase(kube_pod_container_status_restarts_total[5m])

# 节点CPU使用率
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)

4) 常见排错#

  • Prometheus 没抓到指标：检查 ServiceMonitor 与标签
    bash kubectl -n observability get servicemonitor kubectl -n observability describe servicemonitor demo-app
  • 目标端点不可达：检查 Service/Endpoints
    bash kubectl -n prod get svc demo-app kubectl -n prod get endpoints demo-app

告警体系建设#

1) 告警规则示例（CPU 高负载）#

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: node-alerts
  namespace: observability
spec:
  groups:
  - name: node.rules
    rules:
    - alert: NodeHighCPU
      expr: 1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) > 0.85
      for: 5m
      labels:
        severity: P2
      annotations:
        summary: "Node CPU high"
        description: "instance={{ $labels.instance }} CPU usage > 85% for 5m"

2) Alertmanager 通知通道示例（邮件+企业IM）#

global:
  smtp_smarthost: 'mail.example.com:25'
  smtp_from: 'alert@example.com'
route:
  group_by: ['alertname','cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  receiver: 'mail'
receivers:
- name: 'mail'
  email_configs:
  - to: 'ops@example.com'
- name: 'im'
  webhook_configs:
  - url: 'https://im.example.com/webhook/alert'

更新配置：

kubectl -n observability create secret generic alertmanager-config \
  --from-file=alertmanager.yaml --dry-run=client -o yaml | kubectl apply -f -

3) 告警排错#

  • 无告警：确认规则生效与阈值
    bash kubectl -n observability get prometheusrule kubectl -n observability logs deploy/kube-prometheus-prometheus
  • 通知不达：确认 Alertmanager 配置与网络
    bash kubectl -n observability logs deploy/kube-prometheus-alertmanager

关键监控项清单#

  • 控制面：apiserver 响应时延与错误率、etcd 延迟与磁盘、水位。
  • 节点层：Node NotReady、磁盘 inode/空间、CPU steal、负载。
  • 工作负载：Pod 重启次数、OOMKill、Pending/CrashLoopBackOff。
  • 网络层：Service 5xx 比例、Ingress 延迟、CNI 异常。
  • 存储层：PVC 绑定失败、IO 延迟、存储容量使用率。

运行与优化建议#

  • 统一模板：为所有服务提供默认告警规则与仪表盘模板。
  • 建立基线：在稳定期确定告警阈值与容量基线。
  • 演练机制：定期注入异常验证告警链路与响应机制。
  • 容量规划：监控系统自身资源单独规划，防止被业务抢占。

练习与实验#

1) 部署一套 Fluent Bit + Loki，查询某个命名空间的 ERROR 日志并截图。
2) 为一个 demo 应用新增 ServiceMonitor，验证 Prometheus 目标为 UP。
3) 新增一条告警规则（Pod 重启次数>3），并模拟触发（手动重启容器）。
4) 故障排查：停止 demo 应用的 /metrics，确认 Prometheus 目标变为 DOWN，并恢复。