运维监控做成这样

导语

我们知道监控系统的目标是：为保障业务 SLA，帮忙我们更全面、细致的了解业务系统的运行状态，更及时的发现系统风险，同时给技术运营的同学争取更多化解风险的时间和解决问题的方向。

为此有使用开源监控系统（例如 Nagios、Zabbix、Prometheus、Grafana等），也有为了满足自己的业务需求，会使用自己开发的监控系统（例如小米的open falcon，腾讯内部的监控系统 tnm2【基础监控】、cms【日志监控】等）。

随着业务系统对监控系统的依赖，我们对监控系统的高可用性、扩展性等能力都会有更高的要求，那我们应该如何来全面的、系统的看待和提高自身监控系统的要求呢？

 

持提供开放式、自定义的数据内容采集上报方案”

疑问：为什么需要对上报方案有要求呢？

解读：比如腾讯内部的自研日志监控系统CMS，对拥有多种采集方案“Agent、SDK、Kafka、ES等”，各种不同的采集方案应对不同的场景

Agent：类似filebeat，指定服务器的具体路径，对文件的inode节点进行侦听，发现新增立即进行上报数据；

SDK：可以嵌入到业务代码逻辑里面，应对一些敏感数据不落地但是又需要上报的场景，可以在业务逻辑中对敏感数据进行脱敏（染色），然后再进行上报，也可以应对一些日志量太大，不想经过日志落盘这个中间消耗性能环节的场景；

例如：金融交易场景，要对交易数据做监控，但是又有一些敏感数据不想进入监控系统，这个时候就需要使用SDK在产生日志的时候进行脱敏，将用户信息隐藏掉，再上报到监控系统内部；

Kafka：可以应对一份日志多份消费者的场景，可以让业务将日志放入Kafka后，多个消费者进行自行提取即可；

例如：还是金融交易场景，一份日志可以做安全审计，同时也可以做监控系统，这时候就可以安全审计系统和监控系统同时拉取一份Kafka的主题


 

（编辑：保山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!