1.Prometheus监控入门之基础架构介绍

0x00 前言简述

0.学习导读
1.开源监控系统简史
2.Prometheus 基础简介
3.Prometheus 架构组件
4.Prometheus 基本原理
5.Prometheus 数据模型和类型
6.Prometheus 学习参考

0.学习导读

Q: 什么是监控?
描述: 一般的将这类可操作的计算机系统归纳为以下四个特征;

1.告警:掌握故障的发生时间并通知相应人员(监控的重要目标)。
2.调试:通过相应人员后需要根据判断错误根源来解决问题。
3.趋势:展示一段时间内系统相应指标的发生变化趋势(该特征影响架构设计和处理)。
4.管道:监控系统的数据处理管道用作于定制采集。

Q: 监控采集数据存储量优化解决方案?
描述: 我们知道系统的数据监控采集必不可少都要处理或者存储采集到的数据,但是往往我们只需要针对某一事件的度量值进行存储，而其他值只是作为瞬间或者某一时间段内监控指标进行匹配对比报警，所以我们为了减少系统资源的消耗，采用以下四种方案来尽可能的减少数据存储量。

1.剖析: 在无法提供事件的完整上下文时，可以截取某一段有限时间内的上下文作为剖析对象。(主要用作计算调试)
2.跟踪: 并不是关注所有事件而是采集某项指标的事件。(主要用于某一个指标的异常分析)
3.日志: 它关注的是一组有限的事件并记录每个事件的一些上下文。(通常日志记录的事件记录并非采集式)
4.指标: 它在很大程度上忽略了上下文而是跟踪不同类型事件随时间的聚合。(严格限制指标数量采集特定指标的数据)

Q: 日志分类说明？
描述: 根据不同类型的日志有着不同的用处、耐用性和保留要求，大致分为以下四类。

1.事务日志: 关键业务记录需要永久保存,主要涉及金钱和面向用户的关键性功能。
2.请求日志: 例如HTTP请求和数据库请求主要用于业务的处理优化和访问趋势。
3.应用日志: 即应用进程本身的日志通常是人为处理，主要涉及启动信息、后台运行任务以及其他进程级别的日志。
4.调试日志: 在应用或者程序出现莫名其妙的的Bug开启所有其日志在可靠性和保留性要求较低。

1.开源监控系统简史

描述: 下面列举出比较常用的开源监控系统Nagios ['negos']、Cacti 英 [ˈkæktaɪ]、Ganglia 英 [ˈgæŋglɪə]、Zabbix、Openfalcon、Prometheus

监控软件发展历史简述:

1994 年 - MRTG 1.0 由 Tobias Oetiker 编写主要是通过SNMP协议来监控网络。
1996 年 - NetSaint 由 Ethan Galstad 创建的作为一个MS-DOS应用来执行ping命令
1997 年 - MRTG 1.0 改进而来采用C进行重写并创造了用于存储指标数据的RRD(Round Robin Database)。
2002 年 - Nagios 由 NetSaint 重命名
2006 年 - Graphite 使用与 RRD 类似的设计的Whisper来做指标数的存储。(其本身不会收集数据而是将数据发送给收集工具)
cacti
zabbix
2012 年 - Prometheus 由Sound Cloud开发者进行维护开发后2016年加入到CNCF成为了第二个成员。

Nagios
描述: 它是一款免费的开源 IT 基础设施监控系统,基于CS架构。

优点：通过安装插件和编写监控脚本，可以实现对目标灵活的监控
缺点：无法查询历史数据

Cacti
描述: 基于php/mysql/snmp及rrdtool开发的网络流量监测图形分析工具

优点：机房、流量监控方面应用较广泛
缺点：报警比较简陋

Ganglia
描述: 用于监控数以千计的节点的基础性能和流量使用情况。

优点：部署方便，用不同分层管理上万台机器，无需逐个添加配置；ganglia服务端能通过一台客户端收集到同一个网段的所有客户端的数据；ganglia集群服务端能够通过一台服务端收集到它下属的所有客户端数据。
缺点：没有内置的消息系统，无法报警

Openfalcon
描述: OpenFalcon是一款企业级、高可用、可扩展的开源监控解决方案(企业使用较多)。

优点: 支持多种方式报警，且会对警告进行合并处理，不会进行短信轰炸。
缺点: 社区支持不完善、基础软件监控不支持

Zabbix
描述: Zabbix 是一个企业级的分布式开源监控方案，需要在被监控主机中安装Agent(个人、企业使用较多)。

优点:

中
使用成本低安装部署简单，百分之95%的功能都可以在Web UI界面上进行操作，主机监控添加方便。

缺点: 自定义监控脚本编写复杂

Why use Prometheus?
描述: 这里不得不提到老生常谈的东西，人们使用机器方法演变/监控选型；

1.最初人们直接使用物理机，将进程直接跑在物理机上面
- 从监控的角度考虑：监控起来最方便，复杂度最低
2.后来人们开始在物理机中进行虚拟化来安装多台虚拟机例如(VMware/kvm)
- 从监控角度来讲：相对比较复杂，我们要知道哪台机器上跑了哪些虚拟机，同时还要知道每个虚拟机里面跑了什么程序
3.最后由于docker容器的出现进行了，翻起了新一轮的技术革命。
- 从监控角度来讲：监控起来复杂度非常高，我们要知道每台机器上跑了哪些docker，和每个docker的资源使用情况，(很难用静态方法去监控)
4.现在由于云环境的火热常采用 Kubernetes 对 Docker 容器进行编排，极大的提高了运维效率;
- 从监控角度来讲：Prometheus是在Kubernetes孕育而来，在原生支持上面提到的各种工具的监控。

总结说明:

Prometheus并不是最好的监控系统，它不适用于存储事件日志或者单一的事件以及敏感信息采集，选择它的主要原因是他对云环境的原生支持；
Promethus 专门运行监控而设计存在由于某些因素(例如内核调度和抓取故障)导致一些数据不准确和资源竞争的现象，即并不能保证数据的绝对准确性。
恰好现在云环境是当前最火，应用最广泛的解决方案；
监控是应用于服务的，不同的服务场景选择不同的监控软件，切勿盲从；

2.Prometheus 基础简介

简介: Prometheus 是一个开源的云原生基于指标的监控系统以及告警系统，泛义上包括监控，告警，时序数据库(TSDB)，各种指标收集器(Exporter)组成。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控, 所以它主要用于容器监控和k8s集群监控以及云环境的监控(OpenStack)。

2016年 Prometheus 加入了云原生计算基金会(Cloud Native Computing Foundation,CNCF)，成为kubernetes之后的第二个托管项目 google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。

官网介绍: 从度量到洞察使用领先的开源监控解决方案。

Dimensional data (高维数据) : Prometheus implements a highly dimensional data model. Time series are identified by a metric name and a set of key-value pairs.

Powerful queries (强大的查询) : PromQL allows slicing and dicing of collected time series data in order to generate ad-hoc graphs, tables, and alerts.

Great visualization (UI-视觉效果) : Prometheus has multiple modes for visualizing data: a built-in expression browser, Grafana integration, and a console template language.

Efficient storage (高效的存储) : Prometheus stores time series in memory and on local disk in an efficient custom format. Scaling is achieved by functional sharding and federation.

Simple operation (操作简单) : Each server is independent for reliability, relying only on local storage. Written in Go, all binaries are statically linked and easy to deploy.

Precise alerting (精确报警) :
Alerts are defined based on Prometheus's flexible PromQL and maintain dimensional information. An alertmanager handles notifications and silencing.

Many client libraries (众多客户端库) : Client libraries allow easy instrumentation of services. Over ten languages are supported already and custom libraries are easy to implement.

Many integrations (许多集成监控指标) : Existing exporters allow bridging of third-party data into Prometheus. Examples: system statistics, as well as Docker, HAProxy, StatsD, and JMX metrics.

优点:

定制化难度低: 后端采用Go语言开发、前端可用Grafana直接进行Json编辑
开箱即用的各种服务发现机制，可以自动发现监控端点
专为监控指标数据设计的高性能时序数据库TSDB，单机单实例支持数十万监控项/每秒
强大易用的查询语言PromQL以及丰富的聚合函数便于对已有数据进行新的聚合。
生态完善有各种现成的开源Exporter实现，自定义的监控指标也非常简单
配置灵活的告警规则，支持告警分组、抑制、静默、路由等等高级功能
高可用的架构核心组件都有高可用解决方案
强大的功能除了云平台之外还支持主机、各种db资源、web网站、dns、网络延时、端口连通性、各种语言写的程序监控等等;
成熟的社区和健全的生态：

缺点:

安装相对复杂、监控、告警和界面都分属于不同的组件。
没有任何监控告警之外的功能(用户/角色/权限控制等等),需要多配置必须在配置文件中修改。
通过 HTTP 拉取监控数据效率不够高

Tips: 保有量最多的三种监控系统(Zabbix、Openfalcon、Promethes)方式对比;

3.Prometheus 架构组件

描述: Prometheus 架构由客户端在被监控系统上利用导出器采集指标数据，在服务端配置静态目标或者动态的服务发现，此时Prometheus 根据抓取频率进行数据的拉取(exporter)和推送(pushgateway), 然后将抓取的数据存储到时序数据库(TSDB)之中，再利用Grafana的仪表盘展示Prometheus服务中的数据，同时设定记录规则(PromQL表达式)和告警规则(频率)并发送给alertmanager进行发送报警事件到运维人员手中，最终可能还需要进行数据的持久化默认的是本地存储但可以通过远程读写的API让其他系统也可接入采集存储数据。

Prometheus 监控体系如下图几大部分构成:

1.Prometheus server : 主要负责数据采集和存储，提供PromQL查询语言的支持 (默认端口: 9090)
2.exporters : 监控指标采集器，支持数据库、硬件、消息中间件、http 服务器、jmx 等 (默认端口:)
3.alertmanager : 用来进行报警、prometheus_cli：命令行工具 (默认端口: 9093)
4.Web UI : 原生UI功能较为单一，常常采用Grafana这个跨平台的开源的分析和可视化工具 (默认端口: 3000)
5.PushGateWay : 跨网段被监控主机指标采集数据转发到网关代理等待Server的Pull。
6.Time Series DataBase : 时序数据库(TSDB)用于保存时间序列（按时间顺序变化）的数据,每条记录都有完整的时间戳，基于时间的操作都比较方便.

Q:采用时序数据库(TSDB)的优点?

1.时间作为他的主轴，数据按顺序到达。

2.大多数操作是插入新数据，偶尔伴随查询，更新数据比较少。

3.时间序列数据累计速度非常快，更高的容纳率、更快的大规模查询以及更好的数据压缩。

4.TSDB 通常还包括一些共通的对时间序列数据分析的功能和操作:数据保留策略、连续查询、灵活的时间聚合等。

Q:什么是微服务架构?

他的组件是可以独立工作的，每个组件都不依赖其他的组件

配置文件来将不同的模块关联到一起，实现整个监控的功能

每个独立的模块都可以扩展，做高可用方案

4.Prometheus 基本原理

描述: Prometheus 基本工作流程步骤如下:

Setp 1.Prometheus Server 读取配置解析静态监控端点（static_configs），以及服务发现规则(xxx_sd_configs)自动收集需要监控的端点
Setp 2.Prometheus Server 周期刮取(scrape_interval)监控端点通过HTTP的Pull方式采集监控数据
Step 3.Prometheus Server HTTP 请求到达 Node Exporter，Exporter 返回一个文本响应，每个非注释行包含一条完整的时序数据：Name + Labels + Samples(一个浮点数和一个时间戳构成), 数据来源是一些官方的exporter或自定义sdk或接口;

Step 4.Prometheus Server 收到响应，Relabel处理之后(relabel_configs)将其存储在TSDB中并建立倒排索引
Step 5.Prometheus Server 另一个周期计算任务(evaluation_interval)开始执行，根据配置的Rules逐个计算与设置的阈值进行匹配，若结果超过阈值并持续时长超过临界点将进行报警，此时发送Alert到AlertManager独立组件中。
Step 6.AlertManager 收到告警请求，根据配置的策略决定是否需要触发告警，如需告警则根据配置的路由链路依次发送告警，比如邮件、微信、Slack、PagerDuty、WebHook等等。
Step 7.当通过界面或HTTP调用查询时序数据利用PromQL表达式查询，Prometheus Server 处理过滤完之后返回瞬时向量(Instant vector, N条只有一个Sample的时序数据)，区间向量(Range vector，N条包含M个Sample的时序数据)，或标量数据 (Scalar, 一个浮点数)
Step 8.采用Grafana开源的分析和可视化工具进行数据的图形化展示。

5.Prometheus 数据模型和类型

描述: metrics name & label 指标名称和标签(key=value)的形式组成的数据模型，其次是Prometheus惯例是使用基本单元如字节(Byte)和秒(s);

metrics name : 一般由字母和下划线构成 prometheus_http_requests_total
Lable : 标签就是对一条时间序列不同维度的识别 (应用名称=name_监测对像=object_数值类型=int_单位=ok)。

基础示例:

# 数据模型 : metric  @ timestamp  =>  value
http_requests_total{status="200",method="GET"}@1434417560938  => 94355# 数据格式 : Metric_Name{key="value"}
go_info{instance="localhost:9090", job="prometheus", version="go1.16.2"}

数据类型
描述: Prometheus 常常使用以下核心指标类型 Counter(计数器类型) 、Gauge(仪表盘类型) 、Histogram(直方图类型)、Summary(摘要类型);

counter 英 [ˈkaʊntə(r)] 类型：该指标的工作方式和计数器一样，只增不减（除非系统发生了重置）。Counter一般用于累计值，例如记录请求次数、任务完成数、错误发生次数,通常来讲许多指标counter本身并没有什么意义，有意义的是counter随时间的变化率如采用rate函数能计算出每秒增长,由 <basename>_total组成。
Gauge 英 [ɡeɪdʒ] 类型 : 可增可减的指标类，可以用于反应当前应用的状态。比如机器内存，磁盘可用空间大小node_memory_MemAvailable_bytes/node_filesystem_avail_bytes等等;
Histogram 英 [ˈhɪstəɡræm] 类型 : 客户端计算主要用于表示一段时间范围内对数据进行采样（通常是请求持续时间或响应大小），并能够对其指定区间以及总数进行统计，通常它采集的数据展示为直方图。由 <basename>_bucket, <basename>_sum， <basename>_count 组成;

所有事件产生值的大小的总和: basename_sum
事件发生的总次数: basename_count
事件产生的值分布: basename_bucket

Summary 英 [ˈsʌməri] 类型 : 与Histogram类型相似主要用于表示一段时间内数据采样结果（通常时请求持续时间或响应大小），它直接存储了分位数据，而不是根据统计区间计算出来的, 由< basename>_sum，< basename>_count,<basename>{quantile="<φ>"}组成;

Q: Histogram 与 Sumamry 的两者区别?

Histogram 指标: 直接反应了在不同区间内样本的个数，区间通过标签len进行定义，同时对于Histogram的指标，我们还可以通过histogram_quantile()函数计算出其值的分位数。
Sumamry 指标: 分位数则是直接在客户端计算完成。

因此Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之对于客户端而言Histogram消耗的资源更少。
在选择这两种方式时用户应该按照自己的实际场景进行选择。

6.Prometheus 学习参考

描述: 当前2021年4月30日Prometheus Server版本: v2.26.0下载地址:https://prometheus.io/download/
官方地址: https://prometheus.io/0
项目地址:

https://github.com/prometheus/
https://github.com/prometheus-community

帮助文档: https://prometheus.io/docs/prometheus/latest/getting_started/

# 关注 WeiyiGeek 微信公众号

历史文章:

1-Kubernetes基础入门体系架构学习(一)

2-Kubernetes基础入门体系架构学习(二)

3-Kubernetes入门之CentOS上安装部署k8s集群