系统监控之Prometheus

三种主要监控方式：
1. Logging
2. Tracing
3. Metrics

	Metrics	Logging	Tracing
CapEx	Medium	Low	High
OpEx	Low	High	Medium
Reaction	High	Medium	Low
Investigation	Low	Medium	High

CapEx: the initial cost to start instrumenting and collecting the signals;
OpEx: the ongoing cost to run the supporting infrastructure;
Reaction: how good the system is at detecting and alerting on incidents;
Investigation: how much the system can help to triage and debug incidents.

DevOps理念：要提升必先测量

“if you can't measure it, you can't improve it”      --------Lord Kelvin

监控问题：

1.运维人员只专注系统监控（日志，负载度量），没有应用监控能力和上下文

2.开发人员只管实现功能，没有 DevOps 和度量意识

3.应用监控空白，对应用状态无感知，很多功能开发了无人用

4.业务对关键应用指标无感知，很多功能开发了无人用

监控四个黄金指标：

1. 延迟：服务请求所需耗时
例如 HTTP请求平均延迟

2.流量/吞吐： 衡量服务容量需求
例如 每秒处理HTTP请求数

3.错误：衡量错误发生的情况
例如 HTTP 500错误数

4.饱和度：衡量资源使用情况
例如 CPU/内存/磁盘使用量

Prometheus 概述

Prometheus （中文名：普罗米修斯）是由 SoundCloud 开发的开源监控报警系统和时序列数据库(TSDB)。自2012年起,许多公司及组织已经采用 Prometheus,并且该项目有着非常活跃的开发者和用户社区。现在已经成为一个独立的开源项目。Prometheus 在2016加入 CNCF ( Cloud Native Computing Foundation ), 作为在 kubernetes 之后的第二个由基金会主持的项目。Prometheus 的实现参考了Google内部的监控实现，与源自Google的Kubernetes结合起来非常合适。它针对大规模的集群环境设计了拉取式的数据采集方式，只需要在应用里面实现一个metrics接口，然后把这个接口告诉Prometheus就可以完成数据采集了。

Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。

Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。近几年随着k8s的流行，Prometheus成为了一个越来越流行的监控工具。

node-exporter组件负责收集节点上的metrics监控数据，并将数据推送给Prometheus, Prometheus负责存储这些数据，grafana将这些数据通过网页以图形的形式展现给用户。

作为新一代的监控框架，Prometheus 具有以下特点：

1> 多维数据模型（时序列数据由metric名和一组key/value组成）
2> 非常高效的存储，平均一个采样数据占~3.5bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G
3> 在多维度上灵活的查询语言( PromQL )
4> 不依赖分布式存储，单主节点工作
5> 通过基于HTTP的pull方式采集时序数据
6> 可以通过push gateway进行时序列数据推送(pushing)
7> 可以通过服务发现或者静态配置去获取要采集的目标服务器
8> 多种可视化图表及仪表盘支持

Prometheus 相关组件：

1) Prometheus server 主要负责数据采集和存储，定期从静态配置的 targets 或者服务发现（主要是DNS、consul、k8s、mesos等）的 targets 拉取数据，提供PromQL查询语言的支持
2) 客户端sdk，用来构造应用或 exporter 代码，官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等
3） Push Gateway 支持 Job 主动推送指标的中间网关
4） exporters 支持其他数据源的指标导入到Prometheus，支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等
5） alertmanager 是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。
6） 可视化的dashboard ，主要通过grafana来实现webui展示

Prometheus配置运行

Prometheus 也是通过定义配置文件，来给prometheus本身规定需要监控的项目和被监控节点，prometheus.yml配置文件：

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']
  - Job_name: ‘job_name’
    static_configs:
      -targets: [‘localhost:9100’,’192.168.1.180:9100’]

配置文件中配置的三个模块：global，rule_files，和scrape_configs

global 模块是prometheus的全局配置：

scrape_interval：表示 prometheus 抓取指标数据的频率，默认是15s，我们可以覆盖这个值
evaluation_interval：用来控制评估规则的频率，prometheus 使用规则产生新的时间序列数据或者产生警报

rule_files 模块制定了规则所在的位置，prometheus 可以根据这个配置加载规则，用于生成新的时间序列数据或者报警信息，当前我们没有配置任何规则。

scrape_configs模块 用于控制 prometheus 监控哪些资源。由于 prometheus 通过 HTTP 的方式来暴露的它本身的监控数据，prometheus 也能够监控本身的健康情况。在默认的配置里有一个单独的 job，叫做prometheus，它采集 prometheus 服务本身的时间序列数据。这个 job 包含了一个单独的、静态配置的目标：监听 localhost 上的9090端口。prometheus 默认会通过目标的/metrics路径采集 metrics。所以，默认的 job 通过 URL：http://localhost:9090/metrics采集 metrics。收集到的时间序列包含 prometheus 服务本身的状态和性能。如果我们还有其他的资源需要监控的话，直接配置在该模块下面就可以了。

Prometheus本身是一个以进程方式启动，之后以多进程和多线程实现监控数据收集、计算、查询、更新、存储的这样一个C/S模型运行模式。

#./prometheus --web.listen-address=0.0.0.0:9090 --web.read-timeout=5m --web.max-connection=10 --storage.tsdb.retention=15d  --storage.tsdb.path=/data/prometheus/  --query.max-concurrency=20 --query.timeout=3m

--web.read-timeout=5m         请求链接的最大等待时间
--web.max-connection          最大链接数
--storage.tsdb.retention=15d 数据保留期限的设置，企业中设置15天为宜
--storage.tsdb.path               数据存储路径
--query.max-concurrency     最大并发查询用户数量
--query.timeout                     查询timout设置时间   


Prometheus的数据模型

Prometheus从根本上所有的存储都是按时间序列去实现的，相同的metrics(指标名称) 和label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。

metrics name&label指标名称和标签：

每条时间序列是由唯一的“指标名称”和一组”标签（key=value）”的形式组成。

指标名称：一般是给监测对像起一名字，例如http_requests_total这样，它有一些命名规则，可以包字母数字_之类的的。通常是以应用名称开头_监测对像_数值类型_单位这样。例如：push_total、userlogin_mysql_duration_seconds、app_memory_usage_bytes。

标签：就是对一条时间序列不同维度的识别了，例如一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

记住，针对http_requests_total这个metrics name无论是增加标签还是删除标签都会形成一条新的时间序列。

查询语句就可以跟据上面标签的组合来查询聚合结果了。

如果以传统数据库的理解来看这条语句，则可以考虑http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储）。

Prometheus metrics四种数据类型

1.Counter（计数器）：
Counter用于累计值，例如记录请求次数、任务完成数、错误发生次数。一直增加，不会减少。重启进程后，会被重置。

例如：http_response_total{method=”GET”,endpoint=”/api/tracks”} 100，10秒后抓取http_response_total{method=”GET”,endpoint=”/api/tracks”} 100。

2.Gauge（仪表盘）：
Gauge常规数值，用于反应该样本的当前状态，例如 温度变化、内存使用变化、磁盘使用率。可变大，可变小。重启进程后，会被重置。

例如：memory_usage_bytes{host=”master-01″} 100 < 抓取值、memory_usage_bytes{host=”master-01″} 30、memory_usage_bytes{host=”master-01″} 50、memory_usage_bytes{host=”master-01″} 80 < 抓取值。

3.Histogram（直方图）：
Histogram（直方图）可以理解为柱状图的意思，常用于跟踪事件发生的规模，通过分桶(bucket)方式统计样本分布，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供count和sum全部值的功能。

例如：{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值。

4.Summary（摘要/汇总）：
Summary根据样本统计出百分位，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。

例如：count=7次，sum=7次的值求值。

它提供一个quantiles的功能，可以按%比划分跟踪的结果。例如：quantile取值0.95，表示取采样值里面的95%数据。