公司新上了 ref="/tag/2020/" style="color:#C468A7;font-weight:bold;">Kubernetes 集群跑微服务，结果某天订单接口突然变慢，排查半天才发现是某个 Pod 内存爆了被 OOM Kill，但没人收到告警——这事儿在运维圈太常见了。
别一上来就堆 Prometheus
Prometheus 确实是 K8s 监控的标配，但它不是万能胶水。光装个 Prometheus Server，连自己集群的 CPU 使用率都看不到，因为没配数据采集端点。得先让 kubelet、kube-apiserver、etcd 这些组件把指标暴露出来，再用 ServiceMonitor 或 PodMonitor 去抓。
比如给 kube-state-metrics 加个简单配置：
apiVersion: apps/v1
kind: Deployment
metadata:
name: kube-state-metrics
spec:
selector:
matchLabels:
app: kube-state-metrics
template:
metadata:
labels:
app: kube-state-metrics
spec:
containers:
- name: kube-state-metrics
image: registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.9.2
args:
- --resources=nodes,deployments,replicasets,pods,services装完它，Prometheus 才能拿到 Deployment 的副本数是否达标、Pod 是不是总在重启这类业务层指标。
日志和链路不能只靠 Prometheus
Prometheus 擅长数值型指标（比如 CPU 92%、QPS 340），但查“用户下单失败具体报什么错”，就得翻日志；想定位“从网关到库存服务哪一环耗时最长”，就得靠分布式追踪。
轻量级组合可以这样搭：用 Fluent Bit 收集容器 stdout 日志，转给 Loki（比 ELK 占资源少）；用 OpenTelemetry Collector 接入应用埋点，后端接 Jaeger。三者都支持 Helm 一键部署，几条命令就能跑起来：
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki --set "loki.storage.type=filesystem"
helm install fluent-bit stable/fluent-bit告警别只发邮件
很多团队把 Alertmanager 配成只发邮件，结果半夜三点告警来了，人醒了，手机静音没听见。建议至少加个企业微信机器人，模板写清楚：什么集群、哪个命名空间、哪个 Pod 异常、当前值多少、过去一小时趋势图链接。
Alertmanager 的路由配置片段示例：
route:
group_by: ['alertname', 'namespace']
receiver: 'wechat-alerts'
routes:
- match:
severity: warning
receiver: 'wechat-alerts'
- match:
severity: critical
receiver: 'phone-call'Grafana 别只看默认仪表盘
导入现成的 Dashboard（比如 ID 6417 的 Kubernetes Cluster Monitoring）能快速上手，但真实环境里，你得自己加几个关键视图：一个看所有命名空间的 Pending Pod 数趋势，一个盯住每个 Deployment 的 rollout 状态（避免灰度发版卡住没人发现），还有一个显示核心服务 P95 延迟热力图——按小时+服务名交叉统计，一眼看出哪天哪个服务开始抖动。
这些不是玄学，是线上天天会撞上的问题：扩容没生效、配置没热加载、依赖的服务超时阈值设低了……监控方案好不好，不看图表多炫，而看故障发生前五分钟，你能不能准确说出“是支付服务的 Redis 连接池打满了”。