Prometheus快速了解

概览

Prometheus是一个独立的开源监控系统。其组成主要有时序数据库、数据采集、数据查询（PromQL查询语言）和报警。
先看一下Prometheus结构图

Prometheus工作流程

1. 先得部署一个被监控的应用：App。
2. 让App和Prometheus通信才能达到监控的目的。
3. 将app关联到Prometheus，即在Prometheus中配置被监控App的位置信息。
4. 需要采集app的数据，App就得按照Prometheus提供的规则编写Http接口。

• 数据采集两种方式：

  1. 比如Java应用，可以在Java应用中引入相关依赖，提供Prometheus采集数据的pull接口。
  2. 提供exporter做为中间层适配数据采集。

1. Prometheus按时通过该接口pull数据，即达到数据采集的目的。
2. 但是监控平台很多时候不止监控一个应用，也许成百上千个，并且这些应用的位置等配置信息还在动态改变，因此为了方便部署和管理应用，此时引入了kubernetes或marathon集群管理系统。
3. Prometheus只用连接到集群管理系统即可拿到所有被监控应用的配置信息。
4. 然后我们就可以通过PromQL查询我们想要的数据或以图的方式显示：。
5. Prometheus根据配置规则产生警报，并将警报发送给Alertmanager,Alertmanager通过聚合分组，去重等一些列处理后，才会通过Email、短信或电话将警报信息可发送给用户。

• 告警规则需要在Prometheus配置文件中配置

Alertmanager

原文档

接收警报的配置

配置文件定义了抑制规则，通知路由和通知接收者。
用如下命令查看所有可配置标签：

alertmanager -h

使用目标配置文件启动Alertmanager

./alertmanager --config.file=simple.yml

route匹配

• 例子

# The root route with all parameters, which are inherited by the child
# routes if they are not overwritten.
route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  # All alerts that do not match the following child routes
  # will remain at the root node and be dispatched to 'default-receiver'.
  routes:
  # All alerts with service=mysql or service=cassandra
  # are dispatched to the database pager.
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
  # All alerts with the team=frontend label match this sub-route.
  # They are grouped by product and environment rather than cluster
  # and alertname.
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

• 每个警报在配置的顶级路由上进入路由树，它必须匹配所有警报。然后遍历子节点。如果continue设置为false，那么它将在第一个匹配的子节点之后停止。如果在匹配节点上continue为真，则警报将继续匹配后续的兄弟节点。如果警报不匹配节点的任何子节点(没有匹配的子节点，或者根本不存在)，则根据当前节点的配置参数处理警报。

接收警报的数据结构

webhooks是一个api概念，是微服务api的使用范式之一，也被成为反向api，即：前端不主动发送请求，完全由后端推送。 举个常用例子，比如你的好友发了一条朋友圈，后端将这条消息推送给所有其他好友的客户端，就是 Webhooks 的典型场景。

Prometheus通过webhook向Alertmanager推送警报，数据结构如下：

Alers结构如下：

每个警报的标签用于标识警报的相同实例并执行重复数据删除。注释总是设置为最近收到的，并且没有标识警报。
KV是一组用于表示标签和注释的键/值字符串对。

type KV map[string]string

例如：

{
  summary: "alert summary",
  description: "alert description",
}

关于对KV的操作：

Alertmanager管理

1. 检查Alertmanager状态

GET /-/healthy

1. Alertmanager已经准备好为流量服务

GET /-/ready

1. 重新加载配置信息

POST /-/reload

有疑问加站长微信联系（非本文作者）