Prometheus “活学活用”，大牛总结了一套避坑指南 _k8s

监控系统的历史悠久，是一个很成熟的方向，而作为新生代的开源监控系统，慢慢成为了云原生体系的事实标准，也证明了其设计很受欢迎。
本文主要分享在实践中遇到的一些问题和思考，如果你对 K8S 监控体系或的设计还不太了解，可以先看下容器监控系列。
容器监控系列：
几点原则
的局限
K8S 集群中常用的一级标题
属于 CNCF 项目，拥有完整的开源生态，与这种传统 agent 监控不同，它提供了丰富的来满足你的各种需求。
你可以在这里看到官方、非官方的。如果还是没满足你的需求，你还可以自己编写，简单方便、自由开放，这是优点。
：
但是过于开放就会带来选型、试错成本。之前只需要在agent里面几行配置就能完成的事，现在你会需要很多搭配才能完成。还要对所有维护、监控。尤其是升级版本时，很痛苦。非官方还会有不少 bug 。这是使用上的不足，当然也是的设计原则。
K8S 生态的组件都会提供/接口以提供自监控，这里列下我们正在使用的：
： kube-state-：
node-：
还有各种场景下的自定义，如日志提取后面会再做介绍。
自定义：
K8S 核心组件监控与面板
k8s 集群运行中需要关注核心组件的状态、性能。如、等，基于上面提到的的指标，可以在中绘制如下图表：
模板可以参考-for-- ，根据运行情况不断调整报警阈值。
-for--：
这里提一下虽然支持了能力，可以很方便地做多级下拉框选择，但是不支持模式下配置报警规则，相关issue
issue：
官方对这个功能解释了一堆，可最新版本仍然没有支持。借用 issue 的一句话吐槽下：
关于的基础用法，可以看看《容器监控实践—》。
容器监控实践—：
采集组件 All IN One
体系中都是独立的，每个组件各司其职，如机器资源用 Node- ， Gpu 有等等。但是越多，运维压力越大，尤其是对 Agent做资源控制、版本升级。我们尝试对一些进行组合，方案有二：
另外， Node- 不支持进程监控，可以加一个- ，也可以用上边提到的，使用的 input来采集进程指标。
合理选择黄金指标
采集的指标有很多，我们应该关注哪些？在“Sre ”中提出了“四个黄金信号”：延迟、流量、错误数、饱和度。实际操作中可以使用 Use 或 Red 方法作为指导， Use 用于资源， Red 用于服务。
采集中常见的服务分三种：
对 Use 和 Red 的实际示例可以参考容器监控实践—K8S常用指标分析这篇文章。
容器监控实践—K8S常用指标分析：
K8S 1.16中的指标兼容问题
在 K8S 1.16版本，的指标去掉了和的 label ，替换为了pod 和。如果你之前用这两个 label 做查询或者绘图，需要更改下 Sql 了。因为我们一直支持多个 K8S 版本，就通过配置继续保留了原来的**_name 。
注意要用 gs ，不是，采集后做的。
采集外部K8S集群、多集群
如果部署在K8S集群内采集是很方便的，用官方给的Yaml就可以，但我们因为权限和网络需要部署在集群外，二进制运行，采集多个 K8S 集群。