运维监控做到什么程度，就达到 BATJ 的水准了？

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

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

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

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

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

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

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

疑问：为什么需要具备推与拉数据呢？具备一种不可以吗？

解读：正常的监控系统一般都是采用拉数据的方案，因为由服务器端发起，顺序和过程可控，但是为什么需要拉数据呢？

原因是在几种场景下需要这种能力：网络限制，当出现网络限制时，如安全等保中规定，高安全等级区域可以发起对低安全等级区域的链接，反之则不可以，所以需要从高安全等级区域推送数据至监控服务；性能要求，如同 Zabbix 的 active模式 和 passive模式；服务特性，部分服务并么有对外提供请求接口，则需要内部逻辑对外进行主动 Push 监控数据。为了保证对业务系统和流程全面的监控，我们需要有多种能力的满足；

例如：某个业务中有个定时任务将离线数据统计并更新至数据库，该定时任务并无任何请求访问接口，我们如何能监控它的运行状态呢？可以在定时任务逻辑内部加入一个心跳机制，定期向监控系统push自身的监控状况，所以推的传输能力也是监控必不可少的；

（编辑：大连站长网）

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