事件 Events 观测

摘要：指标是连续的时间序列，而事件是离散的"某一刻发生了什么"——发布、扩容、驱逐、OOM、配置变更。故障排查时把事件叠在指标曲线上，往往一眼就能定位根因。本文给出 Kubernetes 事件的采集、留存与告警落地方法。

适用环境

bash

kubectl version --short 2>/dev/null || kubectl version
kubectl get events -A --sort-by=.lastTimestamp | tail -10

# 确认 RBAC 允许读取事件（一般只读权限即可）
kubectl auth can-i list events

操作步骤

1. 认识 Kubernetes 事件的来源与类型

bash

# 常见 Normal 事件：Scheduled、Pulled、Created、Started、ScalingReplicaSet
# 常见 Warning 事件：FailedScheduling、BackOff、Unhealthy、OOMKilling、Evicted
kubectl get events -A --field-selector type=Warning --sort-by=.lastTimestamp | tail -20

2. 查看事件的关键字段

bash

kubectl get events -n default -o custom-columns=\
TIME:.lastTimestamp,TYPE:.type,REASON:.reason,OBJECT:.involvedObject.name,MSG:.message \
--sort-by=.lastTimestamp | tail -20

3. 采集并长期留存（kube-events 默认只保留约 1 小时）

bash

# 使用事件收集器（如 kubernetes-event-exporter 或 EventRouter）转发到日志系统
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: ServiceAccount
metadata:
  name: event-exporter
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: event-exporter
rules:
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: event-exporter
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: event-exporter
subjects:
  - kind: ServiceAccount
    name: event-exporter
    namespace: monitoring
EOF

4. 配置输出目标（以转发到日志/标准输出为例）

yaml

# 事件导出器配置片段：过滤并路由到不同目标
route:
  routes:
    - match:
        - receiver: "dump"
    - drop:
        - type: "Normal"     # 可选：丢弃 Normal 事件以降噪
receivers:
  - name: "dump"
    stdout: {}

5. 转成指标做告警

promql

# 统计各类 Warning 事件在过去 5 分钟的增长速率
sum(rate(kube_event_count{type="Warning"}[5m])) by (reason)
# OOM 事件计数（出现即需关注）
increase(kube_event_count{reason="OOMKilling"}[1h])

yaml

groups:
  - name: k8s-events
    rules:
      - alert: PodOOMKilled
        expr: increase(kube_event_count{reason="OOMKilling"}[30m]) > 0
        labels: {severity: critical}
        annotations: {summary: "有容器被 OOM Kill，请检查内存限制"}
      - alert: PodImagePullBackOff
        expr: increase(kube_event_count{reason="BackOff"}[30m]) > 3
        labels: {severity: warning}

6. 在 Grafana 里叠加事件标注

bash

# 用 annotations 数据源把事件显示为图表上的竖线
# Grafana -> Dashboard settings -> Annotations -> 新增，数据源指向存储事件的日志/ES

7. 接入自定义业务事件（把发布、开关变更也变成事件）

bash

curl -X POST http://127.0.0.1:3100/loki/api/v1/push \
  -H 'Content-Type: application/json' \
  -d '{"streams":[{"stream":{"app":"release","env":"prod"},
       "values":[["'"$(date +%s%N)"'","deploy demo-app v1.2.3 by ci"]]}]}'

验证

bash

# 1) 触发一个事件：删掉一个 Pod，应产生 Killing/Started 事件
kubectl delete pod <pod-name> --now

# 2) 事件能被查到
kubectl get events -n default --sort-by=.lastTimestamp | tail -5

# 3) 导出器是否在运行并输出
kubectl logs -n monitoring deploy/event-exporter --tail=10

# 4) 告警规则语法正确
promtool check rules /etc/prometheus/rules/k8s-events.yml

常见坑

WARNING

Kubernetes 事件默认只保留短时间和有限条数，事后排查时经常"事件已经消失"。必须先做长期留存，否则事件观测无从谈起。

WARNING

不加过滤地采集所有事件会产生海量 Normal 类型噪声（每次调度、拉镜像都记一条）。建议只留存 Warning 事件 + 关键 Normal 事件（如 Scheduled、ScalingReplicaSet）。

DANGER

事件消息里可能包含镜像地址、节点名、环境变量等基础设施细节。事件数据外发到第三方平台前请评估信息暴露范围，避免泄露内网拓扑。

事件 Events 观测 ​

适用环境 ​

操作步骤 ​

验证 ​

常见坑 ​

参考资料 ​

事件 Events 观测

适用环境

操作步骤

验证

常见坑

参考资料