prometheus配置文件中的一些时间概念及名词解释

1、group by
举例：group_by: ['id','alertname']
出现在alertmanager.yml中，表示根据labels中的某一个或多个属性进行分组，以某个告警信息中的labels为例：

"labels":{
          "alertname":"CPU使用率超限",
          "beta_kubernetes_io_arch":"amd64",
          "beta_kubernetes_io_os":"linux",
          "cluster":"prod-kubernetes",
          "container_name":"scope-agent
          "cpu":"total",
          "id":"/kubepods/besteffort/pod4862efd9-0a6e-11e9-a53f-066788000017/da98b52508ac2cc148cf816ff62357c8ca867c56a8e2e62b57d0c4fd9bfc3903",
          "image":"sha256:de09b72e4a4f440f20fe6db755bfdc089bea1c70ed6c7acf0a22eeb40f836366",
          "instance":"node-qiznap13",
          "job":"kubernetes-cadvisor",
          "kubernetes_io_hostname":"node-qiznap13
          "name":"k8s_scope-agent_weave-scope-agent-92vzx_weave_4862efd9-0a6e-11e9-a53f-066788000017_1",
          "namespace":"weave",
          "pod_name":"weave-scope-agent-92vzx",
          "severity":"critical"
         }

group_by: ['id','alertname']的意思是说将id和alertmanager相同的告警分成一组，每一个分组最后都会合成一条信息在产生告警之后发送过来。这种方式可以有效减少告警消息的数量。

在Alertmanager的网页端可以对分组的情况进行实验，如：
在这里插入图片描述
这里将告警以alertname、id、pod三个指标进行分组，将三个指标均相同的告警分成一个告警组。上面的这组告警上方仅显示了alertname=“Daemonset-健康状态”，是因为这条告警并没有id字段和pod字段。

2、模板
Templating(模板) 标签和注释值可以使用控制台模板进行模板化。 $labels变量保存警报实例的标签键/值对，$ value保存警报实例的评估值。

# To insert a firing element's label values:
#labels后面能点出来的属性就是上面展示的labels所有的属性
{{ $labels.<labelname> }}
# To insert the numeric expression value of the firing element:
#查询出来的值，也就是超出阈值线的那个指标值
{{ $value }}

3、第一个是prometheus的容器，使用docker-enter结合docker ps | grep prom查出的信息一起，可以进入到容器内部（使用exit指令退出容器）。第二个则不行。

k8s_prometheus_prometheus-core 
k8s_POD_prometheus-core

4、待补充
for
[1m]
step=5m

5、待补充
Pending

6、静默

配置抑制规则，是存在另一组匹配器匹配的情况下，静音其他引发警报的规则。也就是说允许在其他警报处于触发状态时，抑制一些警报的通知。这两个警报，必须有一组相同的标签。如果同一警报（基于警报名称）已经非常紧急，那么我们可以配置一个抑制来使其他低警告级别的通知静音。

写在alertmanager.yml文件中：

# Matchers that have to be fulfilled in the alerts to be muted.
# 匹配target的是将要被静默的告警
target_match:
  [ <labelname>: <labelvalue>, ... ]
target_match_re:
  [ <labelname>: <regex>, ... ]

# Matchers for which one or more alerts have to exist for the  nhibition to take effect.
# 匹配source的是生效的告警
source_match:
  [ <labelname>: <labelvalue>, ... ]
source_match_re:
  [ <labelname>: <regex>, ... ]

# Labels that must have an equal value in the source and target alert for the inhibition to take effect.
[ equal: '[' <labelname>, ... ']' ]

实例：

inhibit_rules: 
  - source_match: 
      alertType: 'Custom' 
    target_match: 
      alertType: 'Default' 
    equal: ['alertname', 'id','pod']

这条静默的意思为：如果存在alertType: 'Custom' 的告警则静默相对应的（alertname、id、pod皆相同）包含alertType: 'Default' 的告警。当然，如果这组告警（alertname、id、pod皆相同）不存在alertType: ‘Custom’ 的告警，alertType: ‘Default’ 自然不需要静默。

如下：这两条告警并没有被静默。
在这里插入图片描述
英文版：

An inhibition rule mutes an alert (target) matching a set of matchers
when an alert (source) exists that matches another set of matchers.
Both target and source alerts must have the same label values for the
label names in the equal list.
简译：1、满足一定条件的告警被抑制的前提是需要“存在”满足一定条件的生效的告警。2、被静默的告警和生效的告警在equal数组中的标签对应的标签值必须相等。
Semantically, a missing label and a label with an empty value are the
same thing. Therefore, if all the label names listed in equal are
missing from both the source and target alerts, the inhibition rule
will apply.
简译：在equal数组中的标签如果在target告警和source告警中都没有，则这条抑制规则也是可以生效的。
To prevent an alert from inhibiting itself, an inhibition rule will
never inhibit an alert that matches both the target and the source
side of the rule. However, we recommend to choose target and source
matchers in a way that alerts never match both sides. It is much
easier to reason about and does not trigger this special case.
简译：equal数组中的标签在target告警和source告警中的值不能相等，既不能两边都匹配。

注：修改策略文件reload的端口号为prometheus的端口号，修改alertmanager.yml文件后reload的端口号为alertmanager的端口号。

prometheus配置文件中的一些时间概念及名词解释

猜你喜欢