alert 订阅
alert是HTML DOM 中用到的一种脚本语言,它的中文意思是“提醒”。它是JavaScript或VBscript脚本语言中窗口window对象的一个常用方法;其主要用法就是在你自己定义了一定的函数以后,通过执行相应的操作,所弹出对话框的语言。并且alert对话框通常用于一些对用户的提示信息。常见的为alert函数。 展开全文
alert是HTML DOM 中用到的一种脚本语言,它的中文意思是“提醒”。它是JavaScript或VBscript脚本语言中窗口window对象的一个常用方法;其主要用法就是在你自己定义了一定的函数以后,通过执行相应的操作,所弹出对话框的语言。并且alert对话框通常用于一些对用户的提示信息。常见的为alert函数。
信息
类    别
脚本语言
运用范围
HTML DOM
释    义
提醒
中文名
alert
alert简介
alert函数:显示一个警告对话框,包括一个OK按钮。 [1]  说明:产生一个报警动作。语法:Alert(String AlertInfo)。参数:AlertInfo报警提示信息。备注:产生一个报警动作,将AlertInfo信息返回给最上层应用模块,该函数无返回值,该函数仅对用户字段、技术分析(技术指标、K线性态、特征走势)有效,不支持其他公式类型。示例:Alert(“BBI上穿报警”)弹出警报“BBI上穿报警”。 [2] 
收起全文
精华内容
下载资源
问答
  • alert
    千次阅读
    2021-08-17 21:11:50

    原文;https://www.cnblogs.com/gered/p/13496950.html
    目录

    【1】Alertmanager工作机制
    【2】AlertManager的三个概念
    分组(Grouping)
    抑制(Inhibition)
    静默(Silences )
    【3】安装Alertmanager
    【3.1】二进制安装
    【3.2】Alertmanager 参数
    参数 描述
    –config.file=“alertmanager.yml” 指定Alertmanager配置文件路径
    –storage.path=“data/” Alertmanager的数据存放目录
    –data.retention=120h 历史数据保留时间,默认为120h
    –alerts.gc-interval=30m 警报gc之间的间隔
    –web.external-url=WEB.EXTERNAL-URL 外部可访问的Alertmanager的URL(例如Alertmanager是通过nginx反向代理)
    –web.route-prefix=WEB.ROUTE-PREFIX wen访问内部路由路径,默认是 --web.external-url
    –web.listen-address=":9093" 监听端口,可以随意修改
    –web.get-concurrency=0 并发处理的最大GET请求数,默认为0
    –web.timeout=0 web请求超时时间
    –cluster.listen-address=“0.0.0.0:9094” 集群的监听端口地址。设置为空字符串禁用HA模式
    –cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS 配置集群通知地址
    –cluster.gossip-interval=200ms 发送条消息之间的间隔,可以以增加带宽为代价更快地跨集群传播。
    –cluster.peer-timeout=15s 在同级之间等待发送通知的时间
    … …
    –log.level=info 自定义消息格式 [debug, info, warn, error]
    –log.format=logfmt 日志消息的输出格式: [logfmt, json]
    –version 显示版本号

    【4】Alertmanager配置详解

    ## Alertmanager 配置文件
    global:
      resolve_timeout: 5m
      # smtp配置
      smtp_from: "123456789@qq.com"
      smtp_smarthost: 'smtp.qq.com:465'
      smtp_auth_username: "123456789@qq.com"
      smtp_auth_password: "auth_pass"
      smtp_require_tls: true
    # email、企业微信的模板配置存放位置,钉钉的模板会单独讲如果配置。
    templates:
      - '/data/alertmanager/templates/*.tmpl'
    # 路由分组
    route:
      receiver: ops
      group_wait: 30s # 在组内等待所配置的时间,如果同组内,30秒内出现相同报警,在一个组内出现。
      group_interval: 5m # 如果组内内容不变化,合并为一条警报信息,5m后发送。
      repeat_interval: 24h # 发送报警间隔,如果指定时间内没有修复,则重新发送报警。
      group_by: [alertname]  # 报警分组
      routes:
          - match:
              team: operations
            group_by: [env,dc]
            receiver: 'ops'
          - match_re:
              service: nginx|apache
            receiver: 'web'
          - match_re:
              service: hbase|spark
            receiver: 'hadoop'
          - match_re:
              service: mysql|mongodb
            receiver: 'db'
    # 接收器
    # 抑制测试配置
          - receiver: ops
            group_wait: 10s
            match:
              status: 'High'
    # ops
          - receiver: ops # 路由和标签,根据match来指定发送目标,如果 rule的lable 包含 alertname, 使用 ops 来发送
            group_wait: 10s
            match:
              team: operations
    # web
          - receiver: db # 路由和标签,根据match来指定发送目标,如果 rule的lable 包含 alertname, 使用 db 来发送
            group_wait: 10s
            match:
              team: db
    # 接收器指定发送人以及发送渠道
    receivers:
    # ops分组的定义
    - name: ops
      email_configs:
      - to: '9935226@qq.com,10000@qq.com'
        send_resolved: true
        headers:
          subject: "[operations] 报警邮件"
          from: "警报中心"
          to: "小煜狼皇"
      # 钉钉配置
      webhook_configs:
      - url: http://localhost:8070/dingtalk/ops/send
        # 企业微信配置
      wechat_configs:
      - corp_id: 'ww5421dksajhdasjkhj'
        api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
        send_resolved: true
        to_party: '2'
        agent_id: '1000002'
        api_secret: 'Tm1kkEE3RGqVhv5hO-khdakjsdkjsahjkdksahjkdsahkj'
    
    # web
    - name: web
      email_configs:
      - to: '9935226@qq.com'
        send_resolved: true
        headers: { Subject: "[web] 报警邮件"} # 接收邮件的标题
      webhook_configs:
      - url: http://localhost:8070/dingtalk/web/send
      - url: http://localhost:8070/dingtalk/ops/send
    # db
    - name: db
      email_configs:
      - to: '9935226@qq.com'
        send_resolved: true
        headers: { Subject: "[db] 报警邮件"} # 接收邮件的标题
      webhook_configs:
      - url: http://localhost:8070/dingtalk/db/send
      - url: http://localhost:8070/dingtalk/ops/send
    # hadoop
    - name: hadoop
      email_configs:
      - to: '9935226@qq.com'
        send_resolved: true
        headers: { Subject: "[hadoop] 报警邮件"} # 接收邮件的标题
      webhook_configs:
      - url: http://localhost:8070/dingtalk/hadoop/send
      - url: http://localhost:8070/dingtalk/ops/send
    
    # 抑制器配置
    inhibit_rules: # 抑制规则
      - source_match: # 源标签警报触发时抑制含有目标标签的警报,在当前警报匹配 status: 'High'
          status: 'High'  # 此处的抑制匹配一定在最上面的route中配置不然,会提示找不key。
        target_match:
          status: 'Warning' # 目标标签值正则匹配,可以是正则表达式如: ".*MySQL.*"
        equal: ['alertname','operations', 'instance'] # 确保这个配置下的标签内容相同才会抑制,也就是说警报中必须有这三个标签值才会被抑制。
    

    【4.1】案例演示
    【4.2】route 路由匹配规则
    【4.3】receiver 接收器
    【4.4】inhibit_rules 抑制器
    【5】警报通知接收器
    【参考文档】

    更多相关内容
  • 自己写了个alert提示框。因为系统alert在苹果手机微信中,提示时,顶部会显示网站地址。 同时其他后续操作需要在js中继续填写。因此简单用div写了一个alert提示框,并自动关闭。 效果图 css样式 /*弹出消息对话框...
  • 主要介绍了Element Alert警告的具体使用方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • alert隐藏弹窗网址title,试了很久,终于去除了js alert弹窗的网址标题提示,苹果端和安卓端,微信端都适用,亲测有效
  • <script>alert(111);</script>

    2020-03-24 16:17:44
    <script>alert(111);</script><script>alert(111);</script><script>alert(111);</script><script>alert(111);</script><script>alert(111);</script><script>alert(111);</script><script>alert(111);</script>...
  • alert弹出框插件

    2019-06-12 11:34:17
    alert()弹出框插件,可传入普通字符串、图片、html代码,若要展示图片时,需传入完整的img标签及src地址.
  • sweetalert

    2018-05-31 13:54:55
    超级美的弹框等等,只需要将js和css引入项目,引用即可以使用。
  • html自定义alert提示框

    2019-06-13 16:27:37
    有时候感觉系统自带的提示框太丑了,试试自定义提示框吧,直接引用js即可
  • alertmanager arm64安装包

    2022-06-17 14:50:58
    alertmanager tar.gz包包含alertmanager alertmanager.yml amtool data LICENSE NOTICE
  • js alert 提示窗口

    2019-07-29 01:06:09
    NULL 博文链接:https://jsufly.iteye.com/blog/804271
  • sweetalert弹窗插件JS、CSS文件以及示例HTML页面。资源出自:http://mishengqiang.com/sweetalert/
  • 在做html5网页开发的过程中,如果想要alert或confirm弹出信息时,苹果手机会自动带出网址,加上这段js就可以去掉网址信息
  • alert提示框(多种样式)

    2017-05-24 15:14:39
    alert提示框(多种样式), 和大家分享了
  • sweetalert.css

    2016-09-21 13:46:51
    sweetalert.css 在项目中引入,结合sweetalert.min.js使用
  • Alert消息框中设置icon图标的例子
  • alert去掉地址信息

    热门讨论 2014-09-06 19:06:05
    alert弹出框去掉地址信息!是页面设计更完美!
  • Prometheus(四)——Alertmanager

    千次阅读 2022-04-11 22:18:41
    在Prometheus Server中定义告警规则以及产生告警,Alertmanager组件则用于处理这些 由Prometheus产生的告警。Alertmanager即Prometheus体系中告警的统一处理中心。Alertmanager提供了多 种内置第三方告警通知方式,...

    目录

    1、Prometheus告警简介

    2、Alertmanager特性

    2.1、分组

    2.2、抑制

    2.3、静默

    3、alertermanager 部署

    3.1、使用二进制包部署AlertManager

    3.2、alertmanager配置文件

    3.3、关联Prometheus与Alertmanager

    3.4、Alertmanager配置概述

    3.5、基于标签的告警路由

    3.6、路由匹配

    3.7、告警分组

    3.8、内置告警接收器Receiver

    3.9、与SMTP邮件集成

    4、自定义Prometheus告警规则

    4.1、定义告警规则

    4.2、模板化

    4.3、查看告警状态

    4.4、屏蔽告警通知

    5、实例:定义主机监控告警


    在Prometheus Server中定义告警规则以及产生告警,Alertmanager组件则用于处理这些 由Prometheus产生的告警。Alertmanager即Prometheus体系中告警的统一处理中心。Alertmanager提供了多 种内置第三方告警通知方式,同时还提供了对Webhook通知的支持,通过Webhook用户可以完成对告警更多个性化的 扩展。

    Alertmanager作为一个独立的组件,负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告 警信息。Alertmanager可以对这些告警信息进行进一步的处理,比如当接收到大量重复告警时能够消除重复的告警 信息,同时对告警信息进行分组并且路由到正确的通知方,Prometheus内置了对邮件,Slack等多种通知方式的支 持,同时还支持与Webhook的集成,以支持更多定制化的场景。例如,目前Alertmanager还不支持钉钉,那用户完 全可以通过Webhook与钉钉机器人进行集成,从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警 抑制机制来对告警通知行为进行优化。

    1、Prometheus告警简介

    告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示,通过在Prometheus中定义AlertRule(告 警规则),Prometheus会周期性的对告警规则进行计算,如果满足告警触发条件就会向Alertmanager发送告警信息。

    在Prometheus中一条告警规则主要由以下几部分组成:

    告警名称:用户需要为告警规则命名,当然对于命名而言,需要能够直接表达出该告警的主要内容

    告警规则:告警规则实际上主要由PromQL进行定义,其实际意义是当表达式(PromQL)查询结果持续多长时 间(During)后出发告警

    2、Alertmanager特性

    Alertmanager除了提供基本的告警通知能力以外,还主要提供了如:分组、抑制以及静默等告警特性:

    2.1、分组

    分组机制可以将详细的告警信息合并成一个通知。在某些情况下,比如由于系统宕机导致大量的告警被同时触发,在 这种情况下分组机制可以将这些被触发的告警合并为一个告警通知,避免一次性接受大量的告警通知,而无法对问题 进行快速定位。

    例如,当集群中有数百个正在运行的服务实例,并且为每一个实例设置了告警规则。假如此时发生了网络故障,可能 导致大量的服务实例无法连接到数据库,结果就会有数百个告警被发送到Alertmanager。

    而作为用户,可能只希望能够在一个通知中就能查看哪些服务实例受到影响。这时可以按照服务所在集群或者告警名称对告警进行分组,而将这些告警内聚在一起成为一个通知。

    告警分组,告警时间,以及告警的接受方式可以通过Alertmanager的配置文件进行配置。

    2.2、抑制

    抑制是指当某一告警发出后,可以停止重复发送由此告警引发的其它告警的机制。

    例如,当集群不可访问时触发了一次告警,通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可 以避免接收到大量与实际问题无关的告警通知。

    抑制机制同样通过Alertmanager的配置文件进行设置。

    2.3、静默

    静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置, Alertmanager则不会发送告警通知。

    静默设置需要在Alertmanager的Web页面上进行设置。

    3、alertermanager 部署

    3.1、使用二进制包部署AlertManager

    Alertmanager最新版本的下载地址可以从Prometheus官方网站https://prometheus.io/download/获取。

    tar xf alertmanager-0.20.0.linux-amd64.tar.gz
    mv alertmanager-0.20.0.linux-amd64 /usr/local/alertmanager
    

    启动altermanager,并加入system管理

    cat /usr/lib/systemd/system/alertmanager.service
    [Unit]
    Description=alertmanager System
    Documentation=alertmanager System
    [Service]
    ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml
    [Install]
    WantedBy=multi-user.target
    
    cp alertmanager.yml alertmanager.yml.bak

    检查语法

    ./amtool check-config alertmanager.yml

    启动Alertmanager

    systemctl start alertmanager
    systemctl enable alertmanager

    Alertmanager启动后可以通过9093端口访问,http://192.168.33.10:9093

    3.2、alertmanager配置文件

    默认的alertmanager.yml配置文件,内容如下所示:

    global:
       resolve_timeout: 5m
    
    route:
       group_by: ['alertname']
       group_wait: 10s
       group_interval: 10s
       repeat_interval: 1h
       receiver: 'web.hook'
    receivers:
    - name: 'web.hook'
      webhook_configs:
      - url: 'http://127.0.0.1:5001/'
    inhibit_rules:
      - source_match:
          severity: 'critical'
        target_match:
          severity: 'warning'
        equal: ['alertname', 'dev', 'instance']

    Alertmanager的配置主要包含两个部分:路由(route)以及接收器(receivers)。所有的告警信息都会从配置中 的顶级路由(route)进入路由树,根据路由规则将告警信息发送给相应的接收器。

    在Alertmanager中可以定义一组接收器,比如可以按照角色(比如系统运维,数据库管理员)来划分多个接收器。接 收器可以关联邮件,Slack以及其它方式接收告警信息。

    当前配置文件中定义了一个默认的接收者default-receiver由于这里没有设置接收方式,目前只相当于一个占位符。

    在配置文件中使用route定义了顶级的路由,路由是一个基于标签匹配规则的树状结构。所有的告警信息从顶级路由 开始,根据标签匹配规则进入到不同的子路由,并且根据子路由设置的接收器发送告警。目前配置文件中只设置了一 个顶级路由route并且定义的接收器为default-receiver。因此,所有的告警都会发送给default-receiver。

    3.3、关联Prometheus与Alertmanager

    在Prometheus的架构中被划分成两个独立的部分。Prometheus负责产生告警,而Alertmanager负责告警产生后 的后续处理。因此Alertmanager部署完成后,需要在Prometheus中设置Alertmanager相关的信息。

    编辑Prometheus配置文件prometheus.yml,并添加以下内容

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

    重启Prometheus服务,成功后,可以从http://192.168.33.10:9090/config查看alerting配置是否生效。

    3.4、Alertmanager配置概述

    在Alertmanager中通过路由(Route)来定义告警的处理方式。路由是一个基于标 签匹配的树状匹配结构。根据接收到告警的标签匹配相应的处理方式。这里将详细介绍路由相关的内容。

    Alertmanager主要负责对Prometheus产生的告警进行统一处理,因此在Alertmanager配置中一般会包含以下几 个主要部分:

    全局配置(global):用于定义一些全局的公共参数,如全局的SMTP配置,Slack配置等内容;

    模板(templates):用于定义告警通知时的模板,如HTML模板,邮件模板等;

    告警路由(route):根据标签匹配,确定当前告警应该如何处理;

    接收人(receivers):接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook 等,接收人一般配合告警路由使用;

    抑制规则(inhibit_rules):合理设置抑制规则可以减少垃圾告警的产生

    其完整配置格式如下:

    global:
      [ resolve_timeout: <duration> | default = 5m ]
      [ smtp_from: <tmpl_string> ]
      [ smtp_smarthost: <string> ]
      [ smtp_hello: <string> | default = "localhost" ]
      [ smtp_auth_username: <string> ]
      [ smtp_auth_password: <secret> ]
      [ smtp_auth_identity: <string> ]
      [ smtp_auth_secret: <secret> ]
      [ smtp_require_tls: <bool> | default = true ]
      [ slack_api_url: <secret> ]
      [ victorops_api_key: <secret> ]
      [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/"]
      [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
      [ opsgenie_api_key: <secret> ]
      [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
      [ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
      [ hipchat_auth_token: <secret> ]
      [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
      [ wechat_api_secret: <secret> ]
      [ wechat_api_corp_id: <string> ]
      [ http_config: <http_config> ]
     
    templates:
      [ - <filepath> ... ]
    route: <route>
    
    receivers:
      - <receiver> ...
    
    inhibit_rules:
      [ - <inhibit_rule> ... ]

    在全局配置中需要注意的是 resolve_timeout ,该参数定义了当Alertmanager持续多长时间未接收到告警后标记告 警状态为resolved(已解决)。该参数的定义可能会影响到告警恢复通知的接收时间,读者可根据自己的实际场景进 行定义,其默认值为5分钟。在接下来的部分,我们将已一些实际的例子解释Alertmanager的其它配置内容。

    3.5、基于标签的告警路由

    在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树,以确定在接收到告警后Alertmanager需要 如何对其进行处理:

    route: <route>

    其中route中则主要定义了告警的路由匹配规则,以及Alertmanager需要将匹配到的告警发送给哪一个 receiver,一个最简单的route定义如下所示:

    route:
      group_by: ['alertname']
      receiver: 'web.hook'
    receivers:
    - name: 'web.hook'
      webhook_configs:
      - url: 'http://127.0.0.1:5001/'

    如上所示:在Alertmanager配置文件中,我们只定义了一个路由,那就意味着所有由Prometheus产生的告警在发 送到Alertmanager之后都会通过名为 web.hook 的receiver接收。这里的web.hook定义为一个webhook地址。 当然实际场景下,告警处理可不是这么简单的一件事情,对于不同级别的告警,我们可能会不完全不同的处理方式, 因此在route中,我们还可以定义更多的子Route,这些Route通过标签匹配告警的处理方式,route的完整定义如 下:

    [ receiver: <string> ]
    [ group_by: '[' <labelname>, ... ']' ]
    [ continue: <boolean> | default = false ]
    
    match:
      [ <labelname>: <labelvalue>, ... ]
    
    match_re:
      [ <labelname>: <regex>, ... ]
    
    [ group_wait: <duration> | default = 30s ]
    [ group_interval: <duration> | default = 5m ]
    [ repeat_interval: <duration> | default = 4h ]
    
    routes:
      [ - <route> ... ]

    3.6、路由匹配

    每一个告警都会从配置文件中顶级的route进入路由树,需要注意的是顶级的route必须匹配所有告警(即不能有任何 的匹配设置match和match_re),每一个路由都可以定义自己的接受人以及匹配规则。默认情况下,告警进入到顶级 route后会遍历所有的子节点,直到找到最深的匹配route,并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false,那么告警在匹配到第一个子节点之后就直接停止。如果continue为true, 报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点,那该告警将会基于当前路由节点的接收 器配置方式进行处理。

    其中告警的匹配有两种方式可以选择。一种方式基于字符串验证,通过设置match规则判断当前告警中是否存在标签 labelname并且其值等于labelvalue。第二种方式则基于正则表达式,通过设置match_re验证当前告警标签的值 是否满足正则表达式的内容。

    3.7、告警分组

    在之前的部分有讲过,Alertmanager可以对告警通知进行分组,将多条告警合合并为一个通知。这里我们可以使 用group_by来定义分组规则。基于告警中包含的标签,如果满足group_by中定义标签名称,那么这些告警将会合并 为一个通知发送给接收器。

    有的时候为了能够一次性收集和发送更多的相关信息时,可以通过group_wait参数设置等待时间,如果在等待时间 内当前group接收到了新的告警,这些告警将会合并为一个通知向receiver发送。

    而group_interval配置,则用于定义相同的Gourp之间发送告警通知的时间间隔。

    例如,当使用Prometheus监控多个集群以及部署在集群中的应用和数据库服务,并且定义以下的告警处理路由规则 来对集群中的异常进行通知。

    route:
      receiver: 'default-receiver'
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      group_by: [cluster, alertname]
      routes:
      - receiver: 'database-pager'
        group_wait: 10s
        match_re:
          service: mysql|cassandra
      - receiver: 'frontend-pager'
        group_by: [product, environment]
        match:
          team: frontend

    默认情况下所有的告警都会发送给集群管理员default-receiver,因此在Alertmanager的配置文件的根路由中, 对告警信息按照集群以及告警的名称对告警进行分组。

    如果告警时来源于数据库服务如MySQL或者Cassandra,此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由,如果告警中包含service标签,并且service为MySQL或者Cassandra,则 向database-pager发送告警通知,由于这里没有定义group_by等属性,这些属性的配置信息将从上级路由继承, database-pager将会接收到按cluser和alertname进行分组的告警通知。

    而某些告警规则来源可能来源于开发团队的定义,这些告警中通过添加标签team来标示这些告警的创建者。在 Alertmanager配置文件的告警路由下,定义单独子路由用于处理这一类的告警通知,如果匹配到告警中包含标签 team,并且team的值为frontend,Alertmanager将会按照标签product和environment对告警进行分组。此时 如果应用出现异常,开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题,可以快速 对应用进行问题定位。

    3.8、内置告警接收器Receiver

    前上一小节已经讲过,在Alertmanager中路由负责对告警信息进行分组匹配,并将像告警接收器发送通知。告警接 收器可以通过以下形式进行配置:

    receivers:
      - <receiver> ...
    

    每一个receiver具有一个全局唯一的名称,并且对应一个或者多个通知方式:

    name: <string>
    email_configs:
      [ - <email_config>, ... ]
    hipchat_configs:
      [ - <hipchat_config>, ... ]
    pagerduty_configs:
      [ - <pagerduty_config>, ... ]
    pushover_configs:
      [ - <pushover_config>, ... ]
    slack_configs:
      [ - <slack_config>, ... ]
    opsgenie_configs:
      [ - <opsgenie_config>, ... ]
    webhook_configs:
      [ - <webhook_config>, ... ]
    victorops_configs:
      [ - <victorops_config>, ... ]

    目前官方内置的第三方通知集成包括:邮件、 即时通讯软件(如Slack、Hipchat)、移动应用消息推送(如 Pushover)和自动化运维工具(例如:Pagerduty、Opsgenie、Victorops)。Alertmanager的通知方式中还 可以支持Webhook,通过这种方式开发者可以实现更多个性化的扩展支持。

    3.9、与SMTP邮件集成

    邮箱应该是目前企业最常用的告警通知方式,Alertmanager内置了对SMTP协议的支持,因此对于企业用户而言,只 需要一些基本的配置即可实现通过邮件的通知。

    在Alertmanager使用邮箱通知,用户只需要定义好SMTP相关的配置,并且在receiver中定义接收方的邮件地址即 可。在Alertmanager中我们可以直接在配置文件的global中定义全局的SMTP配置:

    global:
      [ smtp_from: <tmpl_string> ]
      [ smtp_smarthost: <string> ]
      [ smtp_hello: <string> | default = "localhost" ]
      [ smtp_auth_username: <string> ]
      [ smtp_auth_password: <secret> ]
      [ smtp_auth_identity: <string> ]
      [ smtp_auth_secret: <secret> ]
      [ smtp_require_tls: <bool> | default = true ]

    完成全局SMTP之后,我们只需要为receiver配置email_configs用于定义一组接收告警的邮箱地址即可,如下所 示:

     name: <string>
     email_configs:
       [ - <email_config>, ... ]

    每个email_config中定义相应的接收人邮箱地址,邮件通知模板等信息即可,当然如果当前接收人需要单独的SMTP 配置,那直接在email_config中覆盖即可:

    [ send_resolved: <boolean> | default = false ]
    to: <tmpl_string>
    [ html: <tmpl_string> | default = '{{ template "email.default.html" . }}' ]
    [ headers: { <string>: <tmpl_string>, ... } ]

    如果当前收件人需要接受告警恢复的通知的话,在email_config中定义 send_resolved 为true即可。

    如果所有的邮件配置使用了相同的SMTP配置,则可以直接定义全局的SMTP配置。

    这里,以Gmail邮箱为例,我们定义了一个全局的SMTP配置,并且通过route将所有告警信息发送到defaultreceiver中:

    global:
      smtp_smarthost: smtp.gmail.com:587
      smtp_from: <smtp mail from>
      smtp_auth_username: <usernae>
      smtp_auth_identity: <username>
      smtp_auth_password: <password>
    route:
      group_by: ['alertname']
      receiver: 'default-receiver'
     
     receivers:
       - name: default-receiver
         email_configs:
           - to: <mail to address>
             send_resolved: true
    

    4、自定义Prometheus告警规则

    Prometheus中的告警规则允许你基于PromQL表达式定义告警触发条件,Prometheus后端对这些触发规则进行周期 性计算,当满足触发条件后则会触发告警通知。默认情况下,用户可以通过Prometheus的Web界面查看这些告警规则 以及告警的触发状态。当Promthues与Alertmanager关联之后,可以将告警发送到外部服务如Alertmanager中并 通过Alertmanager可以对这些告警进行进一步的处理。

    4.1、定义告警规则

    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
          description: description info

    在告警规则文件中,我们可以将一组相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警 规则(rule)。一条告警规则主要由以下几部分组成:

    alert:告警规则的名称。

    expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。

    for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警 的状态为pending。

    labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。

    annotations:用于指定一组附加信息,比如用于描述告警详细信息的文字等,annotations的内容在告警 产生时会一同作为参数发送到Alertmanager。

    为了能够让Prometheus能够启用定义的告警规则,我们需要在Prometheus全局配置文件中通过rule_files指定 一组告警规则文件的访问路径,Prometheus启动后会自动扫描这些路径下规则文件中定义的内容,并且根据这些规 则计算是否向外部发送通知。

    rule_files:
        [ - <filepath_glob> ... ]

    默认情况下Prometheus会每分钟对这些告警规则进行计算,如果用户想定义自己的告警计算周期,则可以通 过 evaluation_interval 来覆盖默认的计算周期:

    global:
       [ evaluation_interval: <duration> | default = 1m ]

    4.2、模板化

    一般来说,在告警规则文件的annotations中使用 summary 描述告警的概要信息, description 用于描述告警的详 细信息。同时Alertmanager的UI也会根据这两个标签值,显示告警信息。为了让告警信息具有更好的可读性, Prometheus支持模板化label和annotations的中标签的值。

    通过 $labels. 变量可以访问当前告警实例中指定标签的值。$value则可以获取当前PromQL表达式计算 的样本值。

    # To insert a firing element's label values:
    {{ $labels.<labelname> }}
    # To insert the numeric expression value of the firing element:
    {{ $value }}

    例如,可以通过模板化优化summary以及description的内容的可读性:

       groups:
       - name: example
         rules:
    
         # Alert for any instance that is unreachable for >5 minutes.
         - 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."
         # 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
           annotations:
             summary: "High request latency on {{ $labels.instance }}"
             description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

    4.3、查看告警状态

    用户可以通过Prometheus WEB界面中的Alerts菜单查看当前Prometheus下的所有告警规则,以及其 当前所处的活动状态。

    同时对于已经pending或者firing的告警,Prometheus也会将它们存储到时间序列ALERTS{}中。

    可以通过表达式,查询告警实例:

    ALERTS{alertname="<alert name>", alertstate="pending|firing", <additional alert labels>}
    

    样本值为1表示当前告警处于活动状态(pending或者firing),当告警从活动状态转换为非活动状态时,样本值则 为0。

    4.4、屏蔽告警通知

    Alertmanager提供了方式可以帮助用户控制告警通知的行为,包括预先定义的抑制机制和临时定义的静默规则。

    抑制机制

    Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通 知。例如当集群不可用时,用户可能只希望接收到一条告警,告诉他这时候集群出现了问题,而不是大量的如集群中 的应用异常、中间件服务异常的告警通知。

    在Alertmanager配置文件中,使用inhibit_rules定义一组告警的抑制规则:

    inhibit_rules:
      [ - <inhibit_rule> ... ]

    每一条抑制规则的具体配置如下:

    target_match:
      [ <labelname>: <labelvalue>, ... ]
    target_match_re:
      [ <labelname>: <regex>, ... ]
    
    source_match:
      [ <labelname>: <labelvalue>, ... ]
    source_match_re:
      [ <labelname>: <regex>, ... ]
      [ equal: '[' <labelname>, ... ']' ]

    当已经发送的告警通知匹配到target_match和target_match_re规则,当有新的告警规则如果满足 source_match或者定义的匹配规则,并且以发送的告警与新产生的告警中equal定义的标签完全相同,则启动抑制 机制,新的告警不会发送。

    例如,定义如下抑制规则:

    - source_match:
        alertname: NodeDown
        severity: critical
      target_match:
        severity: critical
      equal:
        - node

    例如当集群中的某一个主机节点异常宕机导致告警NodeDown被触发,同时在告警规则中定义了告警级别 severity=critical。由于主机异常宕机,该主机上部署的所有服务,中间件会不可用并触发报警。根据抑制规则 的定义,如果有新的告警级别为severity=critical,并且告警中标签node的值与NodeDown告警的相同,则说明新的告警是由NodeDown导致的,则启动抑制机制停止向接收器发送通知。

    5、实例:定义主机监控告警

    修改Prometheus配置文件prometheus.yml,添加以下配置:

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

    在目录/etc/prometheus/rules/下创建告警文件hoststats-alert.rules内容如下:

    groups:
       - name: hostStatsAlert
         rules:
         - alert: hostCpuUsageAlert
           expr: sum(avg without (cpu)(irate(node_cpu{mode!='idle'}[5m]))) by (instance) > 0.85
           for: 1m
           labels:
             severity: page
           annotations:
             summary: "Instance {{ $labels.instance }} CPU usgae high"
             description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"
         - alert: hostMemUsageAlert
           expr: (node_memory_MemTotal - node_memory_MemAvailable)/node_memory_MemTotal > 0.85
           for: 1m
           labels:
             severity: page
           annotations:
             summary: "Instance {{ $labels.instance }} MEM usgae high"
             description: "{{ $labels.instance }} MEM usage above 85% (current value: {{ $value }})"

    重启Prometheus后访问Prometheus UI http://127.0.0.1:9090/rules可以查看当前以加载的规则文件。

    展开全文
  • AlertManager实现webhook告警(使用Postman测试)

    千次阅读 多人点赞 2022-03-19 23:58:02
    AlertManager实现webhook告警(使用Postman测试),Alertmanager 主要用于接收 Prometheus 发送的告警信息,它支持丰富的告警通知渠道,而且很容易做到告警信息进行去重,降噪,分组等,是一款前卫的告警通知系统。...

    🍅程序员小王的博客:程序员小王的博客
    🍅 欢迎点赞 👍 收藏 ⭐留言 📝
    🍅 如有编辑错误联系作者,如果有比较好的文章欢迎分享给我,我会取其精华去其糟粕
    🍅java自学的学习路线:java自学的学习路线
    🍋相关学习资料及其参考文章:prometheus手册邮件和微信告警Alertmanager篇
    🍊 可以去个人博客网站查看本博客排版更清晰:AlertManager

    目录

    一、前言

    二、AlertManager简介

    1、AlertManager工作机制

    2、AlertManager的三个概念

    三、安装AlertManager

    1、下载AlertManager

    2、安装AlertManager

    3、启动Alertmanager

    4、查看Alertmanager运行状态

    四、AlertManager的参数

    五、Webhook配置

    1、初始配置详情:Webhook

    六、使用postman和Shell测试

    1、使用Shell发送测试

    2、通过postman测试

    七、最后的话

    一、前言

    公司想开发一个统一告警平台,需要AlertManager实现告警分析部分,然后就开始了我的AlertManager学习之路了🤣!

    然后AlterManager是Prometheus(普罗米修斯)的一部分,在 Prometheus 中告警分为两部分:

    • Prometheus 服务根据所设置的告警规则将告警信息发送给 Alertmanager。

    • Alertmanager 对收到的告警信息进行处理,包括去重,降噪,分组,策略路由告警通知。

    二、AlertManager简介

    Alertmanager 主要用于接收 Prometheus 发送的告警信息,它支持丰富的告警通知渠道,而且很容易做到告警信息进行去重,降噪,分组等,是一款前卫的告警通知系统。但是我们公司内部不使用Prometheus,只使用AlertManager.

    1、AlertManager工作机制

    Prometheus会根据配置的参数周期性的对警报规则进行计算, 如果满足警报条件,生产一条警报信息,将其推送到 Alertmanager 组件,Alertmanager 收到警报信息之后,会对警告信息进行处理,进行 分组 Group 并将它们通过定义好的路由 Routing 规则转到 正确的接收器 receiver, 比如 Email Slack 钉钉、企业微信 Robot(webhook) 企业微信 等,最终异常事件 WarningError通知给定义好的接收人,其中如钉钉是基于第三方通知来实现的,对于通知人定义是在钉钉的第三方组件中配置。

    • prometheus触发一条告警的过程:

    prometheus—>触发阈值—>超出持续时间—>alertmanager—>分组|抑制|静默—>媒体类型—>邮件|钉钉|微信等。

    2、AlertManager的三个概念

    (1)分组

    GroupingAlertmanager 把同类型的警报进行分组,合并多条警报到一个通知中。在生产环境中,特别是云环境下的业务之间密集耦合时,若出现多台 Instance 故障,可能会导致成千上百条警报触发。在这种情况下使用分组机制, 可以把这些被触发的警报合并为一个警报进行通知,从而避免瞬间突发性的接受大量警报通知,使得管理员无法对问题进行快速定位。

    • 举例:

    就是一个集群部署中,有一半的服务实例不再可以访问数据库,Prometheus中的警报规则配置为在每个服务实例无法与数据库通信时为其发送警报。结果,数百个警报被发送到Alertmanager。作为运维组或者相关业务组的开发人员,可能更关心的是在一个通知中就可以快速查看到哪些服务实例被本次故障影响了。为此,我们对服务所在集群或者服务警报名称的维度进行分组配置,把警报汇总成一条通知时,就不会受到警报信息的频繁发送影响了。

    (2)抑制

    Inhibition指当警报发出后,停止重复发送由此警报引发其他错误的警报的机制。

    • 举例:

    当警报被触发,通知整个集群不可达,可以配置Alertmanager忽略由该警报触发而产生的所有其他警报,这可以防止通知数百或数千与此问题不相关的其他警报。抑制机制可以通过Alertmanager的配置文件来配置。

    (3)静默

    Silences 提供了一个简单的机制,根据标签快速对警报进行静默处理;对传进来的警报进行匹配检查,如果接受到警报符合静默的配置,Alertmanager 则不会发送警报通知。

    • 注意:以上除了分组、抑制是在 Alertmanager 配置文件中配置,静默是需要在 WEB UI 界面中设置临时屏蔽指定的警报通知。

    三、安装AlertManager

    1、下载AlertManager

    [root@localhost soft]# yum -y install wget
    

    • 在linux下载,我选择的是 v0.21.0这个版本(命令中的 \代表换行,因为命令太长可以使用 \换行)

    [root@localhost soft]# wget https://github.com   \
                           /prometheus/alertmanager/releases/download/  \
                           v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz   \
    

    • 下载途中报错,请重新下载即可

    2、安装AlertManager

    • 直接解压

    [root@localhost soft]# tar xvf alertmanager-0.21.0.linux-amd64.tar.gz
    

    • 移动到/usr/apps下面

    mv /usr/soft/alertmanager-0.21.0.linux-amd64 /usr/apps/alertmanager
    

    • AlertManager的目录结构

    ├── alertmanager
    │   
    ├── alertmanager.yml
    ├──  amtool  
    ├── LICENSE
    ├── NOTICE
    
    

    • 查看版本信息

    [root@localhost alertmanager]# /usr/apps/alertmanager/alertmanager --version
    

    3、启动Alertmanager

    [root@localhost alertmanager]# ./alertmanager --config.file=alertmanager.yml
    

    4、查看Alertmanager运行状态

    四、AlertManager的参数

    参数描述
    --config.file="alertmanager.yml"指定Alertmanager配置文件路径
    --data.retention=120h历史数据保留时间,默认为120h
    --alerts.gc-interval=30m警报gc之间的间隔
    --web.external-url=WEB.EXTERNAL-URL外部可访问的Alertmanager的URL(例如Alertmanager是通过nginx反向代理)
    --web.route-prefix=WEB.ROUTE-PREFIXwen访问内部路由路径,默认是 --web.external-url
    --web.listen-address=":9093"监听端口,可以随意修改
    --web.get-concurrency=0并发处理的最大GET请求数,默认为0
    --web.timeout=0web请求超时时间
    --cluster.listen-address="0.0.0.0:9094"集群的监听端口地址。设置为空字符串禁用HA模式
    --cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS配置集群通知地址
    --cluster.gossip-interval=200ms发送条消息之间的间隔,可以以增加带宽为代价更快地跨集群传播。
    --cluster.peer-timeout=15s在同级之间等待发送通知的时间
    --log.level=info自定义消息格式 [debug, info, warn, error]
    --log.format=logfmt日志消息的输出格式: [logfmt, json]
    --version显示版本号

    五、Webhook配置

    [root@localhost alertmanager]# vim alertmanager.yml
    

    1、初始配置详情:Webhook

      ## 1.Alertmanager 配置文件
       global:
         resolve_timeout: 5m
         
      ## 2.route:路由分组
       route:
       #(1)用于分组聚合,对告警通知按标签(label)进行分组,将具有相同标签或相同告警名称(alertname)的告警通知聚合在一个组,然后作为一个通知发送。
       #   如果想完全禁用聚合,可以设置为group_by: [...]
         group_by: ['alertname']  #报警分组
        #(2)当一个新的告警组被创建时,需要等待'10s'后才发送初始通知。
        #    这样可以确保在发送等待前能聚合更多具有相同标签的告警,最后合并为一个通知发送。
         group_wait: 10s 
        #(3)当第一次告警通知发出后,在新的评估周期(interval:间隔)内又收到了该分组最新的告警
        #    则需等待'10s'时间后,开始发送为该组触发的新告警,可以简单理解为,group就相当于一个通道(channel)。
         group_interval: 10s
        #(4)告警通知成功发送后,若问题一直未恢复,需再次重复发送的间隔。
         repeat_interval: 1h
        #(5)配置告警消息接收者,与下面配置的对应。例如常用的 email、wechat、slack、webhook 等消息通知方式。
        #   Webhook:比如你的好友发了一条朋友圈,后端将这条消息推送给所有其他好友的客户端,就是 Webhook 的典型场景。    
         receiver: 'web.hook'
        #(6)这里还可以加入子路由
          -routes:  
           receiver: 'wechat'
           match:  # 通过标签去匹配这次告警是否符合这个路由节点;也可以使用  match_re 进行正则匹配
           severity: Disaster  # 标签severity为Disaster时满足条件,使用wechat警报
    
     ##3.配置报警信息接收者信息。
      receivers:
      #(1)警报接收者名称
      - name: 'web.hook'
        webhook_configs:
      # (2)webhook的路径
        - url: 'http://127.0.0.1:5001/'
      # (3)抑制规则配置,当存在与另一组匹配的警报(源)时,抑制规则将禁用与一组匹配的警报(目标)。
      inhibit_rules:
        - source_match:
            severity: 'critical'
          target_match:
            severity: 'warning'
          equal: ['alertname', 'dev', 'instance']
    

    (1)Route用来设置报警的分发策略。

    Prometheus的告警先是到达alertmanager的根路由(route),alertmanager的根路由不能包含任何匹配项,因为根路由是所有告警的入口点。

    (2)receiver:接收器

          用来处理那些没有匹配到任何子路由的告警(如果没有配置子路由,则全部由根路由发送告警),即缺省接收器。告警进入到根route后开始遍历子route节点,如果匹配到,则将告警发送到该子route定义的receiver中,然后就停止匹配了。因为在route中continue默认为false,如果continue为true,则告警会继续进行后续子route匹配。如果当前告警仍匹配不到任何的子route,则该告警将从其上一级(匹配)route或者根route发出(按最后匹配到的规则发出邮件)。

    (3)无注释版本,可直接使用

       global:
         resolve_timeout: 5m
       
       route:
         group_by: ['alertname']
         group_wait: 10s
         group_interval: 10s
         repeat_interval: 1h
         receiver: 'web.hook'
      receivers:
      - name: 'web.hook'
        webhook_configs:
        - url: 'http://127.0.0.1:5001/'
      inhibit_rules:
        - source_match:
            severity: 'critical'
          target_match:
            severity: 'warning'
          equal: ['alertname', 'dev', 'instance']
    

    六、使用postman和Shell测试

    1、使用Shell发送测试

    (1)新建Shell 脚本

    #!/usr/bin/env bash
    alerts_message='[
      {
        "labels": {
           "alertname": "磁盘已满",
           "dev": "sda1",
           "instance": "实例1",
           "msgtype": "testing"
         },
         "annotations": {
            "info": "程序员小王提示您:这个磁盘sda1已经满了,快处理!",
            "summary": "请检查实例示例1"
          }
      },
      {
        "labels": {
           "alertname": "磁盘已满",
           "dev": "sda2",
           "instance": "实例1",
           "msgtype": "testing"
         },
         "annotations": {
            "info": "程序员小王提示您:这个磁盘sda2已经满了,快处理!",
            "summary": "请检查实例示例1",
            "runbook": "以下链接http://test-url应该是可点击的"
          }
      }
    ]'
    
    

    (2)发送测试

    • 通过http进行测试

    [root@localhost ~]# curl -XPOST -d"$alerts_message" http://127.0.0.1:9093/api/v1/alerts
    

    • 测试结果

    2、通过postman测试

    • postman的使用攻略,可以参考我原来发的博客:[postman接口测试工具的使用攻略]

    • 我们将使用PostMan模拟Prometheus向AlertManager发送告警,然后用我们自已写的程序接收AlertManager发出来的通知。

    • 本文中,我们的测试主要来验证AlertManager中Group的机制,以及的三个配置参数的效果:group_waitgroup_intervalrepeat_interval

    (1)测试选择post,然后输入http://ip/api/v2/alerts

    (2)选择json格式

    • json

    [
      {
        "labels": {
           "alertname": "系统连续崩溃,已经出现雪崩状况!",
           "dev": "sda1",
           "instance": "实例1",
           "msgtype": "testing"
         },
         "annotations": {
            "info": "程序员小王提示您:这个系统雪崩了,快处理!",
            "summary": "请检查实例示例1"
          }
      },
      {
        "labels": {
           "alertname": "管理系统损坏",
           "dev": "sda2",
           "instance": "实例1",
           "msgtype": "testing"
         },
         "annotations": {
            "info": "程序员小王提示您:电子商务管理系统中订单,仓库模块已经雪崩,快处理!",
            "summary": "请检查实例示例1",
            "runbook": "以下链接http://192.168.5.128:9093/api/v2/alerts应该是可点击的"
          }
      }
    ]
    

    (3)测试成功

    • 返回1代表成功

    • 查看页面

    七、最后的话

    AlertManager实现webhook告警(使用Postman测试),主要讲述了原始的配置及测试,但是在公司使用主要还是要借助于AlertManager实现email,钉钉,微信告警,这样开发人员才能快速上手处理,所以后续,将在明后两天写出
    

    🥕AlertManager实现邮件告警相关配置
    🪀AlertManager实现微信告警相关配置
    🔴后续如果有时间会出一篇:AlertManager实现钉钉告警

    • 写这篇博客码字不易,因为alertmanager目前在网上资料较少,这这篇博客花了一天的时间,如果您感觉这篇文章对您有帮助,需要你帮我点个一键三连💞,也算是对我小小的鼓励!❤️

    • pdf版本或者.md版本文件下载地址:https://download.csdn.net/download/weixin_44385486/85005835

    展开全文
  • sweetalert.zip

    2017-08-21 19:27:08
    里面包含sweetalert js 和css
  • 简单的alert计算.rar简单的alert计算.rar简单的alert计算.rar简单的alert计算.rar简单的alert计算.rar简单的alert计算.rar
  • SweetAlert2

    2016-12-27 14:28:17
    SweetAlert2是我将升级后的代码进行整合,方便开发者使用!
  • sweetalert2.zip

    2018-04-13 20:07:01
    sweetalert2完整包。SweetAlert是一个JS插件,能够完美替代JS自带的alert弹出框,并且功能强大,设计优美。
  • jquery 改写Alert弹出框样式

    热门讨论 2014-01-14 09:50:11
    js jquery alert样式
  • 文章目录1 先验证smtp信息是否正确2 配置alertmanager配置文件并触发告警3 解决 smtp.plainAuth failed: wrong host name4 解决 dial tcp 127.0.0.1:5001: connect: connection refused5 解决 配置文件不对应的问题6...

    0 说明

    环境说明

    本文的alertmanager和对应的prometheus都是容器化部署的 使用的是k8s(华为云的CCE)
    为了减少篇幅,下文中基础操作,诸如重启pod、修改configmap、修改deployment等已略去

    通读并理解如下报错和解决办法 需要读者具备如下基础知识

    - 容器化基础
      - 编辑configmap deployment的指令
      - 其他基础指令 如 get / logs / delete
      - 理解并可以配置deployment的volume
      - docker的基础命令
    - python基础 
    - prometheus监控基础
    

    阅读说明

    如下的过程记录了我遇到alertmanager不发送告警邮件后完整的排查过程,也贴有详细的报错信息,如果有时间可以通读,没时间可以直接在全文搜索你自己的报错信息,快速定位问题。

    1 先验证smtp信息是否正确

    我用如下脚本验证了我自己的smtp信息ok 是可以发送邮件的

    #!/usr/bin/python3
    import smtplib
    from email.mime.text import MIMEText
    
    # 第三方 SMTP 服务
    mail_host = "smtp.xxx.com"  # SMTP服务器
    mail_user = "xxx@xxx.com"  # 邮箱地址
    mail_pass = "smtp_password"  # smtp服务器授权密码
    
    sender = "xxx@xxx.com"  # 邮箱地址
    receivers = ['xxx.yyy@zzz.com']  # 接收人邮箱
    
    
    content = 'Python Send Mail !'
    title = 'Python SMTP Mail Test'  # 邮件主题
    message = MIMEText(content, 'plain', 'utf-8')  # 内容, 格式, 编码
    message['From'] = "{}".format(sender)
    message['To'] = ",".join(receivers)
    message['Subject'] = title
    
    try:
        smtpObj = smtplib.SMTP_SSL(mail_host, 465)  # 启用SSL发信, 端口一般是465
        smtpObj.login(mail_user, mail_pass)  # 登录验证
        smtpObj.sendmail(sender, receivers, message.as_string())  # 发送
        print("mail has been send successfully.")
    except smtplib.SMTPException as e:
        print(e)
    

    2 配置alertmanager配置文件并触发告警

    配置好之后如下所示

    在这里插入图片描述
    如下图 可以看到alertmanager已经有告警了
    在这里插入图片描述
    但是确实么有收到邮件 于是去看alertmanager的报错 信息如下 一直说我wrong host name 我看了配置文件 确实没有配错

    level=info ts=2022-03-23T02:16:37.525994901Z caller=main.go:155 msg="Starting Alertmanager" version="(version=0.11.0, branch=HEAD, revision=30dd0426c08b6479d9a26259ea5efd63bc1ee273)"
    level=info ts=2022-03-23T02:16:37.527762474Z caller=main.go:156 build_context="(go=go1.9.2, user=root@3e103e3fc918, date=20171116-17:43:56)"
    level=info ts=2022-03-23T02:16:37.539722557Z caller=main.go:293 msg="Loading configuration file" file=/etc/alertmanager/config.yml
    level=info ts=2022-03-23T02:16:37.545130043Z caller=main.go:368 msg=Listening address=:9093
    level=error ts=2022-03-23T02:17:30.639020284Z caller=notify.go:302 component=dispatcher msg="Error on notify" err="*smtp.plainAuth failed: wrong host name"
    level=error ts=2022-03-23T02:17:30.639083975Z caller=dispatch.go:266 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="*smtp.plainAuth failed: wrong host name"
    level=error ts=2022-03-23T02:17:40.639237563Z caller=notify.go:302 component=dispatcher msg="Error on notify" err="*smtp.plainAuth failed: wrong host name"
    level=error ts=2022-03-23T02:17:40.639277826Z caller=dispatch.go:266 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="*smtp.plainAuth failed: wrong host name"
    level=error ts=2022-03-23T02:17:50.639425498Z caller=notify.go:302 component=dispatcher msg="Error on notify" err="*smtp.plainAuth failed: wrong host name"
    

    3 解决 smtp.plainAuth failed: wrong host name

    在这个博客(https://blog.csdn.net/qq_22543991/article/details/88356928)中 看到了解决办法 于是参考下 把自己的镜像也升级到v0.16.1

    在这里插入图片描述
    再次查看alertmanager 又有新的问题 它说连接127.0.0.1:5001失败 单我的deployment根本没有5001端口

    level=info ts=2022-03-23T02:34:41.389240548Z caller=main.go:177 msg="Starting Alertmanager" version="(version=0.16.1, branch=HEAD, revision=571caec278be1f0dbadfdf5effd0bbea16562cfc)"
    level=info ts=2022-03-23T02:34:41.389681827Z caller=main.go:178 build_context="(go=go1.11.5, user=root@3000aa3a06c5, date=20190131-15:05:40)"
    level=info ts=2022-03-23T02:34:41.394313005Z caller=cluster.go:161 component=cluster msg="setting advertise address explicitly" addr=192.168.0.180 port=9094
    level=info ts=2022-03-23T02:34:41.487475426Z caller=cluster.go:632 component=cluster msg="Waiting for gossip to settle..." interval=2s
    level=info ts=2022-03-23T02:34:41.589155367Z caller=main.go:334 msg="Loading configuration file" file=/etc/alertmanager/alertmanager.yml
    level=info ts=2022-03-23T02:34:41.592776954Z caller=main.go:428 msg=Listening address=:9093
    level=info ts=2022-03-23T02:34:43.487799541Z caller=cluster.go:657 component=cluster msg="gossip not settled" polls=0 before=0 now=1 elapsed=2.000116631s
    level=info ts=2022-03-23T02:34:51.488389096Z caller=cluster.go:649 component=cluster msg="gossip settled; proceeding" elapsed=10.00071002s
    level=error ts=2022-03-23T02:35:30.636722077Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="Post http://127.0.0.1:5001/: dial tcp 127.0.0.1:5001: connect: connection refused"
    level=error ts=2022-03-23T02:35:30.636795707Z caller=dispatch.go:177 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="Post http://127.0.0.1:5001/: dial tcp 127.0.0.1:5001: connect: connection refused"
    level=error ts=2022-03-23T02:35:40.636944614Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="Post http://127.0.0.1:5001/: dial tcp 127.0.0.1:5001: connect: connection refused"
    level=error ts=2022-03-23T02:35:40.637012969Z caller=dispatch.go:177 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="Post http://127.0.0.1:5001/: dial tcp 127.0.0.1:5001: connect: connection refused"
    

    容器中的端口如下 是9093 9094

    [root@xxxxx ~]# kubectl -n monitoring exec alertmanager-7d5c68df6f-4dzl7 -it -- sh
    /alertmanager $ netstat -anpt | grep LISTEN
    tcp        0      0 :::9093                 :::*                    LISTEN      1/alertmanager
    tcp        0      0 :::9094                 :::*                    LISTEN      1/alertmanager
    

    于是怀疑是不是新换的镜像 用了新的配置文件 新的配置文件中有5001端口

    4 解决 dial tcp 127.0.0.1:5001: connect: connection refused

    先查看下我自己的deployment中配置文件的设置 如下 配置文件是/etc/alertmanager/config.yml

            volumeMounts:
            - mountPath: /etc/localtime
              name: localtime
              readOnly: true
            - mountPath: /etc/alertmanager/config.yml
              name: alertmanager-conf
              readOnly: true
              subPath: config.yml
    

    再去alertmanager容器所在的主机上 查看下对应容器的信息 如下

    [root@yyyyy ~]# docker ps | grep alertmanager
    2d074e0ab797        rancher/prom-alertmanager                             "/bin/alertmanager -…"   3 minutes ago       Up 3 minutes                            k8s_container-0_alertmanager-7d5c68df6f-4dzl7_monitoring_bcc9065c-52d6-4ee0-ab12-9e8bbe2b09a8_0
    003d2bba2ebd        cce-pause:3.1                                         "/pause"                 4 minutes ago       Up 4 minutes                            k8s_POD_alertmanager-7d5c68df6f-4dzl7_monitoring_bcc9065c-52d6-4ee0-ab12-9e8bbe2b09a8_0
    [root@yyyyy ~]# docker inspect 2d074e0ab797
    [
        {
            "Id": "2d074e0ab797ba255fdeedbf68502fc82913ed24bc65704a835da9bd2345ff92",
            "Created": "2022-03-23T02:34:40.824251211Z",
            "Path": "/bin/alertmanager",
            "Args": [
                "--config.file=/etc/alertmanager/alertmanager.yml",
                "--storage.path=/alertmanager"
            ],
            "State": {
                "Status": "running",
                "Running": true,
    ...... 后边的内容省略
    

    从上边的信息可以看出 新的镜像用的配置文件是/etc/alertmanager/alertmanager.yml 配置文件不对应 没有读取到正确的配置

    5 解决 配置文件不对应的问题

    配置文件既然不对应 那就想办法让它对应 这里采用的方法是 改自己挂载的configmap

    更改deployment 将挂载volume的地方进行修改 修改为如下

            volumeMounts:
            - mountPath: /etc/localtime
              name: localtime
              readOnly: true
            - mountPath: /etc/alertmanager/alertmanager.yml
              name: alertmanager-conf
              readOnly: true
              subPath: alertmanager.yml
    

    更改后 pod启动失败 报错如下 说Are you trying to mount a directory onto a file

      Type     Reason                 Age                From                   Message
      ----     ------                 ----               ----                   -------
      Normal   Scheduled              36s                                       Successfully assigned monitoring/alertmanager-5c4664d45f-gq9fn to 172.16.0.216
      Normal   SuccessfulMountVolume  35s (x2 over 36s)  kubelet, 172.16.0.216  Successfully mounted volumes for pod "alertmanager-5c4664d45f-gq9fn_monitoring(b78797dd-7ce8-44fc-b23b-a8bb0c3b5e7e)"
      Warning  FailedStart            35s                kubelet, 172.16.0.216  Error: failed to start container "container-0": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"rootfs_linux.go:61: mounting \\\"/mnt/paas/kubernetes/kubelet/pods/b78797dd-7ce8-44fc-b23b-a8bb0c3b5e7e/volume-subpaths/alertmanager-conf/container-0/1\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/8f3de32f6add251b9b040c16fc26a86d653c850550f075d05831459b8fb17a83/rootfs\\\" at \\\"/var/lib/docker/devicemapper/mnt/8f3de32f6add251b9b040c16fc26a86d653c850550f075d05831459b8fb17a83/rootfs/etc/alertmanager/alertmanager.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
      Warning  FailedStart            34s                kubelet, 172.16.0.216  Error: failed to start container "container-0": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"rootfs_linux.go:61: mounting \\\"/mnt/paas/kubernetes/kubelet/pods/b78797dd-7ce8-44fc-b23b-a8bb0c3b5e7e/volume-subpaths/alertmanager-conf/container-0/1\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/c5d9b7e08e9d64bcda975995bf695b2292bf9745e5f5d8644e591dd7ee83fdc1/rootfs\\\" at \\\"/var/lib/docker/devicemapper/mnt/c5d9b7e08e9d64bcda975995bf695b2292bf9745e5f5d8644e591dd7ee83fdc1/rootfs/etc/alertmanager/alertmanager.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
      Normal   Pulled                 20s (x3 over 35s)  kubelet, 172.16.0.216  Container image "rancher/prom-alertmanager:v0.16.1" already present on machine
      Normal   SuccessfulCreate       20s (x3 over 35s)  kubelet, 172.16.0.216  Created container container-0
      Warning  FailedStart            19s                kubelet, 172.16.0.216  Error: failed to start container "container-0": Error response from daemon: OCI runtime create failed: container_linux.go:330: starting container process caused "process_linux.go:381: container init caused \"rootfs_linux.go:61: mounting \\\"/mnt/paas/kubernetes/kubelet/pods/b78797dd-7ce8-44fc-b23b-a8bb0c3b5e7e/volume-subpaths/alertmanager-conf/container-0/1\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/04bb9820df0c996854cebfbe4606cc0fc56e9791b83af3183ea5ca70f56374c4/rootfs\\\" at \\\"/var/lib/docker/devicemapper/mnt/04bb9820df0c996854cebfbe4606cc0fc56e9791b83af3183ea5ca70f56374c4/rootfs/etc/alertmanager/alertmanager.yml\\\" caused \\\"not a directory\\\"\"": unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
      Warning  BackOffStart           6s (x2 over 34s)   kubelet, 172.16.0.216  the failed container exited with ExitCode: 127
      Warning  BackOffStart           6s (x2 over 34s)   kubelet, 172.16.0.216  Back-off restarting failed container
    

    看了眼alertmanager的configmap 原来文件名字不对应

    apiVersion: v1
    data:
      config.yml: |
        global:
          resolve_timeout: 5m
          smtp_from: xxx.yyy@cccc.com
          smtp_smarthost: 'smtp.xxx.com:465'
          smtp_auth_username: xxx.yyy@cccc.com
          smtp_auth_password: smtp_password
          smtp_require_tls: false
        route:
          receiver: email
          group_by:
          - alertname
          - kubernetes_namespace
          - kubernetes_pod
          group_wait: 10s
          group_interval: 10s
          repeat_interval: 1h
        inhibit_rules:
    

    6 解决configmap跟挂载文件名不对应的问题

    修改alertmanager的configmap 将配置文件吗修改为alertmanager.yml

    apiVersion: v1
    data:
      alertmanager.yml: |
        global:
          resolve_timeout: 5m
          smtp_from: xxx.yyy@cccc.com
          smtp_smarthost: 'smtp.xxx.com:465'
          smtp_auth_username: aaa.bbb@ccc.com
          smtp_auth_password: smtp_password
          smtp_require_tls: false
        route:
          receiver: email
          group_by:
          - alertname
          - kubernetes_namespace
          - kubernetes_pod
          group_wait: 10s
          group_interval: 10s
          repeat_interval: 1h
        inhibit_rules:
    

    重启alertmanager pod

    一看又失败了 信息如下 原来是yaml中volumes的地方没修改过来

      Warning  FailedMount  25s                  kubelet, 172.16.0.216  Unable to attach or mount volumes: unmounted volumes=[alertmanager-conf], unattached volumes=[localtime alertmanager-conf default-token-z4nz6]: timed out waiting for the condition
      Warning  FailedMount  20s (x9 over 2m28s)  kubelet, 172.16.0.216  MountVolume.SetUp failed for volume "alertmanager-conf" : configmap references non-existent config key: config.yml
    

    修改完之后如下 再次重启alertmanager

    
    

    更改完毕后 看到了Running
    在这里插入图片描述
    alertmanager页面告警如下
    在这里插入图片描述

    也收到了告警邮件
    在这里插入图片描述

    展开全文
  • AlertManager 告警信息

    千次阅读 2021-12-15 17:00:56
    在 prometheus 中定义你的监控规则,即配置一个触发器,某个值超过了设置的阈值就触发告警, prometheus 会推送当前的告警规则到 alertmanager,alertmanager 收到了会进行一系列的流程处理,然后发送到接收人手里。...
  • Alertmanager 告警详解

    千次阅读 2021-02-03 10:48:10
    • 部署Alertmanager • 配置Prometheus与Alertmanager通信 • 在Prometheus中创建告警规则 • 告警状态 部署Alertmanager 要实现告警通过altermanager这个组件完成的,必须告诉普罗米修斯altermanager是...
  • Bootstrap系列之警告框(Alert

    千次阅读 2022-05-28 09:18:52
    目录1、示例1.1、链接的颜色1.2、添加其它内容1.3、关闭警告框2、通过 JavaScript 触发行为2.1、触发器2.2、本组件所暴露的方法2.3、本组件所暴露的事件后记 ...如需内联一个关闭按钮,请使用 警告框(alert)的
  • 解释以下为什么不使用grafana配和预警,因为grafana比较局限,而且在使用模板的情况下是不允许进行Alert预警的,所以最后我才直接采用了Prometheus下的alertmanager报警,放弃了grafana。 目录Prometheus下的alert...
  • 清除alert log

    千次阅读 2021-05-01 12:00:37
    1.手动删除log_××.xml,...2.使用ADRCI 工具也可以删除alert log。1.在OS中手动删除log_××.xml[oracle@dbserver alert]$ lltotal 4-rw-r----- 1 oracle oinstall 307 Aug 9 08:59 log.xml[oracle@dbserver al...
  • Prometheus Alertmanager告警模板

    千次阅读 2020-12-19 22:50:16
    关于Alertmanager的告警模板,我们以上篇《Prometheus配置和使用Alertmanager发送告警至企业微信》的模板为例,对其做个说明, [root@centos74 home]# cat /usr/local/prometheus/alertmanager/wechat.tmpl {{ ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,169,901
精华内容 467,960
关键字:

alert