万字长文，Prometheus 如何做到“活学活用”，大牛总结的避坑指南( 六 ) _集群

例如: 机器磁盘使用量超过 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 版本，日志的目录格式有所变化，采集时根据版本做区分：
事件：在这里特指 K8S，在排查集群问题时也很关键，不过默认情况下只保留 1h，因此需要对做持久化。一般处理方式有两种：
kube- ：
：
event-：
>>>>
参考资料
PS：欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，欢迎转发分享给更多人。
欢迎加入后端架构师交流群，在后台回复“007”即可。
猜你还想看
阿里、腾讯、百度、华为、京东最新面试题汇集
自从上线了监控告警，真香！
刚刚，之父放弃退休，64岁的他宣布加入微软！
一步步实现 Redis 搜索引擎
嘿，你在看吗？
【万字长文，Prometheus 如何做到“活学活用”，大牛总结的避坑指南】

文章插图