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

你可以基于设置合理的报警规则，如小于 10 时报警:
与 deriv 的关系: 含义上约等于如下表达式，不过稍微准确一些。
如果你要基于做模型预测，可以参考下- 。
-：
的上层封装
部署之后很少会改动，尤其是做了服务发现，就不需要频繁新增。但报警的配置是很频繁的，如修改阈值、修改报警人等。拥有丰富的报警能力如分组、抑制等，但如果你要想把他给业务部门使用，就要做一层封装了，也就是报警配置台。用户喜欢表单操作，而非晦涩的 yaml ，同时他们也并不愿意去理解。而且大多数公司内已经有现成的监控平台，也只有一份短信或邮件网关，所以最好能使用直接集成。
例如: 机器磁盘使用量超过 90% 就报警， rule 应该写为：/ > 0.9
如果不加 label 筛选，这条报警会对所有机器生效，但如果你想去掉其中几台机器，就得在和后面加上{ != “”} 。这些操作在中是很简单的，但是如果放在表单里操作，就得和内部的 cmdb 做联动筛选了。
对于用户来说，封装yaml 会变的易用，但也会限制其能力，在增加报警配置时，研发和运维需要有一定的配合。如新写了一份自定义的，要将需要的指标供用户选择，并调整好展示和报警用的。还有报警模板、原生暴露、用户分组等，需要视用户需求做权衡。
错误的高可用设计
有些人提出过这种类型的方案，想提高其扩展性和可用性。
应用程序将推到到消息队列如，然后经过消费中转，再被拉取。产生这种方案的原因一般是有历史包袱、复用现有组件、想通过 Mq 来提高扩展性。
这种方案有几个问题：
处理逻辑：
：
如果你的架构和的设计理念相悖，可能要重新设计一下方案了，否则扩展性和可靠性反而会降低。
- 的场景
如果你是在 K8S 集群内部署，那大概率会用到 - ，他对的配置做了 CRD 封装，让用户更方便的扩展实例，同时 - 还提供了丰富的模板，包括上面提到的组件监控的视图，启动之后就可以直接使用，免去了配置面板的烦恼。
的优点很多，就不一一列举了，只提一下的局限：
高可用方案
高可用有几种方案：
就算使用官方建议的多副本 + 联邦，仍然会遇到一些问题:
本质原因是，的本地存储没有数据同步能力，要在保证可用性的前提下，再保持数据一致性是比较困难的，基础的 HA Proxy 满足不了要求，比如：
因此解决方案是在存储、查询两个角度上保证数据的一致：
存储方案：
我们采用了来支持多地域监控数据。
高可用：实践：
容器日志与事件
本文主要是监控内容, 这里只简单介绍下 K8S 中的日志、事件处理方案，以及和的搭配。
日志处理：
日志采集方案：
需要注意的点：对于容器标准输出，默认日志路径是/var/lib///xxx ，会将改日志软链到/var/log/pods ，同时还有一份/var/log/ 是对/var/log/pods的软链。不过不同的 K8S 版本，日志的目录格式有所变化，采集时根据版本做区分：