• 欢迎来到小爱博客,一个分享互联网IT技术的网站,喜欢就收藏吧!

prometheus报警示例

prometheus 小爱 2个月前 (08-08) 48次浏览 已收录 0个评论 扫描二维码

Prometheus是我最近的监视工具。Prometheus的核心是一个时间序列数据库,可以使用功能强大的语言查询所有内容,这不仅包括绘图,而且还包括警报。通常将通过Prometheus生成的警报发送到Alertmanager,以通过电子邮件或Slack消息等各种媒体进行传递。

一切都很好,但是当我开始使用它时,我很挣扎,因为 Prometheus没有内置的警报。但是,在Internet上,我发现了以下警报示例:

从我的角度来看,缺少立即可用的示例对于开始使用Prometheus的任何人来说都是一个巨大的痛苦。幸运的是,社区意识到了这一点,并致力于各种建议:

所有这些似乎都很棒,但是我们还没有到那儿,所以这是我谦虚的尝试,在上述资源中添加更多示例。我希望它能帮助您开始使用Prometheus和Alertmanager。

先决条件

在开始设置警报之前,您必须在Prometheus时间序列数据库中具有指标。Prometheus的出口商有很多,它们公开了各种指标,但我将向您展示以下示例:

  • node_exporter用于硬件警报
  • redis_exporter用于Redis集群警报
  • 用于Kafka和Zookeeper警报的jmx-exporter
  • consul_exporter用于提醒Consul指标

除JMX之外,所有导出器都非常易于设置,因为JMX应该在Kafka / Zookeeper JVM中作为Java代理运行。请参阅我以前的有关设置jmx-exporter的文章。

在设置了所有需要的导出器并收集了一段时间的指标之后,我们就可以开始制作警报了。

警报

我的警报原理非常简单-仅在确实发生故障时发出警报,包括最大信息并通过多种媒体传送。

您在Prometheus服务器而不是Alertmanager上以alert.rules文件形式(通常在中/etc/prometheus)描述警报,因为后者负责格式化和传递警报。

alert.rules的格式为YAML,其格式如下:

groups:
- name: Hardware alerts
  rules:
  - alert: Node down
    expr: up{job="node_exporter"} == 0
    for: 3m
    labels:
      severity: warning
    annotations:
      title: Node {{ $labels.instance }} is down
      description: Failed to scrape {{ $labels.job }} on {{ $labels.instance }} for more than 3 minutes. Node seems down.

您有一个groups包含组列表的顶级密钥。我通常为每个导出器创建一个组,因此对于node_exporter我有硬件警报,对于redis_exporter我有Redis警报,等等。

另外,我所有的警报都有2个注释-Alertmanager将使用的标题和描述。

使用node_exporter发出硬件警报

让我们从一个简单的例子开始-当服务器关闭时发出警报。

- alert: Node down
  expr: up{job="node_exporter"} == 0
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Node {{ $labels.instance }} is down
    description: Failed to scrape {{ $labels.job }} on {{ $labels.instance }} for more than 3 minutes. Node seems down.

此警报的本质是表达状态up{job="node_exporter"} == 0。我看过很多示例,up == 0但是很奇怪,因为每个被Prometheus抓取的导出器都有这个指标,因此您将收到有关完全不需要的警告,例如重新启动postgres_exporter,这与Postgres本身不一样。 。因此,我将作业标签设置为node_exporter以明确刮取节点的运行状况。

此警报的另一个关键部分是,该警报for: 3m告诉Prometheus仅在表达式保持为真3分钟时才发送警报。这是为了避免由于网络故障而导致某些刮取失败时的误报。它基本上可以提高警报的健壮性。

有人为此将blackbox_exporter与ICMP探针一起使用。

接下来是Linux md raid警报

- alert: MDRAID degraded
  expr: (node_md_disks - node_md_disks_active) != 0
  for: 1m
  labels:
    severity: warning
  annotations:
    title: MDRAID on node {{ $labels.instance }} is in degrade mode
    description: Degraded RAID array {{ $labels.device }} on {{ $labels.instance }}: {{ $value }} disks failed

在这一部分中,我检查磁盘总数与活动磁盘数目之间的差异,并{{ $value }}在说明中使用差异值。

您还可以通过$labels变量访问指标标签,以将有用的信息放入警报中。

下一个是绑定状态:

- alert: Bond degraded
  expr: (node_bonding_active - node_bonding_slaves) != 0
  for: 1m
  labels:
    severity: warning
  annotations:
    title: Bond is degraded on {{ $labels.instance }}
    description: Bond {{ $labels.master }} is degraded on {{ $labels.instance }}

这类似于mdraid一。

硬件警报的最后一个是可用空间:

- alert: Low free space
  expr: (node_filesystem_free{mountpoint !~ "/mnt.*"} / node_filesystem_size{mountpoint !~ "/mnt.*"} * 100) < 15
  for: 1m
  labels:
    severity: warning
  annotations:
    title: Low free space on {{ $labels.instance }}
    description: On {{ $labels.instance }} device {{ $labels.device }} mounted on {{ $labels.mountpoint }} has low free space of {{ $value }}%

为了计算可用空间,我将其计算为百分比,然后检查它是否小于15%。在上面的表达式中,我还将所有挂载点都排除在外, /mnt因为它通常位于节点外部,例如远程存储,它可能接近满载,例如用于备份。

最后的说明是labels我设定的位置severity: warning。受Google SRE书籍的启发,我决定仅使用2个严重性级别进行警报- warning 和pagewarning警报应发送到票务系统,您应在正常工作日内对这些警报做出反应。page警报属​​于紧急事件,可能会唤醒呼叫工程师–应谨慎设计此类警报,以免耗尽。基于级别的警报路由由Alertmanager管理。

Redis警报

这些非常简单–我们会对warningredis集群实例的可用性发出警报,并page在整个集群损坏时发出警报:

- alert: Redis instance is down
  expr: redis_up == 0
  for: 1m
  labels:
    severity: warning
  annotations:
    title: Redis instance is down
    description: Redis is down at {{ $labels.instance }} for 1 minute.

- alert: Redis cluster is down
  expr: min(redis_cluster_state) == 0
  labels:
    severity: page
  annotations:
    title: Redis cluster is down
    description: Redis cluster is down.

这些指标由redis_exporter报告。我将其部署在Redis集群的所有实例上-这就是为什么在上min应用了功能 的原因redis_cluster_state

我有一个Redis集群,但是如果有多个集群,则应将其包括在警报描述中-可能通过标签。

卡夫卡警报

对于Kafka,我们检查代理的可用性和群集的运行状况。

- alert: KafkaDown
  expr: up{instance=~"kafka-.+", job="jmx-exporter"} == 0
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Kafka broker is down
    description: Kafka broker is down on {{ $labels.instance }}. Could not scrape jmx-exporter for 3m.

要检查Kafka是否关闭,我们up从jmx-exporter 检查指标。这是检查Kafka进程是否存活的明智方法,因为jmx-exporter作为Java代理 Kafka进程运行。我们还按实例名称进行过滤,因为jfx-expoter既针对Kafka也针对Zookeeper运行。

- alert: KafkaNoController
  expr: sum(kafka_controller_kafkacontroller_activecontrollercount) < 1
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Kafka cluster has no controller
    description: Kafka controller count < 1, cluster is probably broken.

这将检查活动控制器。该控制器负责管理分区和副本的状态,并负责执行管理任务,例如重新分配分区。每个经纪人都报告 kafka_controller_kafkacontroller_activecontrollercount度量标准,但只有当前控制者会报告1-这就是我们使用的原因sum

如果您将Kafka用作事件总线或用于任何其他实时处理,则可以page为此选择严重性。就我而言,我将其用作队列,如果断开,则客户端请求不会受到影响。这就是为什么我在这里发出严重警告。

- alert: KafkaOfflinePartitions
  expr: sum(kafka_controller_kafkacontroller_offlinepartitionscount) > 0
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Kafka cluster has offline partitions
    description: "{{ $value }} partitions in Kafka went offline (have no leader), cluster is probably broken.

在这一部分中,我们检查脱机分区。这些分区没有领导者,因此无法接受或传递消息。我们检查所有节点上的脱机分区,这就是我们sum在警报表达中使用的原因。

同样,如果您使用Kafka进行某些实时处理,则可以选择page为这些警报分配 严重性。

- alert: KafkaUnderreplicatedPartitions
  expr: sum(kafka_cluster_partition_underreplicated) > 10
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Kafka cluster has underreplicated partitions
    description: "{{ $value }} partitions in Kafka are under replicated

最后,我们检查复制下的分区。当某些Kafka节点发生故障且分区无处复制时,可能会发生这种情况。这并不妨碍Kafka可以从该分区中进行服务-生产者和消费者将继续工作,但是该分区中的数据存在风险。

Zookeeper警报

Zookeeper警报类似于Kafka –我们检查实例可用性和集群运行状况。

- alert: Zookeeper is down
  expr: up{instance=~"zookeeper-.+", job="jmx-exporter"} == 0
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Zookeeper instance is down
    description: Zookeeper is down on {{ $labels.instance }}. Could not scrape jmx-exporter for 3 minutes>

就像使用Kafka一样,我们从up jmx-exporter的指标检查Zookeeper实例的可用性,因为它在Zookepeer进程中运行。

- alert: Zookeeper is slow
  expr: max_over_time(zookeeper_MaxRequestLatency[1m]) > 10000
  for: 3m
  labels:
    severity: warning
  annotations:
    title: Zookeeper high latency
    description: Zookeeper latency is {{ $value }}ms (aggregated over 1m) on {{ $labels.instance }}.

您真的应该在延迟方面关心Zookeeper的性能,因为如果依赖缓慢的系统将陷入惨境–领导者选举将失败,复制将失败,并且所有其他坏事都会发生。

Zookeeper延迟是通过zookeeper_MaxRequestLatency指标报告的,但它是衡量指标的,因此您无法对其应用increaserate起作用。这就是为什么我们使用max_over_time间隔为1m 的原因 。

警报正在检查最大延迟是否超过10秒(10000毫秒)。这看似极端,但我们在生产中就看到了。

- alert: Zookeeper ensemble is broken
  expr: sum(up{job="jmx-exporter", instance=~"zookeeper-.+"}) < 2
  for: 1m
  labels:
    severity: page
  annotations:
    title: Zookeeper ensemble is broken
    description: Zookeeper ensemble is broken, it has {{ $value }} nodes in it.

最后,有一个有关Zookeeper集成状态的警报,其中我们up 对jmx-exporter的度量值求和。请记住,它运行在Zookeeper JVM中,因此从本质上讲,我们检查Zookeeper实例是否正常运行,并将其与我们大多数集群(如果是3节点集群,则为2)进行比较。

领事警报

与Zookeeper和任何其他群集系统类似,我们检查Consul可用性和群集运行状况。

Consul有2个度量标准来源– 1)官方consul_exporter和2)通过遥测配置的Consul本身。

consul_exporter提供了大多数指标来监视在Consul中注册的节点和服务的运行状况。Consul本身公开了内部指标,例如客户端RPC RPS速率和其他运行时指标。

要检查领事代理是否健康,我们使用consul_agent_node_status 带有以下标签的指标status="critical"

- alert: Consul agent is not healthy
  expr: consul_health_node_status{instance=~"consul-.+", status="critical"} == 1
  for: 1m
  labels:
    severity: warning
  annotations:
    title: Consul agent is down
    description: Consul agent is not healthy on {{ $labels.node }}.

接下来,我们通过来检查集群降级consul_raft_peers。该指标报告集群中有多少个服务器节点。诀窍是对其应用min功能,这样我们就可以检测到一个实例认为它有2个筏对等点而另一个实例有1个筏对等点的网络分区。

- alert: Consul cluster is degraded
  expr: min(consul_raft_peers) < 3
  for: 1m
  labels:
    severity: page
  annotations:
    title: Consul cluster is degraded
    description: Consul cluster has {{ $value }} servers alive. This may lead to cluster break.

最后,我们检查自动驾驶仪状态。当领导者不断检查其他服务器的稳定性时,自动驾驶是Consul的一项功能。这是内部指标,由领事本身报告。

- alert: Consul cluster is not healthy
  expr: consul_autopilot_healthy == 0
  for: 1m
  labels:
    severity: page
  annotations:
    title: Consul cluster is not healthy
    description: Consul autopilot thinks that cluster is not healthy.

结论

我希望您会发现这很有用,这些示例警报将帮助您快速开始Prometheus之旅。

您可以将许多有用的指标用于警报,这里没有神奇之处–研究您拥有的指标,考虑一下它如何有助于跟踪系统的稳定性,冲洗和重复。


小爱博客 , 版权所有
转载请注明原文链接:prometheus报警示例
喜欢 (0)
【你的支持, 我的动力】
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址