本文参考：
《Prometheus官方文档》，或网盘下载《Prometheus操作指南.pdf》(提取码：1l8m)

Prometheus基础知识

1. 简介

Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从 2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。 2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布 了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。 Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且 超过120+项的第三方集成。

监控的目的

• 长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间
• 增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。
• 对照分析：两个版本的系统运行资源使用情况的差异如何？在不同容量情况下系统的并发和负载变化如何？通过 监控能够方便的对系统进行跟踪和比较。
• 告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理 或者提前预防问题的发生，避免出现对业务的影响。
• 故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够 找到并解决根源问题。
• 数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信 息。

与常见监控系统比较
对于常用的监控系统，如Nagios、Zabbix的用户而言，往往并不能很好的解决上述问题。

Prometheus的优势
Prometheus是一个开源的完整监控解决方案，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于 中央化的规则计算、统一分析和告警的新模型。 相比于传统监控系统Prometheus具有以下优点：

• 易于管理

Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是 本地磁盘，因此不会有潜在级联故障的风险。

Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。 对于一些复杂的情况，还可以使用Prometheus服务发现(Service Discovery)的能力动态管理监控目标。

• 监控服务的内部运行状态

Pometheus鼓励用户监控服务的内部状态，基于Prometheus丰富的Client库，用户可以轻松的在应用程序中添加 对Prometheus的支持，从而让用户可以获取服务和应用内部真正的运行状态。

• 强大的数据模型

所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。所有的样本除了基本的指 标名称以外，还包含一组用于描述该样本特征的标签。

如下所示：

http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

每一条时间序列由指标名称(Metrics Name)以及一组标签(Labels)唯一标识。每条时间序列按照时间的先后顺序 存储一系列的样本值。

表示维度的标签可能来源于你的监控对象的状态，比如code=404或者content_path=/api/path。也可能来源于 的你的环境定义，比如environment=produment。基于这些Labels我们可以方便地对监控数据进行聚合，过滤， 裁剪。

强大的查询语言PromQL
Prometheus内置了一个强大的数据查询语言PromQL。 通过PromQL可以实现对监控数据的查询、聚合。同时 PromQL也被应用于数据可视化(如Grafana)以及告警当中。

通过PromQL可以轻松回答类似于以下问题：

• 在过去一段时间中95%应用延迟时间的分布范围？
• 预测在4小时后，磁盘空间占用大致会是什么情况？
• CPU占用率前5位的服务有哪些？(过滤)

高效
对于监控系统而言，大量的监控任务必然导致有大量的数据产生。而Prometheus可以高效地处理这些数据，对于单 一Prometheus Server实例而言它可以处理：

• 数以百万的监控指标
• 每秒处理数十万的数据点。

可扩展
Prometheus是如此简单，因此你可以在每个数据中心、每个团队运行独立的Prometheus Sevrer。Prometheus 对于联邦集群的支持，可以让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务 量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。

易于集成
使用Prometheus可以快速搭建监控服务，并且可以非常方便地在应用程序中进行集成。目前支持： Java， JMX， Python， Go，Ruby， .Net， Node.js等等语言的客户端SDK，基于这些SDK可以快速让应用程序纳入到 Prometheus的监控当中，或者开发自己的监控数据收集程序。同时这些客户端收集的监控数据，不仅仅支持 Prometheus，还能支持Graphite这些其他的监控工具。

同时Prometheus还支持与其他的监控系统进行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。

Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。

可视化
Prometheus Server中自带了一个Prometheus UI，通过这个UI可以方便地直接对数据进行查询，并且支持直接 以图形化的形式展示数据。同时Prometheus还提供了一个独立的基于Ruby On Rails的Dashboard解决方案 Promdash。最新的Grafana可视化工具也已经提供了完整的Prometheus支持，基于Grafana可以创建更加精美的 监控图标。基于Prometheus提供的API还可以实现自己的监控可视化UI。

开放性
通常来说当我们需要监控一个应用程序时，一般需要该应用程序提供对相应监控系统协议的支持。因此应用程序会与 所选择的监控系统进行绑定。为了减少这种绑定所带来的限制。对于决策者而言要么你就直接在应用中集成该监控系 统的支持，要么就在外部创建单独的服务来适配不同的监控系统。

而对于Prometheus来说，使用Prometheus的client library的输出格式不止支持Prometheus的格式化数据， 也可以输出支持其它监控系统的格式化数据，比如Graphite。

因此你甚至可以在不使用Prometheus的情况下，采用Prometheus的client library来让你的应用程序支持监控 数据采集。

Architecture
This diagram illustrates the architecture of Prometheus and some of its ecosystem components:

Prometheus是一个开放性的监控解决方案，用户可以非常方便的安装和使用Prometheus并且能够非常方便的对其 进行扩展。为了能够更加直观的了解Prometheus Server，接下来我们将在本地部署并运行一个Prometheus Server实例，通过Node Exporter采集当前主机的系统资源使用情况。 并通过Grafana创建一个简单的可视化仪 表盘。

2. Prometheus工作流程：

2.1 服务端

Prometheus服务端以一个进程方式启动，如果不考虑参数和后台运行的话，只需要解压安装包之后运行./prometheus脚本即可启动，程序默认监听在9090端口。每次采集到的数据叫做metrics。这些采集到的数据会先存放在内存中，然后定期再写入硬盘，如果服务重新启动的话会将硬盘数据写回到内存中，所以对内存有一定消耗。Prometheus不需要重视历史数据，所以默认只会保留15天的数据。

2.2 客户端

Prometheus客户端分为pull和push两种方式。如果是pull形式的话则是服务端主动向客户端拉取数据，这样需要客户端上安装exporters（导出器）作为守护进程，官网上也提供了很多exporters可以下载使用，比如使用最多的node_exporters，几乎把系统自身相关数据全部采集了，非常全面，node_exporter默认监听9100端口。

如果是push形式的话客户端需要安装pushgateway插件，然后运需要运维人员用脚本把监控数据组织成键值形式提交给pushgateway，再由它提交给服务端。它适合于现有exporters无法满足需求时，自己灵活定制。

2.3metrics主要数据类型

Gauges：最简单、使用最多的指标，获取一个返回值，这个返回值没有变化规律，不能肯定它一定是增长或是减少的状态，采集回来是多少就是多少。比如硬盘容量、CPU内存使用率都适合使用Gauges数据类型。

Counters：计数器。数据从0开始累计，理想状态下应该是永远增长或者是不变。适合统计机器开机时间、HTTP访问量

Histograms：和summary一样属于高级指标，用于统计数据的分布情况。比如最小值、最大值、中间值。这个类型不太好理解，比如说统计一天的日志，大部分用户响应时间都是正常的，只有少量用户异常，如果这个时候取平均值的话，这少量用户的异常情况就会被掩盖过去，而Histograms可以分别统计出全部用户的响应时间，比如0-1秒的用户有多少、1-2秒的用户有多少（其实有点像Kibana）

3. 安装部署Prometheus Server

Prometheus基于Golang编写，编译后的软件包，不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制 包，解压并且添加基本的配置即可正常启动Prometheus Server。

环境

• 系统环境：Centos 7.2
• 软件版本：prometheus-2.13.1.linux-amd64.tar.gz
• 下载地址：https://prometheus.io/download/

安装

tar -xzvf prometheus-2.13.1.linux-amd64.tar.gz
mkdir /usr/local/prometheus
mv prometheus-2.13.1.linux-amd64 /usr/local/prometheus

创建数据目录

mkdir -p /data/prometheus/data

用户授权

useradd prometheus -s /sbin/nologin
chown -R prometheus:prometheus /usr/local/prometheus /data/prometheus

添加启动服务
$vim /usr/lib/systemd/system/prometheus.service，配置如下：

[Unit]
Description=prometheus
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml --storage.tsdb.path=/data/prometheus/data
Restart=on-failure
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target

启动

systemctl daemon-reload
systemctl enable prometheus.service
systemctl start prometheus.service

验证
WEB地址：http://ip:9090

4. 配置(more)

Prometheus可以在运行时重新加载其配置。如果新配置格式不正确，则更改将不会应用。通过向Prometheus进程发送SIGHUP或向/-/reload端点发送HTTP POST请求来触发配置重新加载（--web.enable-lifecycle启用该标志时）。这还将重新加载所有已配置的规则文件。

yaml文件书写的要求如下：

• 大小写敏感
• 使用缩进表示层级关系
• 缩进时不允许使用Tab键，只允许使用空格。
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可

4.1 配置文件(mroe)

要指定要加载的配置文件，请使用该--config.file标志。
该文件以YAML格式写入，由以下所述的方案定义。方括号表示参数是可选的。对于非列表参数，该值设置为指定的默认值。

通用占位符定义如下：

• <boolean>：可以接受值的布尔值true或false
• <duration>：与正则表达式匹配的持续时间 [0-9]+(ms|[smhdwy])
• <labelname>：与正则表达式匹配的字符串 [a-zA-Z_][a-zA-Z0-9_]*
• <labelvalue>：一串unicode字符
• <filename>：当前工作目录中的有效路径
• <host>：由主机名或IP后跟可选端口号组成的有效字符串
• <path>：有效的网址路径
• <scheme>：可以采用值http或https
• <string>：常规字符串
• <secret>：是秘密的常规字符串，例如密码
• <tmpl_string>：使用前已模板扩展的字符串

其他占位符分别指定。
在这里可以找到有效的示例文件。
全局配置指定在所有其他配置上下文中有效的参数。它们还用作其他配置部分的默认设置。

global:
  # 默认情况下抓取目标的频率.
  [ scrape_interval: <duration> | default = 1m ]

  # 抓取超时时间.
  [ scrape_timeout: <duration> | default = 10s ]

  # 评估规则的频率.
  [ evaluation_interval: <duration> | default = 1m ]

  # 与外部系统通信时添加到任何时间序列或警报的标签
  #（联合，远程存储，Alertma# nager）.
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# 规则文件指定了一个globs列表. 
# 从所有匹配的文件中读取规则和警报.
rule_files:
  [ - <filepath_glob> ... ]

# 抓取配置列表.
scrape_configs:
  [ - <scrape_config> ... ]

# 警报指定与Alertmanager相关的设置.
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 与远程写入功能相关的设置.
remote_write:
  [ - <remote_write> ... ]

# 与远程读取功能相关的设置.
remote_read:
  [ - <remote_read> ... ]

4.2 prometheus.yml的样例

(标签部分内容不是必须的，可以了解)

global:
  scrape_interval: 15s #抓取数据的频率，默认15秒。该配置也可配置在每个job_name中
  evaluation_interval: 15s #监控规则评估频率，比如设置了当内存使用大于70%发出报警的规则，然后每15秒来执行一次这个规则

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

scrape_configs:
  - job_name: 'prometheus-server' #作业名，可以理解为组名，其下可以有多个实例配置
    static_configs:
    - targets: ['localhost:9090'] #节点的地址，可以写多个地址
# params: #过滤器
# collect[]:
# - cpu #只采集CPU数据
  - job_name: 'www'
    static_configs:
    - targets: ['ip:9100','ip:9100']
      labels: #自定义标签，可以通过标签进行统一管理
        idc:beijing #增加一个idc标签，内容为beijing
#使用正则替换标签
  - job_name: 'node'
    static_configs:
    - targets: ['ip:9100','ip:9100']
    metric_relable_configs: #通过正则重命名标签
    - action: replace #replace替换是默认动作。此外还有keep（只参加匹配标签的实例）、drop（不采集匹配正则的实例）、labelkeep\labeldrop(对标签进行过滤处理而非实例)等动作
      source_labels: ['job'] #原标签，job是默认就会产生的标签，这里job标签的值是node
      regex: (.*) #正则匹配，这里匹配job标签内的内容，也就是node
      replacement: beijing #替换成什么内容，如果写$1就是将正则里的内容拿过来
      target_label: idc #把替换到的内容赋值给idc标签
    - action: labeldrop #删除标签
      regex: job #把原有的job标签删除不显示

?
[sleepy↓]

?

Prometheus基础(1)

原文：https://www.cnblogs.com/sunhongleibibi/p/11739377.html