本文主要科普一些监控系统相关入门知识。
基础概念
监控的定义
监控是收集和分析数据以确定业务应用程序的性能，运行状况和可用性及其依赖的资源的行为。 有效的监控策略可帮助用户了解应用程序组件的详细进程，还可以通过主动通知关键问题来避免错误发生，以便在问题发生之前解决问题。
监控的核心价值
下面简单梳理一下监控系统的核心价值：
- 实时的数据查看
- 历史状态回顾
- 资源使用数据报表订阅
- 异常告警
时间序列
监控面向的对象是时间序列的数据，那么时间序列的数据有什么样的特征呢？
- 严格按时间顺序进行排序的一组随机变量
- 每个变量都包含有时间戳及值
- 常见的时间序列，包括服务器cpu利用率、服务请求速率等
- 非常有用，能够反映服务的当前状态、在合理分析后能够对未来的趋势进行预测
时间序列数据库
大数据时代，各种软硬件设备联网，需要连续监控，将会产生大量的时间序列的数据，针对这一类的数据如何针对性地进行存储和聚合查询呢？作为这一类数据存储的基础设施的时间序列数据库诞生了。
时间序列数据库是一种针对时间序列特点进行优化，专用于处理时间序列数据的软件系统。 从2000年左右出现，在2014年被DB-Engine列为独立的数据类型进行排名。 典型实现:InfluxDB\OpenTSDB\TimescaleDB\Prometheus等。
从下图我们可以看到，自2018年以来，时间序列数据库的受欢迎程度突飞猛进，这也是当前大数据时代发展的必然要求。
下图是来自DB-Engine关于当前流行的时间序列数据库的排名，比较值得我们重点关注的是InfluxDB\OpenTSDB\Prometheus，后续我也会写专门的文章介绍这三个时间序列数据库。
监控系统的分类
根据Peter Bourgon.2017年分布式追踪峰会上提出的Metrics, Tracing 和 Logging 的关系，他将业界所有监控系统划分为如下三类：
- Logging:即日志监控 。
记录系统发生的离散事件。如：
- 用户的某次特殊操作
- 实例异常离线
- Metrics:即指标监控 。
反映系统状态的聚合型数据，从形式上来看，指标为时间序列。如:
- cpu利用率
- 磁盘读速率
- Tracing:即分布式追踪。
请求处理链相关的监控数据，也是离散型。
- 每个请求的处理状态
- 哪些节点在处理特定请求时失败
- 哪些节点在处理特定请求时响应慢
宏观上看，指标监控的内容主要包括的内容如下：
- 主机状态监控：监控计算机的 CPU、内存状态等
- 应用状态监控：监控系统中的应用程序的状态，如资源占用情况、失败重启情况等
- 网络与连接监控：监控网络的带宽使用情况、延迟与丢包情况等
- 集群状态监控：监控集群中节点的生命周期、节点的选举情况等
- 外部依赖监控：监控外部依赖的可用性等
指标监控系统的两类实现模型
指标Metrics类别的监控系统有两大类典型的实现模型，分别是推模型和拉模型。
拉模型
- 服务端感知客户端并决定从哪些客户端拉取数据
- 服务端决定数据采集频率
- 服务端和客户端必须保证在同一网络平面里
推模型
- 服务端不感知客户端，客户端主动感知服务端
- 客户端决定数据的采集频率
- 服务端和客户端可以不在同一网络平面里，如客户端在
NAT设备之后
监控系统一般架构
监控系统的话题很大，随着业务的复杂，也会衍生出各种各样不同的形态。但总体上绕不开三个部分：
- 采集
- 存储
- 报警
更加细节一点，监控系统所要回答的基本问题包括：
- 监控数据由谁采集？怎么采集？怎么上报？
- 监控数据如何处理？例如，怎么做固定阈值的报警判断？动态阈值的报警判断？未来扩容需求的预测？
- 监控数据是如何被存储的？
- 监控数据是如何聚合和展示的？
因此，在设计一般的监控系统时，会包括如下的组件：
- 采集: 获取来自包括操作系统，传感器、队列、数据库和网络等任何地方的一切数据，包括metrics, events, logs还是traces，并且将他们存储在一个高性能的、每秒能够处理上百万条数据服务器上。
- 处理: 对数据进行高效地分析、聚合、处理，包括机器学习。
- 动作: 实现自动化。只需单击即可设置警报或根据机器学习算法执行复杂的异常检测。发送警报给Slack，SMS和PagerDuty等热门服务。创建自定义触发器以执行任何操作。
