监控

监控

从程序设计的角度来看，监控分为基础资源监控，中间件监控，应用程序监控和日志监控。

基础资源监控

网络监控

网络监控主要在以下几个方向
1.网络性能监控：涉及网络监测，网络实时流量监控和历史数据统计、汇总和历史分析等功能。
2.网络攻击检查：主要针对内外网的网络攻击，如DDoS攻击等，通过分析异常流量来确定网络攻击行为。
3.设备监控：针对数据中心内的多种网络设备进行监控，包括路由器、防火墙和交换机等硬件设备，可以通过SNMP(simple networkl managerment protocol ，网络管理协议，主要用于支持网络管理系统)协议收集数据。

存储监控

1.云存储监控：通过存储设备构建存储资源池，并对操作系统提供统一的存储接口。特点是存储接口统一，并不识别存储数据的格式和内容。
2.分布式存储：构建于操作系统之上，提供分布式集群存储服务，主要针对特定数据结构的数据存储。

服务器监控

主要应用于服务器主机监控，虚拟机监控和容器监控。

中间件监控

中间件指系统软件和应用软件之间的连接软件。中间件由于需要针对不同的中间件特点和属性分别监控，所以没有统一的标准和规范。

应用程序监控

APM主要用于针对应用程序的监控，包括应用程序的运行状态监控、性能监控、日志监控以及调用链跟踪等。

日志监控

区别于指标监控，日志监控采集日志数据(文本类型)，并将这些数据汇总到日志存储和搜索引擎当中，提供日志检索的web接入。指标监控的对象一般都是数字，而日志监控的对象是文本数据，因为对于存储系统的要求是具备文本检索功能。
日志监控出了可以应用于性能问题定位以外，还能用于数据统计和故障告警。
当下比较热门的日志监控组合如下：
Fluentd：日志监控。kafka：整流合并。Logstash：日志整理，具有日志过滤日志修改等功能。Elasticsearch：负责日志存储和日志检索，自带分布式存储。Kibana：日志查询组件，负责日志展现。

prometheus

特点

1.提供多维度数据模型和灵活的查询方式，可以实现多个监控指标关联，并提供HTTP查询接口。
2.不依赖外部数据存储的情况下，支持服务器节点的本地存储。
3.定义开放指标的数据标准，以基于HTTP的pull方式采集时序数据。
4.支持通过静态文件配置和动态发现机制发现监控对象。
5易于维护，可以通过二进制文件直接启动。
6.支持数据的分区采样和联邦部署，支持大规模集群监控。

架构

prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合prometheus的数据格式，就可以接入prometheus监控。

Prometheus从exporter拉取数据，或者间接地通过网关gateway拉取数据（如果在k8s内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，采集到的数据有两个去向，一个是报警，另一个是可视化。PromQL和其他API可视化地展示收集的数据，并通过Alertmanager提供报警能力。
获取监控对象方面，prometheus主要通过两种方式：
1.通过配置文件、文本文件等进行静态配置。
2.zookeeper、consul、kubernetes等方式进行动态发现。比如利用kubernetes的api查询和监控容器信息的变化，动态更新监控对象，这样容器的删除和创建都可以被prometheus感知。
storage通过一定的规则清理和整理数据，把得到的结果存储到新的时间序列中。存储方式主要有两种：
1.本地存储TSDB: 存储模块默认本地存储为tsdb
2.远端存储：主要是openTSDB、influxDB等后端存储
另外prometheus通过promql和其他API可视化地展示收集的数据。并支持多种方式的图表可视化。
上图组件基本内容：

Prometheus Server

负责从 Exporter 拉取和存储监控数据,并提供一套灵活的查询语言（PromQL）
Retrieval: 采样模块
TSDB: 存储模块默认本地存储为tsdb
HTTP Server: 提供http接口查询和面板，默认端口为9090

Exporters/Jobs

prometheus已经是云原生应用监控行业的标准，虽然很多流行的监控系统都已经实现了prometheus监控接口。但是大多数监控对象都没有直接提供监控接口。所以需要exporter来采集监控数据，并通过prometheus监控规范对外提供数据的组件。负责收集目标对象（host, container…）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。只要符合接口格式，就可以被采集。

Short-lived jobs

瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用

PushGateway

可选组件，主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。

Alertmanager

从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，钉i钉, webhook 等。

Service Discovery

服务发现，Prometheus支持多种服务发现机制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。

指标

指标定义

分为指标名称和标签

<metric name>(<label name>=<label value>, ...)

指标分类

1.counter：只增不减，如访问量
2.gauge：可增可减，如内存使用量
3.summary：通过采样分位图统计，了解某个时间段的分布情况
4.histogram：反映某个区间内的样本个数。

数据采集

prometheus只要采用pull的方式来提取数据与push的区别主要是主动与被动。
push与pull的区别：
1.push实时性相对较好，采集数据后立即上报。但是本地不会保存数据，agent本身是无状态的，master需要维护各个agent的状态，并且每个agent要配置master的地址。
2.pull实时性差，周期性采集数据。agent要保留数据存储功能，master只负责提取因此可以做到无状态，agent不用感知master的存在。

获取采集对象

1.静态文件配置：

"targets":["10.10.10.10:8080"]

如上代码表示监控对象的地址是10.10.10.10，端口号是8080，prometheus会周期的调用这个监控对象。但是如果想要监控应对服务发生偏移、变更、更换地址以及端口，就需要动态发现的方式来获取监控对象。

2.动态发现：

相比较之下更适合在云环境下使用。因为晕的理念就是按需供给，资源是动态分配的，并且生命周期比物理机器短。
目前支持以下系统获取监控对象：
1.容器管理平台：kubernetes、marathon
2.各种云管平台：EC2、Azure、OpenStack
3.各种服务组件：DNS、ZooKeeper、Consul
监控对象自动发现流程(以kubernetes为例)：
1.需要在prometheus里配置kubernetes API的地址和认证凭据。这样prometheus就可以连接到kubernetes的API来获取信息。
2.prometheus的服务发现组件会一直监听kubernetes集群的变化，或随着新主机的加入、创建容器等及时获得信息。

3.数据采集

prometheus采用统一的Restfule API的方式获取数据，具体来说就是利用HTTP的GET请求或metrics数据接口获取监控数据，为了高效的采集数据，prometheus对每个采集点启动了一个线程去定时采集数据。
prometheus支持文本数据格式，每个exporter都将监控数据输出成文本数据格式。

存储

1、本地存储

1.v1:每秒最多5w样本数，数据和元数据存储在levelDB上，每15分钟获取一次。宕机时会丢失过去15分钟的数据。
2.v2:性能从5w到了80w，采取每个时序数据以单个文件的方式保存。但是因为每个文件都有10mb，所以会产生严重的时序流失和写放大等问题。
3.v3:性能达到1000w，将监控数据以时间段拆分成不同的block，并且会压缩合并历史数据块。通过wal，避免了宕机丢数据的情况。相比v2，cpu使用率降低三倍，磁盘I/O降低10倍。
Prometheus按2小时一个block进行存储，每个block由一个目录组成，该目录里包含：一个或者多个chunk文件（保存timeseries数据）、一个metadata文件、一个index文件（通过metric name和labels查找timeseries数据在chunk文件的位置）。
最新写入的数据保存在内存block中，达到2小时后写入磁盘。为了防止程序崩溃导致数据丢失，实现了WAL（write-ahead-log）机制，启动时会以写入日志(WAL)的方式来实现重播，从而恢复数据。

2、远端存储

其中adapter需要实现prometheus的read、wirte接口。并且将read、write转化为每种数据库各自的协议。用户查询数据时，prometheus会通过配置的查询接口发送HTTP请求，Adapter会返回相应的时序数据。
整体可以理解为：
存储的方式为：Prometheus —-发送数据—- > remote_storage_adapter —- 存储数据 —-> influxdb。
prometheus通过下面两种方式来实现与其他的远端存储系统对接：
Prometheus 按照标准的格式将metrics写到远端存储
Prometheus 按照标准格式从远端的url来读取metrics