监控系统介绍
监控系统介绍
- 监控系统
-
- 监控系统的功能
- 监控系统的分类
-
- 日志类
- 调用链类
-
- 介绍
- 一些术语
-
- Traces
- Spans
- Operation Names
- Inter-Span References
- Logs
- Tags
- SpanContext
- Baggage
- 度量类
-
- 关系型数据与时序数据库的比较
- 时序数据特点
- 时间序列数据的模型
- 监控系统分层
- 流行的监控系统
-
- Zabbix
- Open-Falcon
- Nagios
- Prometheus
- 综合对比
监控系统
随着云计算、微服务等技术的流行，以及互联网业务迅速发展，运维人员与开发人员需要关注的服务数量也呈现出了指数级的增长，如何做好监控，能够快速且精准的定位问题成为了最迫切要解决的问题。
监控系统的功能
在IT运维过程中，常遇到如下情况：
- 某个模块出现故障，没有及时发现，等到故障影响范围扩大到影响业务场景才发现；
- 数据库目前的数据量如何，增长速度如何。又例如每日活跃用户的数量增长的速度；
- 我们的请求延迟刚刚大幅增加了，有没有其他现象同时发生？
- 系统出现瓶颈，CPU占用居高不下，内存不足，磁盘被写满。
以上这些问题一旦发生，会对我们的业务产生巨大的影响。因此，每个公司或者 IT 团队都会针对此类情况建立自己的 IT 监控系统。
其功能包括：
- 对服务，系统，平台的运行状态实时监控。
- 收集服务，系统，平台的运行信息。
- 通过收集信息的分析结果，预知存在的故障风险，并采取行动。
- 根据对风险的评估，进行故障预警。
- 一旦发生故障，第一时间发出告警信息。
- 通过监控数据，定位故障，协助生成解决方案。
- 最终保证系统持续、稳定、安全运行。
- 监控数据可视化，便于统计，按照一定周期导出、归档，用于数据分析和问题复盘。
监控系统的分类
针对不同场景把监控系统分为三类，分别是：
- 日志类
- 调用链类
- 度量类
日志类
通常我们的系统会记录不同等级和状态的运行日志信息，这些信息与事件息息相关，例如：PV/UV，用户登录，下订单，用户平均响应时间等等。
这类以日志的记录和查询的解决方案比较多。比如 ELK 方案（Elasticsearch+Logstash+Kibana），使用ELK（Elasticsearch、Logstash、Kibana）+Kafka/Redis/RabbitMQ 来搭建一个日志系统。
程序内部通过 Spring AOP 记录日志，Beats 收集日志文件，作为消息发送给消息队列(Kafka/Redis/RabbitMQ)， Logstash通过订阅消息队列，实时消费消息并将日志写入 Elasticsearch。
最后，使用 Kibana 将存放在 Elasticsearch 中的日志数据显示出来，形式可以是实时数据图表。
调用链类
介绍
当代的互联网的服务，通常都是用复杂的、大规模分布式集群来实现的。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具。
分布式服务的跟踪系统需要记录在一次特定的请求后系统中完成的所有工作的信息。举个例子，上图展现的是一个和5台服务器相关的一个服务，包括：前端（A），两个中间层（B和C），以及两个后端（D和E）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个RPC到服务器B和C。B会马上做出反应，但是C需要和后端的D和E交互之后再返还给A，由A来响应最初的请求。对于这样一个请求，在调用链监控系统中我们通常称之为一个trace。
在广义上，一个trace代表了一个事务或者流程在（分布式）系统中的执行过程。在OpenTracing标准中，trace是多个span组成的一个有向无环图（DAG），每一个span代表trace中被命名并计时的连续性的执行片段。
分布式追踪中的每个组件都包含自己的一个或者多个span。例如，在一个常规的RPC调用过程中，OpenTracing推荐在RPC的客户端和服务端，至少各有一个span，用于记录RPC调用的客户端和服务端信息。
通过分布式系统跟踪工作流或事务通常看起来如上所述。虽然这种类型的可视化对于查看各种组件如何组合在一起是有用的，但是它不传达任何持续时间，不能很好地扩展，并且在涉及并行性时是麻烦的。另一个限制是无法轻易显示延迟或时序的其他方面。甚至基本跟踪可视化的更有用的方法通常如下所示：
这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，项目团队可能专注于优化路径中的关键位置，最大幅度的提升系统性能。例如：可以通过追踪一个资源定位的调用情况，明确底层的调用情况，发现哪些操作有阻塞的情况。
一些术语
一个tracer过程中，各span的关系
[Span A] ←←←(the root span)
|
+------+------+
| |
[Span B] [Span C] ←←←(Span C 是 Span A 的孩子节点, ChildOf)
| |
[Span D] +---+-------+
| |
[Span E] [Span F] >>> [Span G] >>> [Span H]
↑
↑
↑
(Span G 在 Span F 后被调用, FollowsFrom)
上述tracer与span的时间轴关系
––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time
[Span A···················································]
[Span B··············································]
[Span D··········································]
[Span C········································]
[Span E·······] [Span F··] [Span G··] [Span H··]
Traces
一个trace代表一个潜在的，分布式的，存在并行数据或并行执行轨迹（潜在的分布式、并行）的系统。一个trace可以认为是多个span的有向无环图（DAG）。
Spans
一个span代表系统中具有开始时间和执行时长的逻辑运行单元。span之间通过嵌套或者顺序排列建立逻辑因果关系。
Operation Names
每一个span都有一个操作名称，这个名称简单，并具有可读性高。（例如：一个RPC方法的名称，一个函数名，或者一个大型计算过程中的子任务或阶段）。span的操作名应该是一个抽象、通用的标识，能够明确的、具有统计意义的名称.
Inter-Span References
一个span可以和一个或者多个span间存在因果关系。OpenTracing定义了两种关系：ChildOf 和 FollowsFrom。这两种引用类型代表了子节点和父节点间的直接因果关系。未来，OpenTracing将支持非因果关系的span引用关系。（例如：多个span被批量处理，span在同一个队列中，等等）
ChildOf 引用: 一个span可能是一个父级span的孩子，即"ChildOf"关系。在"ChildOf"引用关系下，父级span某种程度上取决于子span。下面这些情况会构成"ChildOf"关系：
- 一个RPC调用的服务端的span，和RPC服务客户端的span构成ChildOf关系
- 一个sql insert操作的span，和ORM的save方法的span构成ChildOf关系
- 很多span可以并行工作（或者分布式工作）都可能是一个父级的span的子项，他会合并所有子span的执行结果，并在指定期限内返回
FollowsFrom 引用: 一些父级节点不以任何方式依然他们子节点的执行结果，这种情况下，我们说这些子span和父span之间是"FollowsFrom"的因果关系。"FollowsFrom"关系可以被分为很多不同的子类型，未来版本的OpenTracing中将正式的区分这些类型
Logs
每个span可以进行多次Logs操作，每一次Logs操作，都需要一个带时间戳的时间名称，以及可选的任意大小的存储结构。
Tags
每个span可以有多个键值对（key:value）形式的Tags，Tags是没有时间戳的，支持简单的对span进行注解和补充。
SpanContext
每个span必须提供方法访问SpanContext。SpanContext代表跨越进程边界，传递到下级span的状态。(例如，包含
Baggage
Baggage是存储在SpanContext中的一个键值对(SpanContext)集合。它会在一条追踪链路上的所有span内全局传输，包含这些span对应的SpanContexts。在这种情况下，"Baggage"会随着trace一同传播，他因此得名（Baggage可理解为随着trace运行过程传送的行李）。鉴于全栈OpenTracing集成的需要，Baggage通过透明化的传输任意应用程序的数据，实现强大的功能。例如：可以在最终用户的手机端添加一个Baggage元素，并通过分布式追踪系统传递到存储层，然后再通过反向构建调用栈，定位过程中消耗很大的SQL查询语句。
Baggage拥有强大功能，也会有很大的消耗。由于Baggage的全局传输，如果包含的数量量太大，或者元素太多，它将降低系统的吞吐量或增加RPC的延迟。
度量类
度量类主要采用时序数据库的解决方案。它是以事件发生时间以及当前数值的角度来记录的监控信息，是可以聚合运算的，用于查看一些指标数据和指标趋势。所以这类监控主要不是用来查问题的，主要是用来看趋势的。
关系型数据与时序数据库的比较
时序数据库的概念：
时序数据库（Time Series Database）是用于存储和管理时间序列数据的专业化数据库，为时间序列数据提供高性能读写和强计算能力的分布式数据库服务。时序数据库特别适用于物联网设备监控和互联网业务监控场景。
关系数据库代表MySql,和时序数据库influx db的比较
| 比较指标 | 关系数据库（MySql） | 时序数据库(influx db) |
|---|---|---|
| 数据存储规模 | 百万级 | 轻松千万级 |
| 实现机制 | B+Tree | LSM_Tree |
| 吞吐量 | 一般 | 高 |
| 延迟性 | 一般 | 低 |
| 扩展性 | 一般 | 高 |
| 事务性 | 支持 | 否 |
| 一致性 | 高 | 一般 |
根据以上特点，可知：
- 关系数据库，比较适合数据量规模并不是很大，读多写少，对吞吐性，读写延迟不是很高，一致性要求高的场景。
- 时序数据库，适合巨量数据规模，读少写多，读写延迟低，数据一致性要求不高，即便丢失数据也不影响业务的场景。
时序数据特点
- 时间序列数据
- 这类数据描述了某个被测量的主体在一个时间范围内的每个时间点上的测量值 。
- 数据写入平稳、持续、高并发
- 时序数据是以某个固定频率采样而产生的，不会受其他因素制约。
- 写多读少。
- 实时写入最近的数据，无更新。
- 数据查询以时间范围
- 不会具体到某个点上的数据，以采样间隔多精度查询。
- 数据量大，冷热分明，多精度数据存储
- 整个数据的规模，是TB甚至是PB级的 ，历史数据分析价值有限，通常有保存周期，时效性强。
时间序列数据的模型
时序数据库的一些基本概念（不同的时序数据库称呼略有不同）。
-
metric: 度量，相当于关系型数据库中的table。
-
data point: 数据点，相当于关系型数据库中的row。
-
timestamp：时间戳，代表数据点产生的时间。
-
field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个field。一般情况下存放的是会随着时间戳的变化而变化的数据。
-
tag: 标签，或者附加信息。一般存放的是并不随着时间戳变化的属性信息。timestamp加上所有的tags可以认为是table的primary key。
以关系型数据库表为例介绍其数据模型
假如：有一组监控数据，记录主机的CPU使用率(%)，内存使用情况，每10s采取一次。
表结构一般我们会如下2种设计。
- 以时间(数据源)为维度
| 时间 | 主机名字 | CPU使用率(%) | 内存使用率(%) |
|---|---|---|---|
| 2018-08-01 00:00:10 | 上海主机 | 10 | 30 |
| 2018-08-01 00:00:20 | 上海主机 | 20 | 50 |
| 2018-08-01 00:00:30 | 上海主机 | 15 | 40 |
其中每一行代表一个data point，时间列为timestamp，CPU使用率(%)和内存使用率(%)为field，主机名为tag
- 以指标为维度
| 指标名字 | 时间 | 主机名字 | 指标值 |
|---|---|---|---|
| CPU使用率(%) | 2018-08-01 00:00:10 | 上海主机 | 10 |
| 内存使用率(%) | 2018-08-01 00:00:10 | 上海主机 | 30 |
| CPU使用率(%) | 2018-08-01 00:00:20 | 上海主机 | 20 |
| 内存使用率(%) | 2018-08-01 00:00:20 | 上海主机 | 50 |
| CPU使用率(%) | 2018-08-01 00:00:30 | 上海主机 | 15 |
| 内存使用率(%) | 2018-08-01 00:00:30 | 上海主机 | 40 |
时序数据库的存储原理，关系型数据库存储采用的是 B tree，虽然降低了数据查询的磁盘寻道时间，但是无法解决大量数据写入时的磁盘效率。
由于时序数据的特点，经常会遇到大批量的数据写入，所以选择 LSMtree（Log Structured Merge Tree）存储时序数据库。
LSMtree（Log Structured Merge Tree），从字面意义上理解，记录的数据按照日志结构（Log Structured）追加到系统中，然后通过合并树（Merge Tree）的方式将其合并。
来看一个 LevelDB 的例子，方便我们理解，LSM-tree 被分成三种文件：
- 接收写入请求的 memtable 文件（内存中）
- 不可修改的 immutable memtable 文件（内存中）
- 磁盘上的 SStable文件（Sorted String Table），有序字符串表，这个有序的字符串就是数据的key。SStable 一共有七层（L0 到 L6）。下一层的总大小限制是上一层的 10 倍。
LSMtree 写入流程：
-
将数据追加到日志 WAL（Write Ahead Log）中，写入日志的目的是为了防止内存数据丢失，可以及时恢复。
-
把数据写到 memtable 中。
-
当 memtable 满了（超过一定阀值），就将这个 memtable 转入 immutable memtable 中，用新的 memtable 接收新的数据请求。
-
immutablememtable 一旦写满了， 就写入磁盘。并且先存储 L0 层的 SSTable 磁盘文件，此时还不需要做文件的合并。
每层的所有文件总大小是有限制的（8MB，10MB，100MB… 1TB）。从 L1 层往后，每下一层容量增大十倍。
-
某一层的数据文件总量超过阈值，就在这一层中选择一个文件和下一层的文件进行合并。
如此这般上层的数据都是较新的数据，查询可以从上层开始查找，依次往下，并且这些数据都是按照时间序列存放的。
监控系统分层
一般我们将监控系统分为五层来考虑，仅供参考：
- **客户端监控，**用户行为信息，业务返回码，客户端性能，运营商，版本，操作系统等。
- **业务层监控，**核心业务的监控，例如：登录，注册，下单，支付等等。
- **应用层监控，**相关的技术参数，例如：URL 请求次数，Service 请求数量，SQL 执行的结果，Cache 的利用率，QPS 等等。
- **系统层监控，**物理主机，虚拟主机以及操作系统的参数。例如：CPU 利用率，内存利用率，磁盘空间情况。
- **网络层监控，**网络情况参数。例如：网关流量情况，丢包率，错包率，连接数等等。
流行的监控系统
接下来，我们来看看有哪些优秀实践。这里介绍几个比较流行的监控系统：
- Zabbix
- Open-Falcon
- Nagios
- Prometheus
Zabbix
Zabbix是由Alexei Vladishev开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持SNMP、IPMI、JMX、Telnet、SSH等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。
Zabbix 由 Server，Agent，Proxy（可选项）组成：
- Agent 负责收集数据，并且传输给 Server。
- Server 负责接受 Agent 的数据，进行保存或者告警。
- Proxy 负责代理 Server 收集 Agent 传输的数据，并且转发给 Server。Proxy 是安装在被监控的服务器上的，用来和 Server 端进行通信，从而传输数据。
- Zabbix Database支持常用的关系型数据库，如果MySQL、PostgreSQL、Oracle等，默认是MySQL
- Zabbix Web页面（PHP编写）进行数据查询和数据可视化
Zabbix 的数据采集，主要有两种模式：Server 主动拉取数据和 Agent 主动上报数据。
以 Server 拉取数据为例，用户在 Web-portal 中，设置需要监控的机器，配置监控项，告警策略。Zabbix-Server 会根据策略主动获取 Agent 的数据，然后存储到 MySQL 中。同时根据用户配置的策略，判定是否需要告警。用户可以在 Web 端，以图表的形式，查看各种指标的历史趋势。
在 Zabbix 中，将 Server 主动拉取数据的方式称之为 Active Check。这种方式配置起来较为方便，但是会对 Zabbix-Server 的性能存在影响。所以在生产环境中，一般会选择主动推送数据到 Zabbix-Server 的方式，称之为 Trapper。即用户可以定时生成数据，再按照 Zabbix 定义的数据格式，批量发送给 Zabbix-Server，这样可以大大提高 Server 的处理能力。
Open-Falcon
Open-Falcon是小米开源的企业级监控工具，用Go语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案。
主要组件包括了：
1）Falcon-agent是用Go语言开发的Daemon程序，运行在每台Linux服务器上，用于采集主机上的各种指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等，目前已经支持200多项监控指标。并且，Agent支持用户自定义的监控脚本。
2）Hearthbeat server简称HBS心跳服务，每个Agent都会周期性地通过RPC方式将自己的状态上报给HBS，主要包括主机名、主机IP、Agent版本和插件版本，Agent还会从HBS获取自己需要执行的采集任务和自定义插件
3）Transfer负责接收Agent发送的监控数据，并对数据进行整理，在过滤后通过一致性Hash算法发送到Judge或者Graph。
4）Graph是基于RRD的数据上报、归档、存储组件。Graph在收到数据以后，会以rrdtool的数据归档方式来存储，同时提供RPC方式的监控查询接口。
5）Judge告警模块，Transfer转发到Judge的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警引入了Redis暂存告警，从而完成告警的合并和抑制。
6）Dashboard是面向用户的监控数据查询和告警配置界面。
Nagios
Nagios原名为NetSaint，由Ethan Galstad开发并维护。Nagios是一个老牌监控工具，由C语言编写而成，主要针对主机监控（CPU、内存、磁盘等）和网络监控（SMTP、POP3、HTTP和NNTP等），当然也支持用户自定义的监控脚本。
它还支持一种更加通用和安全的采集方式NREP（Nagios Remote Plugin Executor），它首先在远端启动一个NREP守护进程，用于在远端主机上面运行检测命令，在Nagios服务端用check nrep的plugin插件通过SSL对接到NREP守护进程执行相应的监控行为。相比SSH远程执行命令的方式，这种方式更加安全。
Prometheus
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
Prometheus 的几大组件：
-
**Prometheus Server，**用于收集和存储时间序列数据，负责监控数据的获取，存储以及查询。
-
**监控目标配置，**Prometheus Server 可以通过静态配置管理监控目标，也可以配合 Service Discovery（K8s，DNS，Consul）实现动态管理监控目标。
-
**监控目标存储，**Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列存储在本地磁盘中。
-
**监控数据查询，**Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。
-
**Client Library，**客户端库。为需要监控的服务生成相应的 Metrics 并暴露给 Prometheus Server。
当 Prometheus Server 来 Pull 时，直接返回实时状态的 Metrics。通常会和 Job 一起合作。
-
**Push Gateway，**主要用于短期的 Jobs。由于这类 Jobs 存在时间较短，可能在 Prometheus 来 Pull 之前就消失了。为此，这些 Jobs 可以直接向 Prometheus Server 端推送它们的 Metrics。
-
**Exporters，**第三方服务接口。将 Metrics（数据集合）发送给 Prometheus。
Exporter 将监控数据采集的端点，通过 HTTP 的形式暴露给 Prometheus Server，使其通过 Endpoint 端点获取监控数据。
-
**Alertmanager，**从 Prometheus Server 端接收到 Alerts 后，会对数据进行处理。例如：去重，分组，然后根据规则，发出报警。
-
**Web UI，**Prometheus Server 内置的 Express Browser UI，通过 PromQL 实现数据的查询以及可视化。
Prometheus Server负责定时在目标上抓取metrics（指标）数据并保存到本地存储里面。Prometheus采用了一种Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。
如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger，通过告警的抑制后触发邮件或者webhook。Prometheus支持PromQL提供多维度数据模型和灵活的查询，通过监控指标关联多个tag的方式，将监控数据进行任意维度的组合以及聚合。
综合对比
1）从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到Go。
2）从系统成熟度上看，Zabbix和Nagios都是老牌的监控系统：Nagios是在1999年出现的，Zabbix是在1998年出现的，系统功能比较稳定，成熟度较高。而Prometheus和Open-Falcon都是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验；
3）从系统扩展性方面看，Zabbix和Open-Falcon都可以自定义各种监控脚本（Zabbix4.2也开始支持Prometheus的exporter），并且Zabbix不仅可以做到主动推送，还可以做到被动拉取，Prometheus则定义了一套监控数据规范，并通过各种exporter扩展系统采集能力。
4）从数据存储方面来看，Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能（Zabbix4.2开始支持时序数据库，但仅是验证阶段）Nagios和Open-Falcon都采用RDD数据存储，Open-Falcon还加入了一致性hash算法分片数据，并且可以对接到OpenTSDB，而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储；
5）从配置复杂度上看，Prometheus只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，尤其是Open-Falcon。
6）从社区活跃度上看，目前Zabbix和Nagios的社区活跃度比较低，尤其是Nagios，Open-Falcon虽然也比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势，社区活跃度最高，并且受到CNCF的支持，后期的发展值得期待；
7）从容器支持角度看，由于Zabbix和Nagios出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。Open-Falcon虽然提供了容器的监控，但支持力度有限。Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。而Nagios则在网络监控方面有广泛应用，伴随着容器的发展，Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。
总体来说，对比各种监控系统的优劣，Prometheus可以说是目前监控领域最火的弄潮儿。
参考：
[1]: https://mp.weixin.qq.com/s/hUuZQVK1uYjXTqx2q1fZCg
[2]: https://blog.csdn.net/u013256816/article/details/101443288
[3]: https://blog.csdn.net/crave_shy/article/details/81334845#2-%E4%B8%BA%E4%BB%80%E4%B9%88%E9%9C%80%E8%A6%81%E7%9B%91%E6%8E%A7%E4%BD%93%E7%B3%BB
[4]: https://juylee.github.io/2018/08/27/%E6%97%B6%E5%BA%8F%E6%95%B0%E6%8D%AE%E5%BA%93/