2021 年 4 月 5 日

一个开源系统监控和警报工具包。现在是一个独立的开源项目，独立于任何公司进行维护。根据它们发布的指标分析您的应用程序和基础架构的执行情况。特别适用于具有临时实例的大型分布式系统。

• 指标存储在multi-dimensional数据模型中，而不是hierarchical，其中每个度量由名称和许多键/值对组成http.server.requests.count(uri="/endpoint", method="GET") 12 代替 http.server.requests.GET.endpoint=12由专门为指标构建的自己的自定义时间序列数据库提供支持提供自己的查询语言PromQL作为只读且灵活的查询语言，用于聚合时间序列数据
• 不依赖分布式存储；单个服务器节点是自治的
• 时间序列收集通过 HTTP 上的拉模型发生
• 通过服务发现或静态配置发现目标
• 多种图形和仪表板支持模式
• 替代Graphite，InfluxDB
• 生态系统提供了许多预先构建的exporters公开指标，供 Prometheus 抓取

架构

• Prometheus 主服务器由一个时间序列数据库组成，用于存储每个捕获的测量值旁边还有一个从外部应用程序、主机、平台中提取样本的Scraper以及允许在 tsdb 上执行操作的 HTTP 服务器（例如通过 PromQL 查询）
• Prometheus 是单实例组件；所有数据都存储在本地节点存储上如果您需要扩展，建议使用不同/复制目标启动多个单独的 Prometheus 实例
• 在一个pull模型中运行，Prometheus 被设置为定期从所有目标应用程序实例中抓取指标因此必须通过以下方式了解所有活动实例的位置 service discovery更容易判断目标是否已关闭，可以手动转到目标并使用网络浏览器检查其健康状况除了暴露最新指标快照的端点外，应用程序本身并不了解 Prometheus ( /metrics)
• 该pull模型对于短期/批量操作可能存在问题，这些操作可能没有足够长的时间被抓取，Pushgateway 组件可以用作中间人 - 从作业中获取推送的指标并将它们转发到 Prometheus
• 服务发现集成到Kubernetes, AWS, Azure以了解所有目标节点的当前情况
• 指标被抓取并存储在 tsdb 中后，可以通过 Web UI/Grafana/API 提供给用户
• AlertManager 组件可以与一组查询指标的规则一起使用以生成系统警报对警报、节流、静音等执行重复数据删除转发到电子邮件，PagerDuty，Slack等

安装

• 从https://prometheus.io/download/作为单个 Go 二进制文件提供，因此可以直接执行./prometheus默认情况下prometheus.yml在同一目录中查找配置文件（默认情况下只会抓取 Prometheus 本身）
• Prometheus Web UI 可在 http://localhost:9090允许您查看当前目标、配置和运行查询。对于更复杂的可视化使用Grafana
• 或者可以通过容器运行 docker run -p 9090:9090 -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

配置

• prometheus.yml 文件中 提供的所有 Prometheus 配置文档位于https://prometheus.io/docs/prometheus/latest/configuration/configuration/
• Prometheus 可以在运行时重新加载其配置。如果新配置的格式不正确，则不会应用更改通过向SIGHUP Prometheus 进程发送 a 触发重新加载( kill -HUP <pid>)或在启用标志时HTTP POST向/-/reload 端点发送请求--web.enable-lifecycle

global: # applied to all targets unless overridden
  scrape_interval: 15s # how often to scrape each target
  evaluation_interval: 15s # how often to evaluate predefined rules

scrape_configs: # a set of jobs denoting where to scrape metrics from
  - job_name: "prometheus" # a group of targets, also added as a label to each measurement
    metrics_path: '/metrics' # default
    static_configs: # a hardcoded host/port or could be service discovery
      - targets: ["localhost:9090"] # uses metrics path to pull metrics, by default http

服务发现

• static_configs 无法扩展到频繁添加/删除实例的动态环境
• Prometheus 可以与服务发现机制集成以自动更新其运行实例的视图当添加新实例时，Prometheus 将开始抓取，当从发现中丢失时，时间序列也将被删除如果需要自定义机制，则与Consul、或基于文件的内置集成AzureAWS
• JSON/YAML文件可以由平台发布，指定要从中抓取的所有目标。Prometheus 使用它来自动更新目标

- job_name: 'myapp'
  file_sd_configs:
    refresh_interval: 5m # default
    - files:
      - file_sd.yml

已发布文件file_sd.json包含所有当前活动目标和任何附加标签的位置：

[ { "targets": [ "<host>" ], "labels": { "<labelname>": "<labelvalue>" } } ] 

重新打标签

Prometheus 需要知道要抓取什么，这就是服务发现的relabel_configs用武之地。重新标记配置允许您选择要抓取的目标以及目标标签。因此，如果您想说抓取这种类型的机器而不是那种机器，请使用relabel_configs.

metric_relabel_configs相比之下，在抓取发生之后，但在数据被存储系统摄取之前应用。因此，如果您想要删除一些昂贵的指标，或者来自/metrics您想要操作的抓取本身（例如来自页面）的标签，那么这就是metric_relabel_configs适用的地方。

所以作为一个简单的经验法则：relabel_config在抓取之前发生，metric_relabel_configs在抓取之后发生

  relabel_configs:
  - source_labels: [__meta_kubernetes_service_label_app]
    regex: nginx
    action: keep
  - source_labels: [__meta_kubernetes_endpoint_port_name]
    regex: web
    action: keep
  - source_labels: [__meta_ec2_public_ip] # rewrite private ip to public from service discovery
    regex: '(.*)'
    replacement: '${1}:9100'
    target_label: __address__    

您可以执行以下action操作：

• keep：保留一个匹配的目标或系列，放弃所有其他目标
• drop：删除匹配的目标或系列，保留所有其他目标
• replace: 用target_label和replacement参数定义的新标签替换或重命名匹配的标签
• labelkeep: 匹配regex所有标签名称，删除所有不匹配的标签（忽略source_labels并应用于所有标签名称）
• labeldrop: 匹配regex所有标签名称，删除所有匹配的标签（忽略source_labels并应用于所有标签名称）

metric_relabel_configs 可用于在摄取前删除不必要的时间序列：

- job_name: cadvisor
  metric_relabel_configs:
  - source_labels: [container_label_JenkinsId]
    regex: '.+'
    action: drop
  - source_labels: [__name__]
    regex: '(container_tasks_state|container_memory_failures_total)'
    action: drop

https://grafana.com/docs/grafana-cloud/billing-and-usage/prometheus/usage-reduction/

仪表盘

• 有两种方式可以为 Prometheus 公开应用程序指标直接在应用程序中使用客户端库来创建和公开 Prometheus 端点（通常/metrics）使用中间代理exporter实例检测目标应用程序并转换为 Prometheus 指标格式

# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027 1395066363000
http_requests_total{method="post",code="400"}    3 1395066363000

# Minimalistic line:
metric_without_timestamp_and_labels 12.47

# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="0.5"} 129389
http_request_duration_seconds_bucket{le="1"} 133988
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320

# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds{quantile="0.9"} 9001
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693

惯例和命名规则

• 指标名称应以字母开头，后面可以跟任意数量的字母、数字和下划线
• 指标必须有唯一的名称，如果您尝试注册相同的两次，客户端库应该报告错误
• 应该有一个后缀描述单位，复数形式（例如_bytes或_total）
• 应该代表在所有标签维度上测量的相同逻辑事物
• 键值标签对的每个独特组合都代表一个新的时间序列，这可以显着增加存储的数据量。不要使用标签来存储具有高基数（许多不同的标签值）的维度，例如用户 ID、电子邮件地址或其他无限制的值集

Exporter 导出器

有许多库和服务器有助于从第三方系统导出现有指标作为 Prometheus 指标。这对于直接使用 Prometheus 指标（Linux 内核）检测给定系统不可行的情况很有用，因为无法修改源等

• https://prometheus.io/docs/instrumenting/exporters/
• anexporter是一个单独的过程，完全致力于从目标系统中提取指标并将它们作为 Prometheus 指标公开“代理服务”将目标接口转换为 Prometheus 可以抓取的接口
• 常见出口商（一些官方）：节点导出器- Unix 内核、CPU 负载、内存、I/O、网络公开的硬件和操作系统指标MySQL Expoter - 数据库指标、运行的查询、计时、池大小Blackbox Exporter - 通过 HTTP、DNS、TCP、ICMP 探测端点Kafka、Nginx、Postgres、Jenkis、AWS、Graphnite、JMX
• 对于您有权修改应用程序代码的情况，必须添加检测以添加 Prometheus 指标可以使用现有的应用程序框架来公开默认的通用指标 ( Spring Actuator)使用客户端库添加要公开的自定义指标（Go、Java、Python、Ruby）
• 其他指标库提供了指标定义的外观，并允许添加可插入的 Prometheus 导出器 ( Micrometer) 不必直接使用 Prometheus 客户端库来提高整体监控解决方案的灵活性

Blackbox 导出器

一个探测导出器，允许您监控网络端点 - 在探测时它会返回有关底层请求的详细指标。

• 用于在您不了解系统内部的情况下，用于测量响应时间、DNS 解析时间、检查端点的可用性等

• 从https://github.com/prometheus/blackbox_exporter 作为单个 Go 二进制文件提供，因此可以直接执行./blackbox_exporter - 默认在端口上运行 9115或使用 Docker docker run --rm -d -p 9115:9115 -v pwd:/config prom/blackbox-exporter:master --config.file=/config/blackbox.yml
• 在 Prometheus 中检索指标，probe直接定位端点（执行和测量请求）
• 用于执行网络请求的模块（如探针 URL 中所定义）在blackbox.yml配置文件（HTTP、DNS、SSH）中定义https://github.com/prometheus/blackbox_exporter/blob/master/example.yml

执行 HTTP 请求并在响应正文中查找内容

# blackbox.yml
http_find_prom:
  prober: http
  http:
    preferred_ip_protocol: ip4 # by default ipv6
    fail_if_body_not_matches_regexp:
    - "monitoring"

http://localhost:9115/probe?target=prometheus.io&module=http_find_prom —— probe_success = 1

执行 TCP 探测

http://localhost:9115/probe?target=localhost:8000&module=tcp_connect

执行 DNS 探测

dns_google:
  prober: dns
  dns:
    transport_protocol: "tcp"
    preferred_ip_protocol: ip4
    query_name: "www.google.com"

http://localhost:9115/probe?target=8.8.8.8&module=dns_google

爬取数据到Prometheus

# prometheus.yml
scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]  # Look for a HTTP 200 response.
    static_configs:
      - targets:
        - http://prometheus.io    # Target to probe with http
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target # save current target address into temp param
      - source_labels: [__param_target]
        target_label: instance # move current address to instance label
      - target_label: __address__
        replacement: 127.0.0.1:9115 # redirect address

指标类型

客户端库提供四种核心指标类型。这些目前仅在客户端库（以启用针对特定类型的使用而定制的 API）和有线协议中有所不同。Prometheus 服务器尚未使用类型信息并将所有数据扁平化为无类型时间序列。

指标

• 表示单个单调递增计数器的累积度量，其值只能在重新启动时增加或重置为零
• 例如，您可以使用计数器来表示服务的请求数、完成的任务数或错误数
• 不要使用计数器来公开可以减少的值。例如，不要对当前运行的进程数使用计数器；而是使用仪表

测量

• 表示可以任意上下的单个数值的度量
• 仪表通常用于测量值，如温度或当前内存使用情况，但也用于可以上下浮动的“计数”，如并发请求的数量

直方图

• 采样观察（通常是请求持续时间或响应大小之类的东西）并将它们计算在可配置的桶中。它还提供所有观察值的总和
• 具有基本指标名称的直方图<basename>在抓取期间公开多个时间序列：观察桶的累积计数器，公开为 <basename>_bucket{le="<upper inclusive bound>"}的总和的所有观察值的，公开为<basename>_sum该计数已观察到的事件的，公开为<basename>_count（等同于<basename>_bucket{le="+Inf"}上文）
• 使用该histogram_quantile()函数从直方图或甚至跨实例的直方图聚合计算分位数
• 在桶上操作时，请记住直方图是累积的

概括

• 类似于直方图，摘要样本观察（通常是请求持续时间和响应大小之类的东西）。虽然它还提供观察的总数和所有观察值的总和，但它计算滑动时间窗口内的可配置分位数
• 具有基本指标名称的摘要<basename>在抓取期间公开多个时间序列：观察事件的流式φ-分位数(0 ≤ φ ≤ 1)，暴露为<basename>{quantile="<φ>"}的总和的所有观察值的，公开为<basename>_sum该计数的事件已经被观察到，暴露<basename>_count
• https://prometheus.io/docs/practices/histograms/如果需要聚合，请选择直方图。否则，如果您了解将观察到的值的范围和分布，请选择直方图。如果您需要准确的分位数，请选择摘要，无论值的范围和分布如何。

PromQL

Prometheus 提供了一种称为 PromQL（Prometheus Query Language）的函数式查询语言，可以让用户实时选择和聚合时间序列数据。表达式的结果既可以显示为图形，也可以在 Prometheus 的表达式浏览器中查看为表格数据，也可以通过 HTTP API 由外部系统使用。

数据类型

表达式或子表达式可以计算为以下四种类型之一：

• 即时向量- 一组时间序列，包含每个时间序列的单个样本，所有时间序列都共享相同的时间戳 ( prometheus_http_requests_total)
• 范围向量- 一组时间序列，包含每个时间序列随时间变化的数据点范围 ( prometheus_http_requests_total[5m])
• 标量- 一个简单的数字浮点值

根据用例（例如，当绘制与显示表达式的输出时），作为用户指定表达式的结果，这些类型中只有一些是合法的。例如，返回即时向量的表达式是唯一可以直接绘制的类型。

选择器和匹配器

在最简单的形式中，只指定了一个度量名称。这会产生一个包含所有具有此度量名称的时间序列元素的即时向量：

http_requests_total

可以通过在花括号 ( {}) 中附加逗号分隔的标签匹配器列表来进一步过滤这些时间序列。

此示例仅选择具有http_requests_total度量名称且job标签设置为prometheus且group标签设置为 的时间序列canary：

http_requests_total{job="prometheus",group="canary"}

• = - 选择与提供的字符串完全相同的标签
• != - 选择不等于提供的字符串的标签
• =~ - 选择正则表达式匹配提供的字符串的标签
• !~ - 选择与提供的字符串不匹配的标签

范围向量字面量的工作方式与即时向量字面量类似，不同之处在于它们从当前时刻选择了一系列样本。持续时间附加在[]向量选择器末尾的方括号 ( ) 中，以指定应为每个结果范围向量元素提取多远的时间值。

在此示例中，我们选择了我们在过去 5 分钟内为指标名称http_requests_total和job标签设置为 的所有时间序列记录的所有值prometheus：

http_requests_total{job="prometheus"}[5m]

Operator

Prometheus 的查询语言支持基本的逻辑和算术运算符。对于两个瞬时向量之间的操作，可以修改匹配行为。

• 二元算术运算符定义在标量/标量、向量/标量和向量/向量值对之间。( +, -, *, /, %, ^)
• 比较运算符在标量/标量、向量/标量和向量/向量值对之间定义。默认情况下，它们会过滤。它们的行为可以通过bool在操作符之后提供来修改，该操作符将返回0或1为值而不是过滤 ( ==, !=, >, >=)
• 向量之间的操作尝试为左侧的每个条目在右侧向量中找到匹配元素。应用运算符时，Prometheus 尝试通过标签在两个向量中找到匹配元素。可以忽略标签以获取匹配项method_code:http_errors:rate5m{code="500"} / ignoring(code) method:http_requests:rate5m
• 聚合运算符可用于聚合单个即时向量的元素，从而产生具有聚合值的更少元素的新向量：( sum, min, max, avg, count, topk, quantile)如果该指标http_requests_total具有按application、instance和group标签扇出的时间序列，我们可以通过以下方式计算每个应用程序和组在所有实例上看到的 HTTP 请求总数：sum without (instance) (http_requests_total)
• rate 计算一段时间内的每秒增量（接收范围向量并输出即时向量）
• https://prometheus.io/docs/prometheus/latest/querying/functions

例子

使用度量返回所有时间序列http_requests_total：

http_requests_total

返回与所有指标的时间序列http_requests_total和给定job和handler标签：

http_requests_total{job="apiserver", handler="/api/comments"}

返回同一向量的整个时间范围（在本例中为 5 分钟），使其成为范围向量（不可图形化）：

http_requests_total{job="apiserver", handler="/api/comments"}[5m]

返回http_requests_total指标在过去 30 分钟内的 5 分钟速率，分辨率为 1 分钟：

rate(http_requests_total[5m])[30m:1m]

按作业名称返回所有实例的 5 分钟费率总和：

sum by (job) (
  rate(http_requests_total[5m])
)

为每个实例返回未使用的内存（以 MiB 为单位）：

如果我们有两个具有相同维度标签的不同度量，我们可以对它们应用二元运算符，并且两侧具有相同标签集的元素将被匹配并传播到输出：

(instance_memory_limit_bytes - instance_memory_usage_bytes) / 1024 / 1024

相同的表达式，但按应用求和，可以这样写：

sum by (app, proc) (
  instance_memory_limit_bytes - instance_memory_usage_bytes
) / 1024 / 1024

返回按应用程序 ( app) 和进程类型 ( proc)分组的前 3 个 CPU 用户：

topk(3, sum by (app, proc) (rate(instance_cpu_time_ns[5m])))

返回每个应用程序运行的实例总数：

count by (app) (instance_cpu_time_ns)

记录规则

Prometheus 支持两种类型的规则，这些规则可以配置并定期评估：记录规则和警报规则。要在 Prometheus 中包含规则，请创建一个包含必要规则语句的文件，并让 Prometheus 通过rule_files配置中的字段加载该文件。

• 记录规则允许您预先计算经常需要或计算量大的表达式，并将其结果保存为一组新的时间序列
• 查询预先计算的结果通常比每次需要时执行原始表达式快得多
• 这对于需要在每次刷新时重复查询相同表达式的仪表板特别有用

记录和警报规则存在于规则组中。组内的规则按固定间隔按顺序运行，评估时间相同。记录规则的名称必须是有效的指标名称。警报规则的名称必须是有效的标签值。

规则定义

• 记录规则应该是一般形式 level:metric:operationlevel = 规则输出的度量和标签的聚合级别metric = 评估中的指标名称操作= 应用于评估指标的操作列表

# rules/myrules.yml
groups:
  - name: example # The name of the group. Must be unique within a file.
    rules:
    - record: job:http_inprogress_requests:sum # The name of the time series to output to. Must be a valid metric name.
    # The PromQL expression to evaluate. Every evaluation cycle this is
    # evaluated at the current time, and the result recorded as a new set of
    # time series with the metric name as given by 'record'.
      expr: sum by (job) (http_inprogress_requests)

规则文件路径需要添加到主 Prometheus 配置中，以便按照定义的方式定期执行 evaluation_interval

rule_files:
  - "rules/myrules.yml"

检查规则语法

要在不启动 Prometheus 服务器的情况下快速检查规则文件的语法是否正确，您可以使用 Prometheus 的promtool命令行实用工具：

promtool check rules /path/to/example.rules.yml

告警

告警规则允许您根据 Prometheus 表达式语言表达式定义警报条件，并将有关触发警报的通知发送到外部服务。每当告警表达式在给定的时间点产生一个或多个向量元素时，警报对于这些元素的标签集算作活动。

告警规则在 Prometheus 中的配置方式与记录规则相同：

# rules/alert_rules.yml
groups:
- name: example
  rules:
  # Alert for any instance that has a median request latency >1s.
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    labels:
      severity: page
    annotations:
      summary: "High request latency on {{ $labels.instance }}"
      description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

• for - 在第一次遇到新的表达式输出向量元素和将告警计数为针对该元素触发之间等待一段时间
• 标签- 指定要附加到告警的一组附加标签
• 注释= 信息标签，可用于存储更长的附加信息，例如告警描述或操作手册链接

rule_files:
  - "rules/alert_rules.yml"

可以通过 Prometheus 仪表板中的“Alert”选项卡监控警报（哪些是活动的、待处理的、触发的等）

告警管理器

• 需要另一层在简单告警定义之上添加汇总、通知速率限制、静音和告警依赖项
• Prometheus 配置为定期向Alertmanager实例发送有关警报状态的信息，然后由实例负责发送正确的通知负责对它们进行重复数据删除、分组和路由到正确的接收器集成，例如电子邮件、PagerDuty
• 从https://prometheus.io/download/作为单个 Go 二进制文件提供，因此可以直接执行./alertmanager - 默认在端口上运行 9093或使用 Docker docker run --name alertmanager -d -p 9093:9093 quay.io/prometheus/alertmanager从alertmanager.yml同一目录中的文件中获取配置

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 'localhost:9093'

发送电子邮件通知

• alertmanager.yml文件定义了定义应如何管理告警的路由树。如果没有匹配的标签，则使用默认Root

route:
  receiver: admin

receivers:
- name: admin
  email_configs:
  - to: 'example@gmail.com'
    from: 'example@gmail.com'
    smarthost: smtp.gmail.com:587
    auth_username: 'example@gmail.com'
    auth_password: 'abcdefghijklmnop'

路由树

• 分组将类似性质的告警分类为单个通知。当许多系统同时发生故障并且可能同时触发数百到数千个告警时，这在较大的中断期间尤其有用。将 Alertmanager 配置为按集群和告警名称对告警进行分组，以便它发送单个紧凑通知。
• 抑制是在某些其他告警已经触发时抑制某些告警的通知的概念
• 静音是一种在给定时间内简单地将告警静音的方法。静音是基于匹配器配置的，就像路由树一样。检查传入告警是否与活动静默的所有相等或正则表达式匹配器匹配。如果他们这样做，则不会发送该告警的通知。通过 UI 配置。如果基于时间，请改为向基础规则添加条件
• 默认情况下，通过路由树运行的每个警报将在与同一级别的第一个接收器匹配后停止 - 可以使用continue子句

route:
  receiver: admin # root fallback
  group_wait: 2m # how long to wait for other alerts in a group to fire before notifying (after initial)
  group_interval: 10s # how long to wait before sending a notification about new alerts added to an already firing group
  repeat_interval: 30m # how long to wait before sending a notification again if it has already been sent
  routes:
  - match_re:
      app_type: (linux|windows) # custom label specified in the rule definition file
    receiver: ss-admin # fallback receiver
    group_by: [severity] # group all alerts on a label to send compact notification
    routes:
    - match:
        app_type: linux # match on more specific label
      receiver: linux-teamlead # target more specific receiver
      routes: # nested routes on different labels
      - match:
          severity: critical
        receiver: delivery-manager
        continue: true
      - match:
          severity: warning
        receiver: linux-teamlead

  - match_re:
      app_type: (python|go)
    receiver: pec-admin # fallback receiver
    routes:
    - match:
        app_type: python
      receiver: python-team-admin # fallback receiver
      routes:
      - match:
          severity: critical
        receiver: python-team-manager
      - match:
          severity: warning
        receiver: python-team-lead

inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning' # mute warning alert if critical alert already raised in same app and category
  equal: ['app_type', 'category']

receivers:
- name: linux-team-lead
  email_configs:
  - to: 'example@gmail.com'

检查树语法

要在不启动 AlertManager 实例的情况下快速检查告警路由树文件的语法是否正确，您可以使用该amtool实用程序：

amtool check-config alertmanager.yml

或者https://prometheus.io/webtools/alerting/routing-tree-editor/可以用来可视化路由树

HTTP API

允许直接端点查询即时/范围查询、查看目标、配置等

• localhost:9090/api/v1/query?query=up
• localhost:9090/api/v1/query?query=http_requests_total[1m]
• localhost:9090/api/v1/targets?state=active / localhost:9090/api/v1/rules?type=alert

https://prometheus.io/docs/prometheus/latest/querying/api/

Push Gateway 推送网关

这种pull方法不适用于临时工作，因为这些工作运行时间不够长，Prometheus 无法抓取它们。Pushgateway是服务级别批处理作业的指标缓存。用于处理从批处理/cron 作业推送的指标的展示。如果Pushgateway从多个目标收集指标的实例出现故障，则所有指标都将丢失。

• 从https://prometheus.io/download/作为单个 Go 二进制文件提供，因此可以直接执行./pushgateway - 默认在端口上运行 9091或使用 Docker docker run -d -p 9091:9091 prom/pushgateway
• 需要Pushgateway在 Prometheus 中添加为抓取目标

- job_name: "pushgateway"
  honor_labels: true # instrumentation labels to override target labels
  static_configs:
    - targets: ["localhost:9091"]

• 指标可以Pushgateway通过发送 HTTPPOST请求 从作业实例发送到echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
• 或 Prometheus 客户端库应该具有将注册的指标推送到 Pushgatewayhttps://prometheus.github.io/client_java/io/prometheus/client/exporter/PushGateway.html