Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。Prometheus 于2016年加入了 Cloud Native Computing Foundation，这是继Kubernetes之后的第二个托管项目。
官网：https://prometheus.io 最新版本: 2.19.2
Exporter是一个采集监控数据并通过Prometheus监控规范对外提供数据的组件，能为Prometheus提供监控的接口。
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。不同的Exporter负责不同的业务。
Prometheus 开源的系统监控和报警框架，灵感源自Google的Borgmon监控系统 AlertManager 处理由客户端应用程序（如Prometheus server）发送的警报。它负责将重复数据删除，分组和路由到正确的接收者集成，还负责沉默和抑制警报 Node_Exporter 用来监控各节点的资源信息的exporter，应部署到prometheus监控的所有节点 PushGateway 推送网关，用于接收各节点推送的数据并暴露给Prometheus server文档：https://prometheus.io/docs/introduction/overview/
下载prometheus各组件：
https://prometheus.io/download/
下图说明了Prometheus的体系结构及其某些生态系统组件：
prometheus的使用场景：prometheus非常适合记录任何纯数字时间序列。它既适合以机器为中心的监视，也适合监视高度动态的面向服务的体系结构。在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。
prometheus的设计旨在提高可靠性，使其成为中断期间要使用的系统，从而使您能够快速诊断问题。每个prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务，当基础设施部分出现问题时仍然可以使用它。
prometheus将所有数据存储为时间序列：属于相同 metric名称和相同标签组（键值对）的时间戳值流。
metric 和 标签：每一个时间序列都是由其 metric名称和一组标签（键值对）组成唯一标识。
metric名称代表了被监控系统的一般特征（如 http_requests_total代表接收到的HTTP请求总数）。它可能包含ASCII字母和数字，以及下划线和冒号，它必须匹配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。
注意：冒号是为用户定义的记录规则保留的，不应该被exporter使用。
标签给prometheus建立了多维度数据模型：对于相同的 metric名称，标签的任何组合都可以标识该 metric的特定维度实例（例如：所有使用POST方法到 /api/tracks 接口的HTTP请求）。查询语言会基于这些维度进行过滤和聚合。更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。
标签名称可能包含ASCII字母、数字和下划线，它必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。另外，以双下划线__开头的标签名称仅供内部使用。
标签值可以包含任何Unicode字符。标签值为空的标签被认为是不存在的标签。
表示法：给定 metric名称和一组标签，通常使用以下表示法标识时间序列：
<metric name>{<label name>=<label value>, ...}例如，一个时间序列的 metric名称是 api_http_requests_total，标签是 method="POST" 和 handler="/messages"。可以这样写：
api_http_requests_total{method="POST", handler="/messages"}这和OpenTSDB的表示法是一样的。
metric类型： Counter 值只能单调增加或重启时归零，可以用来表示处理的请求数、完成的任务数、出现的错误数量等 Gauge 值可以任意增加或减少，可以用来测量温度、当前内存使用等 Histogram 取样观测结果，一般用来请求持续时间或响应大小，并在一个可配置的分布区间（bucket）内计算这些结果，提供所有观测结果的总和 累加的 counter，代表观测区间：<basename>_bucket{le="<upper inclusive bound>"} 所有观测值的总数：<basename>_sum 观测的事件数量：<basenmae>_count Summary 取样观测结果，一般用来请求持续时间或响应大小，提供观测次数及所有观测结果的总和，还可以通过一个滑动的时间窗口计算可分配的分位数 观测的事件流φ-quantiles (0 ≤ φ ≤ 1)：<basename>{quantile="φ"} 所有观测值的总和：<basename>_sum 观测的事件数量：<basename>_count 实例与任务：在prometheus中，一个可以拉取数据的端点叫做实例（instance），一般等同于一个进程。一组有着同样目标的实例（例如为弹性或可用性而复制的进程副本）叫做任务（job）。
当prometheus拉取目标时，它会自动添加一些标签到时间序列中，用于标识被拉取的目标：
job：目标所属的任务名称 instance：目标URL中的<host>:<port>部分如果两个标签在被拉取的数据中已经存在，那么就要看配置选项 honor_labels 的值来决定行为了。
每次对实例的拉取，prometheus会在以下的时间序列中保存一个样本（样本指的是在一个时间序列中特定时间点的一个值）：
up{job="<job-name>", instance="<instance-id>"}：如果实例健康（可达），则为 1 ，否则为 0 scrape_duration_seconds{job="<job-name>", instance="<instance-id>"}：拉取的时长 scrape_samples_post_metric_relabeling{job="<job-name>", instance="<instance-id>"}：在 metric relabeling 之后，留存的样本数量 scrape_samples_scraped{job="<job-name>", instance="<instance-id>"}：目标暴露出的样本数量up 时间序列对于实例的可用性监控来说非常有用。
访问ip:9090，
prometheus部署完成，接下来需要配置prometheus。
prometheus的配置文件prometheus.yml，它主要分以下几个配置块：
全局配置 global 告警配置 alerting 规则文件配置 rule_files 拉取配置 scrape_configs 远程读写配置 remote_read、remote_write 全局配置 global：global指定在所有其他配置上下文中有效的参数。还可用作其他配置部分的默认设置。
global: # 默认拉取频率 [ scrape_interval: <duration> | default = 1m ] # 拉取超时时间 [ scrape_timeout: <duration> | default = 10s ] # 执行规则频率 [ evaluation_interval: <duration> | default = 1m ] # 通信时添加到任何时间序列或告警的标签 # external systems (federation, remote storage, Alertmanager). external_labels: [ <labelname>: <labelvalue> ... ] # 记录PromQL查询的日志文件 [ query_log_file: <string> ] 告警配置 alerting：alerting指定与Alertmanager相关的设置。
alerting: alert_relabel_configs: [ - <relabel_config> ... ] alertmanagers: [ - <alertmanager_config> ... ] 规则文件配置 rule_files：rule_files指定prometheus加载的任何规则的位置，从所有匹配的文件中读取规则和告警。目前没有规则。
rule_files: [ - <filepath_glob> ... ] 拉取配置 scrape_configs：scrape_configs指定prometheus监控哪些资源。默认会拉取prometheus本身的时间序列数据，通过http://localhost:9090/metrics进行拉取。
一个scrape_config指定一组目标和参数，描述如何拉取它们。在一般情况下，一个拉取配置指定一个作业。在高级配置中，这可能会改变。
可以通过static_configs参数静态配置目标，也可以使用支持的服务发现机制之一动态发现目标。
此外，relabel_configs在拉取之前，可以对任何目标及其标签进行修改。
scrape_configs: job_name: <job_name> # 拉取频率 [ scrape_interval: <duration> | default = <global_config.scrape_interval> ] # 拉取超时时间 [ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ] # 拉取的http路径 [ metrics_path: <path> | default = /metrics ] # honor_labels 控制prometheus处理已存在于收集数据中的标签与prometheus将附加在服务器端的标签("作业"和"实例"标签、手动配置的目标标签和由服务发现实现生成的标签)之间的冲突 # 如果 honor_labels 设置为 "true"，则通过保持从拉取数据获得的标签值并忽略冲突的服务器端标签来解决标签冲突 # 如果 honor_labels 设置为 "false"，则通过将拉取数据中冲突的标签重命名为"exported_<original-label>"来解决标签冲突(例如"exported_instance"、"exported_job")，然后附加服务器端标签 # 注意，任何全局配置的 "external_labels"都不受此设置的影响。在与外部系统的通信中，只有当时间序列还没有给定的标签时，它们才被应用，否则就会被忽略 [ honor_labels: <boolean> | default = false ] # honor_timestamps 控制prometheus是否遵守拉取数据中的时间戳 # 如果 honor_timestamps 设置为 "true"，将使用目标公开的metrics的时间戳 # 如果 honor_timestamps 设置为 "false"，目标公开的metrics的时间戳将被忽略 [ honor_timestamps: <boolean> | default = true ] # 配置用于请求的协议 [ scheme: <scheme> | default = http ] # 可选的http url参数 params: [ <string>: [<string>, ...] ] # 在每个拉取请求上配置 username 和 password 来设置 Authorization 头部，password 和 password_file 二选一 basic_auth: [ username: <string> ] [ password: <secret> ] [ password_file: <string> ] # 在每个拉取请求上配置 bearer token 来设置 Authorization 头部，bearer_token 和 bearer_token_file 二选一 [ bearer_token: <secret> ] # 在每个拉取请求上配置 bearer_token_file 来设置 Authorization 头部，bearer_token_file 和 bearer_token 二选一 [ bearer_token_file: /path/to/bearer/token/file ] # 配置拉取请求的TLS设置 tls_config: [ <tls_config> ] # 可选的代理URL [ proxy_url: <string> ] # Azure服务发现配置列表 azure_sd_configs: [ - <azure_sd_config> ... ] # Consul服务发现配置列表 consul_sd_configs: [ - <consul_sd_config> ... ] # DNS服务发现配置列表 dns_sd_configs: [ - <dns_sd_config> ... ] # EC2服务发现配置列表 ec2_sd_configs: [ - <ec2_sd_config> ... ] # OpenStack服务发现配置列表 openstack_sd_configs: [ - <openstack_sd_config> ... ] # file服务发现配置列表 file_sd_configs: [ - <file_sd_config> ... ] # GCE服务发现配置列表 gce_sd_configs: [ - <gce_sd_config> ... ] # Kubernetes服务发现配置列表 kubernetes_sd_configs: [ - <kubernetes_sd_config> ... ] # Marathon服务发现配置列表 marathon_sd_configs: [ - <marathon_sd_config> ... ] # AirBnB's Nerve服务发现配置列表 nerve_sd_configs: [ - <nerve_sd_config> ... ] # Zookeeper Serverset服务发现配置列表 serverset_sd_configs: [ - <serverset_sd_config> ... ] # Triton服务发现配置列表 triton_sd_configs: [ - <triton_sd_config> ... ] # 静态配置目标列表 static_configs: [ - <static_config> ... ] # 目标relabel配置列表 relabel_configs: [ - <relabel_config> ... ] # metric relabel配置列表 metric_relabel_configs: [ - <relabel_config> ... ] # 每次拉取样品的数量限制 # metric relabelling之后，如果有超过这个数量的样品，整个拉取将被视为失效。0表示没有限制 [ sample_limit: <int> | default = 0 ] 远程读写配置 remote_read/remote_write：remote_read/remote_write将数据源与prometheus分离，当前不做配置。
# 与远程写功能相关的设置 remote_write: [ - <remote_write> ... ] # 与远程读功能相关的设置 remote_read: [ - <remote_read> ... ] 简单配置示例： vim /usr/local/prometheus/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s alerting: alertmanagers: - static_configs: - targets: # - alertmanager:9093 rule_files: # - "first_rules.yml" # - "second_rules.yml" scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090']node exporter展示了prometheus可以拉取的指标，包括在输出中更下方的各种系统指标（带有前缀node_）。要查看这些指标（以及帮助和类型信息）：
curl http://localhost:9100/metrics | grep 'node_' 配置scrape_configs：启动好node_exporter后，还需要配置prometheus才能访问node exporter指标。
vim /usr/local/prometheus/prometheus.yml #修改 scrape_configs 内容 scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['192.168.30.135:9090'] - job_name: 'node' static_configs: - targets: ['192.168.30.135:9100','192.168.30.136:9100','192.168.30.137:9100'] systemctl restart prometheus 查看node状态：访问prometheus页面，Status → Targets，
可以看到，之前部署的node exporter状态是UP，说明运行正常。
通过部署的node_exporter可以收集当前主机的系统基础信息。如查看系统15分钟平均负载，
node_exporter部署完成。
启动好alertmanager后，还需要配置prometheus才能通过alertmanager告警。
vim /usr/local/prometheus/prometheus.yml #更改 alerting 内容 alerting: alertmanagers: - static_configs: - targets: - 192.168.30.136:9093 scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['192.168.30.135:9090'] - job_name: 'node' static_configs: - targets: ['192.168.30.135:9100','192.168.30.136:9100','192.168.30.137:9100'] - job_name: 'alertmanager' static_configs: - targets: ['192.168.30.136:9093'] systemctl restart prometheus访问prometheus页面，Status → Targets，
可以看到，之前部署的alertmanager状态是UP，说明运行正常。
alertmanager部署完成。但alertmanager还需要进一步配置通知路由和通知接收者。
alertmanager通过命令行标志和配置文件进行配置。命令行标志配置不可变的系统参数时，配置文件定义禁止规则，通知路由和通知接收器。
alertmanager的配置文件alertmanager.yml，它主要分以下几个配置块：
全局配置 global 通知模板 templates 路由配置 route 接收器配置 receivers 抑制配置 inhibit_rules 全局配置 global：global指定在所有其他配置上下文中有效的参数。还用作其他配置部分的默认设置。
global: # 默认的SMTP头字段 [ smtp_from: <tmpl_string> ] # 默认的SMTP smarthost用于发送电子邮件，包括端口号 # 端口号通常是25，对于TLS上的SMTP，端口号为587 # Example: smtp.example.org:587 [ smtp_smarthost: <string> ] # 要标识给SMTP服务器的默认主机名 [ smtp_hello: <string> | default = "localhost" ] # SMTP认证使用CRAM-MD5，登录和普通。如果为空，Alertmanager不会对SMTP服务器进行身份验证 [ smtp_auth_username: <string> ] # SMTP Auth using LOGIN and PLAIN. [ smtp_auth_password: <secret> ] # SMTP Auth using PLAIN. [ smtp_auth_identity: <string> ] # SMTP Auth using CRAM-MD5. [ smtp_auth_secret: <secret> ] # 默认的SMTP TLS要求 # 注意，Go不支持到远程SMTP端点的未加密连接 [ smtp_require_tls: <bool> | default = true ] # 用于Slack通知的API URL [ slack_api_url: <secret> ] [ victorops_api_key: <secret> ] [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ] [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ] [ opsgenie_api_key: <secret> ] [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ] [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ] [ wechat_api_secret: <secret> ] [ wechat_api_corp_id: <string> ] # 默认HTTP客户端配置 [ http_config: <http_config> ] # 如果告警不包括EndsAt，则ResolveTimeout是alertmanager使用的默认值，在此时间过后，如果告警没有更新，则可以声明警报已解除 # 这对Prometheus的告警没有影响，它们包括EndsAt [ resolve_timeout: <duration> | default = 5m ] 通知模板 templates：templates指定了从其中读取自定义通知模板定义的文件，最后一个文件可以使用一个通配符匹配器，如templates/*.tmpl。
templates: [ - <filepath> ... ] 路由配置 route：route定义了路由树中的节点及其子节点。如果未设置，则其可选配置参数将从其父节点继承。
每个告警都会在已配置的顶级路由处进入路由树，该路由树必须与所有告警匹配（即没有任何已配置的匹配器），然后它会遍历子节点。如果continue设置为false，它将在第一个匹配的子项之后停止；如果continue设置为true，则告警将继续与后续的同级进行匹配。如果告警与节点的任何子节点都不匹配（不匹配的子节点或不存在子节点），则根据当前节点的配置参数来处理告警。
route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: 'web.hook' 接收器配置 receivers：receivers是一个或多个通知集成的命名配置。建议通过webhook接收器实现自定义通知集成。
receivers: - name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/' 抑制规则配置 inhibit_rules：当存在与另一组匹配器匹配的告警（源）时，抑制规则会使与一组匹配器匹配的告警（目标）“静音”。目标和源告警的equal列表中的标签名称都必须具有相同的标签值。
在语义上，缺少标签和带有空值的标签是相同的。因此，如果equal源告警和目标告警都缺少列出的所有标签名称，则将应用抑制规则。
inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'dev', 'instance'] 默认配置示例： vim /usr/local/alertmanager/alertmanager.yml global: resolve_timeout: 5m route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: 'web.hook' receivers: - name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/' inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'dev', 'instance']grafana 是一款采用 go 语言编写的开源应用，主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库。
官网：https://grafana.com
安装grafana： vim /etc/yum.repos.d/grafana.repo [grafana] name=grafana baseurl=https://packages.grafana.com/oss/rpm repo_gpgcheck=1 enabled=1 gpgcheck=1 gpgkey=https://packages.grafana.com/gpg.key sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt yum makecache fast yum install -y grafana systemctl daemon-reload systemctl enable grafana-server && systemctl start grafana-server netstat -lntp | grep 3000访问ip:3000，初始账号密码为admin、admin，建议后面更改密码。
grafana部署完成。grafana配置文件：/etc/grafana/grafana.ini。
导入prometheus数据源：Configuration → Data Sources → Prometheus → Select，填入http://ip:9090，保存即可。
导入dashboard：官方dashboard模板：https://grafana.com/grafana/dashboards
选择排行第一的中文模板：1 Node Exporter for Prometheus Dashboard CN v20200628，模板ID是8919。
Manage → Import，填入模板ID，导入，
自定义dashboard名称，选择数据源Prometheus，
至此，prometheus + grafana 部署完成。接下来详细配置prometheus的监控与告警。
