自动采集数据(如何最大程度满足稳定性工作需求，各种运维平台的复杂程度也在成倍增加)

　　自动采集数据(如何最大程度满足稳定性工作需求，各种运维平台的复杂程度也在成倍增加)

　　随着互联网的发展，运维复杂度成倍增加；随之而来的，各种运维平台的复杂性也呈指数级增长。

　　在这个场景中，我们一直在追求和讨论如何最大程度满足稳定工作的需求，保证我们的系统相对干净和解耦。

　　监控系统的话题很大。

　　本文文章是作者监控系列文章的第一篇，只介绍监控系统的采集链接。

　　前言

　　监控系统的话题很大，随着业务的复杂化，会衍生出各种形式。但总的来说，不能绕过的部分有三部分：采集、存储、告警。

　　本文将和大家聊聊第一部分：data采集。

　　哪些数据需要采集

　　说到采集，首先要明白采集需要什么数据。

　　监控系统可用于实时数据查看，可用于历史状态查看，或用于异常报警。这些需要采集准确的数据。

　　数据采集其实就是采集足够的数据来满足各种业务需求。

　　数据模型

　　要谈采集方法，必须从监控数据模型说起。

　　监控到的数据其实是最纯粹的时间序列数据。那么，在构建监控系统时，抽象出统一的数据模型应该是设计和架构的第一步。

　　一般时间序列数据包括四部分：

　　开放猎鹰数据模型

　　如上图所示，是open-falcon数据模型。此数据模型在基本时间序列模型上进行了自定义，增加了两个字段，endpoint 和 counterType。

　　这两个字段与open-falcon的形式和存储细节有关。但如果更宏观地看，你可以把这两个字段看作是两个标签，只是分别取出来。 采集的方式

　　采集 的方法根据我们监控数据的来源而有所不同。主要分为默认采集、插件、检测、日志、埋点。

　　所有运维标准的制定，没有相应的工具和平台支持，都是空谈。因此，监控系统还应提供多种语言的业务嵌入SDK和快速简单的数据采集平台。

　　大多数开发团队都有自己的一套开发框架。如果能深入业务，还可以考虑进一步将埋点SDK直接集成到业务线的统一开发框架中。

　　日志监控

　　从稳定性的角度来看，在大多数情况下，日志监控和业务埋点获取的数据是相同的。

　　只是日志监控更加灵活。当我们的服务是一个闭源项目，或者在短时间内无法快速修改使用的开源组件时，日志监控可以快速生效。

　　一般来说，日志监控分为在线日志采集和离线日志采集。

　　在线日志采集一般比较灵活。通过各种自定义操作，可以很好的过滤和计算日志的时间、内容、大小，只需要少量的配置成本。就是这样。但是采集这种日志侵入性较大，需要在机器上安装代理，实时分析日志会占用CPU资源，容易影响在线服务的稳定性，因此资源必须进行限制。

　　离线日志采集是统一采集日志并在中心处理计算。这个采集的好处是不会占用太多CPU资源，日志量也没有瓶颈。但同时，也会占用大量的网络资源。在时效性方面，与实时分析相比，会有一些延迟；而对于大批量日志的集中处理，日志的格式必须标准化，灵活性可能会差一些。

　　插件采集

　　有基础指标，还有埋点、日志、检测。其他人呢？

　　如果用户有自己的采集方法，但是需要将数据上报给监控系统，这个场景可以通过插件采集来实现。

　　插件采集提供了一种由监控系统控制的采集循环。用户只需实现一个采集逻辑的循环即可完成数据采集能力。

　　插件采集更加灵活，可以提供用户自定义的采集方法，比如特定的集合命令，比如jum。插件只需要上报监控系统开发的标准化数据即可。

　　插件采集需要定期在机器上执行插件脚本。因此，必须检查此脚本的审计。无论是有害行为还是资源消耗，都可能成为影响在线稳定性的隐患。

　　报告自定义指标

　　监控系统除了上面提到的几个采集方法外，还应该支持自定义上报的功能。

　　自定义时间序列都希望利用监控系统实现数据可视化和报警功能。

　　此时可以提供自定义的数据上报接口，无论是由本地代理采集还是单独的中央采集器。

　　通过自定义指标上报，监控系统真正成为一个稳定的基础设施。

　　open-falcon 的采集agent 提供了这样的接口。

　　但支持自定义，但无法很好地规范用户的举报行为。在生产环境中，经常会出现数据上报错误或使用不规范的情况，导致监控系统的存储成为瓶颈。这部分我们将在“运维监控系统（二)：脏数据治理”）的主题中讨论。

　　如何采集数据

　　一般有两种采集方式：

　　拉取数据采集

　　中心端主动拉取，即一个中心端周期性的按需从采集端拉取数据。这种模式的优点是可以按需拉取而不浪费。但在这个模型中，中心承受了太大的压力。理论上，性能会有很大的瓶颈。

　　报告数据采集

　　客户端会自动上报，即所有数据均等上报。一般会用统一的代理来采集，然后再考虑多级组件，或者加一层MQ，都是可以考虑的设计。

　　综合来看，如果监测数据量估计比较大。还是建议采用采集集中上报的模式。

　　Open-falcon 的数据采集是一种非常好的客户端自动上报模式。传输可以无状态扩展并支持级联。

　　后记

　　本文文章为《运维监控系统专题》第一篇，后续会持续更新。名单如下：