2019独角兽企业重金招聘Python工程师标准>>>

Prometheus入门

本文介绍新一代的监控系统 Prometheus，并指导用户如何一步一步搭建一个 Prometheus 系统。

什么是 Prometheus ？

Prometheus是一套开源的监控与告警框架，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，继 Kubernetes 之后，Prometheus 成为 Cloud Native Computing Foundation 的第二个项目。

Prometheus 的特点

多维度的时间序列数据模型，以 metric 和键值对加以区分；
灵活的查询语言；
部署方便：不依赖分布式存储；可自治的单服务器节点；
时间序列数据通过HTTP协议以拉取（pull）的方式收集；
通过中间的网关可以实现时间序列的推送；
监控目标可以通过服务发现或静态配置；
支持多种绘图和仪表盘模式

Prometheus 的组件

Prometheus 的生态系统包括多个组件，其中大部分都是可选的：

Prometheus Server，负责抓取、存储时间序列数据；
客户端库（client library），组合进应用代码；
推送网关（push gateway），支持“短暂”的任务；
特殊用途的exporter，支持如 HAProxy，StatsD，Graphite，Redis 一类的服务；
一个告警管理器（Alertmanager）来管理告警；
各种支持工具

大部分 Prometheus 的组件都是用 Go 写的，部署很方便。

Prometheus 的架构

从架构图中可以看出其大概的工作流程：

Prometheus Server 以服务发现（如 Kubernetes 等）的方式自动发现或者静态配置添加监控目标；
Prometheus Server 定期从监控目标（Jobs/exporters）或 Pushgateway 中拉取数据（metrics），将时间序列数据保存到其自身的时间序列数据库（TSDB）中；
Prometheus Server 通过 HTTP Server 对外开放接口，可以给可视化工具（如 Prometheus web UI、Grafana 或你自己开发的工具）用 PromQL 查询/导出数据；
当有告警产生时，Prometheus Server 将告警信息推送到 Alertmanager ，由 Alertmanager 根据配置的策略发送告警信息到对应的接收方；
Pushgateway 接收 “Short-lived” 类型的 Jobs 推送过来的 metrics 并缓存，等待 Prometheus Server 抓取。

Prometheus 适合做什么？

Prometheus 非常适合记录纯数字的时间序列，既可以是以主机为中心的监控，也可以是以服务为导向的动态架构。在微服务的世界，它支持多维度的数据集合，查询功能非常强大。

Prometheus 是为可用性而设计，利用它你可以快速定位问题。每一个 Prometheus Server 都是独立的，不依赖于网络存储或其他的第三方服务。你可以在部分基础设施出现问题时仍然使用它。

Prometheus 不适合做什么？

Prometheus 用于评估可用性。如果你想要100%的精准度，比如每个请求的账单，Prometheus就不是一个好的选择，因为收集上来的数据可能没这么细致、完整。对于这样的需求，你最好用其他的大数据系统对数据做分析。

Prometheus 相关概念

为了在后面的安装和配置步骤中更好地理解，我们首先需要学习一下 Prometheus 的一些相关概念。

数据模型

Prometheus 以时间序列存储所有的数据：属于相同 metric 名称和相同标签组（键值对）的值以时间顺序形成数据流。

Metric 名称和标签

每一个时间序列都是由其 metric名称和一组标签（键值对）唯一标识。

metric名称 代表了被监控系统的一般特征（比如 http_requests_total，代表接收到的 HTTP 请求总数）。其语法要求符合正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。

需要注意的是，冒号 : 一般保留用于用户自定义的记录规则，不应该给 exporter 使用。

标签给 Prometheus 带来了多维度数据模型：对于相同metric名称，任意的标签组合标识出该 metric 在某特定维度上的实例（比如：所有使用POST方法到/api/tracks接口的HTTP请求）。查询语言可以基于这些维度过滤和聚合数据。变更任何标签值，包括增加和删除标签，都会创造新的时间序列。

标签名称可以包含 ASCII 字符、数字和下划线，其必须符合正则表达式 [a-zA-Z0-9_]*，以双下划线__开头的标签名用于内部使用。

标签的值可以包含 Unicode 字符。

表示法

给定 metric名称和一组标签，我们一般用以下的表示法来表示时间序列：

{=, ...}

举个例子：一个时间序列的 metric名称是api_http_requests_total，标签是method="POST"和handler="/messages"，那么我们可以这样写：

api_http_requests_total{method="POST", handler="/messages"}

这和 OpenTSDB 的表示法是一样的。

Metric 的类型

Prometheus 的客户端库提供四种 Metric 的类型，这些类型目前只在客户端库和传输协议上做区分。Prometheus server 暂时没有使用这些类型信息，会将数据变成无类型的时间序列。这种情况在未来可能会有所变化。

Counter

Counter 是一种累加的 metric ，代表一个单调函数，其值只能上升或在重启时重置为0。可以用 counter 代表处理的请求数、完成的任务数、出现的错误数量等。

不可以用 counter 代表一个可能会下降的值。比如，不能用 counter 表示正在运行的进程数，而应该用下面我们将提到的 gauge。

Gauge

Gauge 代表一个可以任意增加或减少的 metric 值。

Gauge 一般用来测量如温度、当前的内存使用量这样的值，也用来检测会上升或下降的值，比如 Go 的并发 goroutine 的数量。

Histogram

Histogram 取样观测的结果（一般是请求持续时间或响应大小）并在一个可配置的分布区间（bucket）内计算这些结果。其也提供所有观测结果的总和。

Histogram 有一个基本 metric名称，在一次抓取中展现多个时间序列：

累加的 counter，代表观测区间：_bucket{le=""}
所有观测值的总数：_sum
观测到的事件数量：_count

使用 histogram_quantile() 函数计算 histogram 的分位数或者聚合 histogram。Histogram 也适用于计算 Apdex指数。当配置分布区间（bucket）的时候请牢记 histogram 是累加的。

Summary

和 histogram 相似，summary 取样观测的结果（一般是请求持续时间或响应大小）。但是它还提供观测的次数和所有值的总和，它通过一个滑动的时间窗口计算可配置的分位数。

Summary 有一个基本的 metric名称，在一次抓取中展现多个时间序列：

观测事件的流式φ-分位数（0 ≤ φ ≤ 1）：{quantile="φ"}
所有观测值的总和：_sum
观测的事件数量：_count

任务（Job）与实例（Instance）

在 Prometheus 中，一个你可以抓取数据的端点叫做实例（instance），一般等价于一个进程。一组有着同样目标的实例（例如为弹性或可用性而复制的进程副本）叫做任务（job）。

自动生成的标签和时间序列

当 Prometheus 抓取目标时，它会自动添加一些标签到时间序列中，用于标识被抓取的目标：

job：目标所属的任务名称；
instance：目标URL中的:部分；

如果两个标签在被抓取的数据中已经存在，那么就要看配置选项 honor_labels 的值来决定行为了。

每次对实例的抓取， Prometheus 会在以下的时间序列中保存一个样本（样本指的是在一个时间序列中特定时间点的一个值）：

up{job="", instance=""}：如果实例健康（可达），则为 1 ，否则为 0
scrape_duration_seconds{job="", instance=""}：抓取的时长
scrape_samples_post_metric_relabeling{job="", instance=""}：在 metric relabeling 之后，留存的样本数量
scrape_samples_scraped{job="", instance=""}：目标暴露出的样本数量

up 这个时间序列对于实例的可用性监控来说非常有用。

安装与配置 Prometheus

Prometheus 大部分组件都是用 Go 编写，因此安装非常方便。

在组件的选择上，一般包括必选的 Prometheus server 和各种可选组件如：Alertmanager、各种 exporter、Grafana 等。

安装方式可以是二进制安装或通过 Docker 安装。

下面我们将通过二进制的方式安装 Prometheus server + Alertmanager + Grafana + node_exporter，另外我们还需要安装一个钉钉告警组件 prometheus-webhook-dingtalk，用于将告警发送到钉钉群组。

其他的组件读者可以参考官网/Github 等站点自行安装。

主机资源准备

| 编号 | 系统 | IP地址 | 安装的组件 | | -- | -- | -- | -- | | 1 | CentOS 7 | 192.168.2.10 | Prometheus server & node_exporter | | 2 | CentOS 7 | 192.168.2.11 | Grafana | | 3 | CentOS 7 | 192.168.2.12 | Alertmanager & prometheus-webhook-dingtalk |

安装 Prometheus Server

熟悉 Ansible 的同学可以从 Github 上下载 Playbook 进行 Prometheus server 的安装，下面介绍手动安装的步骤：

在 192.168.2.10 上创建系统用户 prometheus 和组 prometheus：

$ groupadd -r prometheus
$ useradd -r -M -s /sbin/nologin -d /tmp prometheus

到官网下载已编译的二进制源码包，解压缩。

$ curl https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz | tar -zx

规定配置文件的目录为 /etc/prometheus，数据库目录为 /data/prometheus。复制配置文件 prometheus.yml 、目录 conf.d、rules、file_sd、console_libraries、consoles 到配置文件目录 /etc/prometheus，创建数据库目录。
```
$ mkdir -p /etc/prometheus /data/prometheus
$ chown root:prometheus /etc/prometheus /data/prometheus
$ cp -rf prometheus.yml conf.d rules file_sd console_libraries consoles /etc/prometheus
```
复制二进制文件 prometheus 和 promtool 到 /usr/local/bin。

创建 systemd service unit 文件 /etc/systemd/system/prometheus.service：

[Unit]
Description=Prometheus
After=network.target

[Service]
Type=simple
Environment="GOMAXPROCS=4"
User=prometheus
Group=prometheus
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/data/prometheus \
  --storage.tsdb.retention=30d \
  --web.console.    libraries=/etc/prometheus/console_libraries \
  --web.console.templates=/etc/prometheus/consoles \
  --web.listen-address=0.0.0.0:9090 \
  --web.external-url=/prometheus
PrivateTmp=true
PrivateDevices=true
ProtectHome=true
NoNewPrivileges=true
LimitNOFILE=infinity
ReadWriteDirectories=/data/prometheus
ProtectSystem=full


SyslogIdentifier=prometheus
Restart=always

[Install]
WantedBy=multi-user.target

通过以上几步我们就完成了 Prometheus server 的安装。

配置 Prometheus Server

Prometheus server 的配置分两部分，一部分属于固定配置，需要通过命令行参数传递，在上面安装的时候我们已经写在 unit 文件中。另一部分就需要配置文件了。配置文件 prometheus.yml 的格式是 yaml ，主要分以下几个配置块：

全局配置 global
规则文件配置 rule_files
抓取配置 scrape_configs
告警配置 alerting
远程读/写功能 remote_read 和 remote_write

我们来逐个进行配置。

全局配置 `global`

全局配置中的参数在其他的所有配置块中都可以使用，将作为其他配置块的默认值。以下是一个例子：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s #需注意该值应小于 scrape_internal
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn

规则文件配置 `rule_files`

规则文件配置指定规则和告警的配置文件的路径，可以是 glob 模式：

rule_files:
  - /etc/prometheus/rules/*.rules

Prometheus 中的规则文件分两种类型：记录规则和告警规则。

记录规则可以让你提前计算高频需求或对计算性能要求很高的表达式，将结果保存为一组新的时间序列。查询这些提前计算好的结果一般都会比每次到用时才计算要快得多。对于 Dashboard 来说这很重要，因为 Dashboard 每次刷新的时候都会重复查询同样的表达式。

告警规则可以让你基于 PromQL 表达式定义告警条件，并将触发的告警提醒发送给外部的服务。每当告警表达式在一个时间点产生一个或多个矢量元素时，告警会将这些元素的标签设为激活状态。

记录和告警规则放在一个规则组（group）中。同一个组中的规则会以一个特定的频率不断地执行。

规则文件的语法

groups:
  [ -  ]

举个例子：

groups:
  - name: example
    rules:
    - record: job:http_inprogress_requests:sum
      expr: sum(http_inprogress_requests) by (job)

# 组的名称，在一个文件中需唯一
name: 

# 组中规则执行的频率
[ interval:  | default = global.evaluation_interval ]

rules:
  [ -  ... ]

记录规则的语法：

# 时间序列的名称，必须是一个合法的 metric 名称
record: 

# PromQL 表达式。每一个计算周期内都会计算一次，结果记录为一组以上面 'record' 给定的名称命名的时间序列
expr: 

# 保存结果前需要添加或覆盖的标签
labels:
  [ :  ]

告警规则的语法：

# 告警的名称，必须是一个合法的 metric 名称。
alert: 

# PromQL 表达式。每一个计算周期内都会计算一次，所有的结果组成时间序列，会成为待定/触发的告警。
expr: 

# 告警如果持续了这么长时间，就会触发一次；如果还没持续这么长时间，就认为是待定的告警
[ for:  | default = 0s ]

# 对于每一个告警需要添加/覆盖的标签
labels:
  [ :  ]

# 对于每一个告警需要添加的注释
annotations:
  [ :  ]

一个告警规则的例子如下：

groups:
- name: example
  rules:
  - alert: HighErrorRate
    expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
    for: 10m
    labels:
      severity: page
    annotations:
      summary: High request latency

for 子句使 Prometheus 在第一次发现一个表达式输出的矢量元素后、到触发该元素对应的告警之前需要等待特定的时长。在这种情况下， Prometheus 会检查告警是否在10分钟的等待期内持续被激活，当等待期满了以后就会触发告警。被激活而未触发的告警，就处于等待状态（Pending）。

label 子句用于给告警提供一组额外的标签。已经存在的标签会被覆盖。标签的值可以用模板做替换。

annotations 子句用于给告警提供一组信息标签，这组标签可以保存更长的信息，比如告警描述、运行记录链接等。注释的值也可以用模板做替换。

模板

标签和注释的值都可以用 console templating 格式做模板转换。$labels 变量代表一个告警实例的所有标签键/值对，$value 变量代表告警实例计算的值。

# 插入一个触发元素的标签值：
{{ $labels. }}
# 插入触发元素的数字表达式值：
{{ $value }}

例：

groups:
- name: example
  rules:

  # 对于任何超过5分钟还不可达的实例进行告警：
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

  # 对于平均请求延迟超过1秒的实例进行告警：
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

更多模板的例子可以访问官方文档查看。

抓取配置 `scrape_configs`

抓取配置设置抓取配置的列表。

每一个抓取配置指定了一组抓取的目标和描述抓取方式的一些参数。一般来说，一个抓取配置对应一个任务（job）。

目标可以用 static_configs 静态配置，也可以用支持的某种服务发现机制动态发现。

另外 relabel_configs 允许在抓取前对目标及其标签进行修改。

下面展示了四个抓取配置，其中 prometheus 和 redis 通过 static_configs 静态配置，node 和 dms 则通过 file_sd 的方式自动发现目标。如果你是在 Kubernetes 中运行，或环境中有 Consul 一类服务发现工具，你也可以配置 kubernetes_sd_configs 或 consul_sd_configs 等实现动态发现。

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml

告警配置 `alerting`

alerting 的配置与 Alertmanager 有关，目前我们还没安装 Alertmanager，但可以先把配置配上，这里我们用静态配置指定 Alertmanager 的 HTTP 接口：

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093

远程读/写功能 `remote_read` 和 `remote_write`

这部分配置将数据源与 Prometheus 分离时使用，在我们当前的安装架构中不需要做额外配置。

下面是完整的配置文件：

global:
  evaluation_interval: 5s
  scrape_interval: 5s
  scrape_timeout: 3s
  external_labels:
    environment: vm-tel-xyz-prometheus.xyz.cn

rule_files:
  - /etc/prometheus/rules/*.rules

alerting:
  alertmanagers:
  - path_prefix: /alertmanager
    scheme: http
    static_configs:
    - targets:
      - 192.168.2.12:9093

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
    - targets:
      - vm-tel-xyz-prometheus.xyz.cn:9090
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml
  - job_name: redis
    static_configs:
    - targets:
      - localhost:9121
  - job_name: dms
    metrics_path: /actuator/prometheus
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/dms.yml

关于配置中更多的配置项和用法，请参阅官方文档。

exporter 简介

对于自己研发的应用，我们可以在应用内加入客户端库，各种语言的库使用方式请参考：https://prometheus.io/docs/instrumenting/clientlibs/

但是对于某些监控对象，比如：操作系统、Nginx、Redis、MySQL，我们不能插入库文件，怎么办呢？ Prometheus 的解决方案是引入 exporter 。通过各种 exporter 你可以方便地采集各类目标运行数据。

这里我们只介绍 node_exporter。该 exporter 适用于 *nix 操作系统，可以采集各种基础资源使用信息如 CPU、内存、磁盘、网络等。

其他的 exporeter 你可以在 https://prometheus.io/docs/instrumenting/exporters/ 查找并使用。

安装 node_exporter

同样在官方下载页面我们可以找到 node_exporter 的二进制安装包，只需下载并放到后台运行即可。

细心的同学已经发现了，我们在 Prometheus 配置 scrape_configs 时已经加入了 node_exporter 的部分配置：

scrape_configs:
...
  - job_name: node
    file_sd_configs:
    - files:
      - /etc/prometheus/file_sd/node.yml

file_sd_configs中的配置文件可以用 yaml 或 JSON 格式编写，这里还是用我们熟悉的 yaml ：

- targets:
  - 192.168.2.10:9100
  labels:
  - server_name: prometheus_server

安装 Alertmanager 和 prometheus-webhook-dingtalk

让我们来到告警服务器（192.168.2.12），下载两个软件的二进制包：

$ curl https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz | tar zx

$ git clone https://github.com/timonwong/prometheus-webhook-dingtalk.git

只需要将两个二进制包 alertmanager 和 prometheus-webhook-dingding 放进 /usr/local/bin 就能运行了。

配置 Alertmanager 和 prometheus-webhook-dingtalk

创建配置文件目录 /etc/alertmanager 并复制配置文件 alertmanager.yml 到这里；创建存储目录：
```
$ mkdir -p /etc/alertmanager
$ cp alertmanager.yml /etc/alertmanager.yml
$ mkdir -p /data/alertmanager
```

修改配置文件，使其在告警时发送给钉钉的 webhook：

global:
  resolve_timeout: 5m

route:
  receiver: 'focusops'
  group_wait: 10s
  group_interval: 1m
  repeat_interval: 1h
  group_by: ['alertname']
  routes:
    - receiver: 'focusops'
      continue: true
    - receiver: 'xyz'

receivers:
# 我们指定了两个receiver，分别到 dingtalk 的 webhook1 和 webhook2 ，这和我们后面启动 prometheus-webhook-dingtalk 时的参数保持一致，    需要注意。
- name: 'focusops'
  webhook_configs:
  - send_resolved: true
    url: 'http://localhost:8060/dingtalk/webhook1/send'
- name: 'xyz'
  webhook_configs:
  - send_resolved: true
    url: 'http://localhost:8060/dingtalk/webhook2/send'

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

编写 Alertmanager 和 prometheus-webhook-dingtalk 的启动脚本，并启动：

alertmanager.sh：

alertmanager \ --config.file=/etc/alertmanager/alertmanager.yml \
--web.external-url=/alertmanager \
--storage.path=/data/alertmanager/ \
&> alertmanager.log &

dingtalk.sh（注意替换token1和token2）：

prometheus-webhook-dingtalk \
--ding.profile=webhook1=https://oapi.dingtalk.com/robot/send?access_token= \
--ding.profile=webhook2=https://oapi.dingtalk.com/robot/send?access_token= \
&>dingtalk.log &

安装与配置 Grafana

尽管 Prometheus 自身提供一个 web UI，但是这个 UI 还是太简陋了， Grafana 几乎是标配的展示工具。

对于我们的 CentOS 7 系统，我们可以通过 YUM 快速安装：

添加 yum 源文件 /etc/yum.repos.d/grafana.repo：

[grafana]
name=grafana
baseurl=https://packagecloud.    io/grafana/stable/el/7/$basearch
#repo_gpgcheck=1
enabled=1
gpgcheck=0
#gpgkey=https://packagecloud.io/gpg.key     https://grafanarel.s3.amazonaws.    com/RPM-GPG-KEY-grafana
#sslverify=1
#sslcacert=/etc/pki/tls/certs/ca-bundle.crt

因为国内网络的关系我把 gpgcheck 相关的验证都去掉了，不放心的可以把删除注释，但是需要保证可以网络连通哦！

YUM 安装：
```
$ yum install grafana
```
配置 Grafana

配置文件 /etc/grafana/grafana.ini 只需要注意登录方面的配置，如 admin_user 和 admin_password，你还可以启用 LDAP 验证模块：
```
[auth.ldap]
enabled = true
config_file = /etc/grafana/ldap.toml
```
然后配置 /etc/grafana/ldap.toml ，这里不再赘述。
启动 Grafana
```
$ systemctl start grafana-server
```
关联 Grafana 与 Prometheus 数据源

访问 http://192.168.2.11:3000 打开 Grafana，登录后选择添加数据源，在 Settings 中选择 Type 为 Prometheus ，在 HTTP 的 URL 中填入 Prometheus server 的 HTTP 接口地址，点击 Save & Test，看到绿色的 Data source is working 就说明已经关联成功了。
添加 Dashboard

虽然你可以自定义 Dashboard，但是如果我告诉你已经有很多人做好了现成的 Dashboard 并且你可以直接拿来用呢？

是的，除非我们有特定要求，不然我们何必自己造轮子。

打开 http://192.168.2.11:3000/dashboard/import ，填入 grafana 官网的 Dashboard ID，即可以导入其他人做好的 Dashboard 作品。

各种 Dashboard 我们可以在 https://grafana.com/dashboards 查看、检索。

在 Grafana 中查看数据和图表

对于不同的时间序列我们可以使用不同的 Dashboard 进行查看。比如对于 node_exporter 采集到的时间序列，我们只需导入 node_exporter 适配的 Dashboard （ID：1860），就可以看到图表了：

最后

上面介绍了这么多，但是如何自定义图表和告警规则？在下一篇文章中我将给大家介绍 Prometheus 的查询语言 PromQL。

Prometheus入门

Prometheus入门

什么是 Prometheus ？

Prometheus 的特点

Prometheus 的组件

Prometheus 的架构

Prometheus 适合做什么？

Prometheus 不适合做什么？

Prometheus 相关概念

数据模型

Metric 名称和标签

表示法

Metric 的类型

Counter

Gauge

Histogram

Summary

任务（Job）与实例（Instance）

自动生成的标签和时间序列

安装与配置 Prometheus

主机资源准备

安装 Prometheus Server

配置 Prometheus Server

全局配置 global

规则文件配置 rule_files

规则文件的语法

模板

抓取配置 scrape_configs

告警配置 alerting

远程读/写功能 remote_read 和 remote_write

exporter 简介

安装 node_exporter

安装 Alertmanager 和 prometheus-webhook-dingtalk

配置 Alertmanager 和 prometheus-webhook-dingtalk

安装与配置 Grafana

在 Grafana 中查看数据和图表

最后

你可能感兴趣的:(Prometheus入门)

全局配置 `global`

规则文件配置 `rule_files`

抓取配置 `scrape_configs`

告警配置 `alerting`

远程读/写功能 `remote_read` 和 `remote_write`