1.初级Kubernetes技术如何学习？
2.2020-08-25
3.小公司也可以0成本构建统一的源码告警管理体系
4.MySQL数据库的警告问题，怎么解决
5.oracle数据库的源码警告日志如何查看
6.如何在prometheus产生告警时自动执行某个脚本文件

初级Kubernetes技术如何学习？

       一、初级

       1. 了解Kubernetes 基础架构与核心组件功能

       2. 了解Docker基本概念和用法

       3. 理解Docker与Kubernetes的源码基本关系

       4. 能够安装、部署与配置 Kubernetes 集群

       5. 熟练使用 kubectl 命令操作各种 Kubernetes 资源对象，源码了解基本概念和使用方法

       6. 能够在 Kubernetes 上部署、源码运行、源码陈雨墨最新指标源码管理工作负载并了解其调度算法

       7. 能够使用 Service、源码Ingress 等访问工作负载

       8. 深入理解Pod相关的源码配置及使用

       9. 了解Kubernetes生态相关工具及其作用

       二、中级

       1. 理解Kubernetes的源码资源管理，资源分配、源码优先级、源码QoS等

       2. 能够使用 Flannel、源码Calico、源码Macvlan 等常用 CNI 插件配置集群网络

       3. 能够排查 Kubernetes 集群系统组件、源码网络、源码日志、监控告警与存储的故障

       4. 能够使用 EFK 搭建容器日志系统

       5. 能够使用 Prometheus、AlertManager 等搭建容器监控告警系统

       6. 能够配置应用使用持久性存储并了解 Ceph、NFS、GlusterFS 等常见存储工作原理

       7. 应用生命周期管理

       8. 理解Kubernetes容器调度的基本流程和使用方法

       9. Kubernetes集群日常维护

       . 理解并使用Kubernetes的用户认证及授权体系（RBAC）

       . 理解弹性伸缩（HPA）的基本原理

       三、高级

       1. 理解Kubernets核心组件的工作原理，并能够进行问题定位及提供解决方案

       2. 掌握Kubernetes的admission 控制器，audit，镜像gc，Pod驱赶行为等相关工作原理

       3. 可以扩展和定制Kubernetes调度器

       4. 能够用 Operator/CRD 对 Kubernetes 作定制化开发

       5. 理解 Kubernetes 多可用区/多集群管理模式

       6. 灵活掌握Kubernetes的扩展机制，可以按需定制，包括CNI、CSI、Ingress、自定义控制器等扩展定制

       7. 可以解决日志、监控等核心组件的问题定位以及进行性能调优

       四、专家

       1. 能够对 Kubernetes 集群、操作系统、镜像、应用做安全加固

       2. 能够排查 Linux 内核、Docker 容器运行时故障

       3. 能够基于 Kubernetes、Jenkins等工具构建云原生DevOps方案

       4. 理解Kubernetes生态主要工具的作用及优缺点，可以在不同场景下灵活运用相关工具并确定最 佳实施方案

       5. 具备对大规模集群支持的相关经验，包括架构设计、性能调优等稳定性保障

       6. 理解Kubernetes社区运作模式，能够为社区提供PR

       7. 理解Kubernetes各组件源代码，并能排查、paython源码分析相关问题

       作为国内领 先的全栈云原生技术服务提供商，时速云特别推出了Kubernetes培训课程，对于刚接触Kubernetes技术、企业计划使用容器及Kubernetes集群、以及计划考取CKA证书的人群会是一个不错的选择。

--

       Prometheus 实现邮件告警（Prometheus+Alertmanager+QQ邮箱或者网易邮箱，目前测试过这两种邮箱都可以发送告警邮件）

        Prometheus实现邮件告警原理如下：

        Prometheus官方有一个附带的中间件：alertmanager，通过设置rules规则和路由转发可以实现邮件告警，前提是你需要有一个可以发送邮件的邮件服务端（可以自建或者使用互联网公司提供的免费邮箱）

        告警原理图

       Prometheus完整架构图

        我之前得出的错误结论如下：

        推荐直接在虚拟机操作系统上直接安装Prometheus和Alertmanager，不推荐其中任何一方在容器中运行，因为测试过在容器中运行Prometheus和alertmanager，结果出现如下错误情况

        第一种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus却提示节点依然在线？有时候却能够正常显示节点掉线跌机，生成告警发送邮件

        第二种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，但是没有发送邮件，我手动恢复node-exporter后，告警解除，邮件能正常发送邮件提示告警已经解除。。。。

        第三种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，正常成功发送邮件，我手动恢复node-exporter后，告警解除，邮件没有发送出来。。。。

        以上三种情况之前经常出现，当时第一步以为是自己设置的scrape_interval不合理导致的，结果调试几次，问题没有解决，第二步以为是自己的服务器时间没有做到精确同步，然后我去设置和阿里云的ntp服务器同步，结果问题依然没有解决，第三步，换个方向，把alertmanager迁移到虚拟机操作系统上安装运行，问题解决！

       åŒ—京时间是GMT+8小时，有些同志的时间可能是UTC的，但是如果是在要求不太十分精确的情况下，UTC时间是刚刚好等于GMT时间

        为了避免时区的混乱，prometheus所有的组件内部都强制使用Unix时间，对外展示使用GMT时间。

        要改时区有两个办法

        1 .修改源码，重新编译。

       2. 使用 docker 运行 Prometheus，挂载本地时区文件

        docker run --restart always -e TZ=Asia/Shanghai --hostname prometheus --name prometheus-server -d -p : -v /data/prometheus/server/data:/prometheus -v /data/prometheus/server/conf/prometheus.yml:/etc/prometheus/prometheus.yml -u root prom/prometheus:v2.5.0

        正文开始

        安装alertmanager

        容器安装方式：

        docker run -d --name alertmanager -p : -v /usr/local/Prometheus/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml prom/alertmanager:latest

        先在宿主机/usr/local/Prometheus下创建一个文件夹alertmanager，然后在文件夹里创建alertmanager.yml配置文件，待会才能映射到alertmanager容器里的/etc/alertmanager目录下

       global：全局配置

           resolve_timeout: 问题解决的超时时间

           smtp_from: 发送告警邮件的邮箱账号

           smtp_smarthost: é‚®ç®± SMTP 服务地址,这里是以QQ邮箱为例，也可以用网易邮箱，这个和我之前设置zabbix邮件告警时的配置一样

           smtp_auth_username: 如果没有设置邮箱别名，那就是账户名

           smtp_auth_password:  邮箱的授权码，不是 账户密码，你可以在QQ邮箱或者网易邮箱网页端设置，开启 POP3/SMTP æœåŠ¡æ—¶ä¼šæç¤ºï¼Œå’Œé…ç½®zabbix邮件告警的时候几乎一样

           smtp_require_tls: 是否使用 tls，根据环境不同，来选择开启和关闭。如果提示报错 email.loginAuth failed: Must issue a STARTTLS command first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。

       templates： 告警模板目录，可以不编写模板，有默认模板

            Subject: '{ { template "email.default.subject" . }}'

            html: '{ { template "email.default.html" . }}'

       route：报警的分发设置

            group_by：分组

            group_wait: 分组等待时间

            group_interval: 5m 每组时间间隔

            repeat_interval: m 重复间隔

            receiver: 接收方式，请注意！这里的名字要对应下面receivers中的任何一个名字，不然会报错，这里其实就是选择方式，有邮箱，企业微信，wehook，victorops等等

       receivers：接受方式汇总，即告警方式汇总

        例子：

        receivers:

        - name:'default-receiver' 

        email_configs:

        - to:'whiiip@.com'    

          html: '{ { template "alert.html" . }}'    

          headers: { Subject: "[WARN] 报警邮件test"}

       inhibit_rules:   æŠ‘制规则

        当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。

        包括源匹配和目标匹配

        alertmanager官方是这样说的

        Inhibition

        Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.

        Example:  An alert is firing that informs that an entire cluster is not reachable. Alertmanager can be configured to mute all other alerts concerning this cluster if that particular alert is firing. This prevents notifications for hundreds or thousands of firing alerts that are unrelated to the actual issue.

        Inhibitions are configured through the Alertmanager's configuration file.

        当存在与另一组匹配器匹配的警报（源）时，禁止规则会使与一组匹配器匹配的警报（目标）静音。目标警报和源警报的equal列表中的标签名称都必须具有相同的标签值。

        在语义上，缺少标签和带有空值的标签是同一件事。因此，如果equal源警报和目标警报都缺少列出的所有标签名称，则将应用禁止规则。

        为了防止警报禁止自身，与规则的目标和源端 都 匹配的警报不能被警报（包括其本身）为真来禁止。但是，我们建议选择目标匹配器和源匹配器，以使警报永远不会同时匹配双方。这很容易进行推理，并且不会触发此特殊情况。

        接着是规则rules

       ä¸è§£é‡Šäº†ï¼Œè‡ªå·±ç ”究官方文档

       alertmanager的非容器安装方式是

         wget /prometheus/alertmanager/releases/download/v0..0/alertmanager-0..0.linux-amd.tar.gz

        tar xf alertmanager-0..0.linux-amd.tar.gz

       mv alertmanager-0..0.linux-amd /usr/local/alertmanager

       vim /usr/lib/systemd/system/alertmanager.service

       [Unit]

       Description=alertmanager

        Documentation=/prometheus/alertmanager

        After=network.target

        [Service]

        Type=simple

        User=root

        ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

        Restart=on-failure

        [Install]

        WantedBy=multi-user.target

        Alertmanager 安装目录下默认有 alertmanager.yml 配置文件，可以创建新的配置文件，在启动时指定即可。

        其余方式和上面一样

        接着是Prometheus，我之前的博客里有写了容器安装和非容器安装的方法，自己去翻阅

        然后是在prometheus.yml里修改相关配置

        首先去掉alertmanager的注释，改成IP加你设置的端口号，默认是

       æŽ¥ç€åœ¨rule_files: 下面写下规则文件的绝对路径，可以是具体文件名，也可以是*，也可以分几级文件，*默认是全部匹配

       æŽ¥ç€æ˜¯è¢«ç›‘控项的设置，这里设置完成可以在Prometheus网页里的targets里看得到

        请注意，这里设置的参数名字要和rule规则中设置的参数名字一模一样，否则你的prometheus服务会无法启动，然后报错

        如果不在特定的job下设置scrape_interval（优先级高于全局）,则默认采用gobal下的scrape_interval

       æœ€åŽæ¨¡æ‹ŸèŠ‚点掉线，手动关闭node-exporter或者Cadvisor

        docker stop node-exporter 或者容器ID

        docker stop cadvisor æˆ–者容器ID

        或者把up{ { job='prometheus'}} == 1 设置成1，反向设置，不用关掉服务，就可以看看告警成不成功

       è¯´æ˜Žä¸€ä¸‹ Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

        Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。

        Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。

        Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

       æ²¡æœ‰é…ç½®å‘Šè­¦æ¨¡æ¿æ—¶çš„默认告警格式是这样的

       èŠ‚点恢复后邮件告知是这样的

       å†™äº†æ¨¡æ¿åŽæ˜¯è¿™æ ·çš„

       è¿˜è¦é‡æ–°æ˜ å°„模板文件夹路径到alertmanager容器里的相对路径，然后重启alertmanager，当然，如果目录下没有模板文件，则不显示

       å‘Šè­¦æ¨¡æ¿

       åœ¨alertmanager.yml中修改相关设置

        重启alertmanager

        docker restart alertmanager

        最终效果不是很好

小公司也可以0成本构建统一的告警管理体系

       小公司如何0成本构建统一的告警管理体系？

       在探讨这一问题时，我们首先回顾了某国企互联网公司在监控告警体系上的建设实践。然而，使用Prometheus与AlertManager虽能方便监控相关组件，但仅能借助Dingtalk进行消息报警，无法实现短信、电话等告警升级功能。

       由此，小公司构建统一告警管理体系的关键在于解决这一痛点。解决方案是通过二次开发DingTalk告警组件，集成钉钉、短信、电话，并开放统一的API。这使得告警信息能够直接调用，增强告警系统的灵活性。

       接下来，我们详细探讨了使用Go语言编写的Prometheus-webhook-dingtalk组件。此组件能够对接Alertmanager，将告警信息发送至钉钉群，但缺乏短信、电话功能。因此，我们通过修改源代码，新增了短信、电话接口，并在web/dingtalk目录下创建了sms.go、call.go文件。在sms.go中调用短信接口时，需要添加自己的短信appKey、appSecret、templateID。同时，对call.go中的代码进行调整，替换阿里云的ALIBABA_CLOUD_ACCESS_KEY_ID、ACCESS_KEY_SECRET。swan源码

       通过执行go run cmd/prometheus-webhook-dingtalk/main.go命令，我们成功启动了新增的短信、电话webhook，实现与Alertmanager的对接。为了进一步统一管理，我们还在sms.go中添加了smsap，以便更方便地调用短信功能。同样，call.go也进行了相应的优化，确保电话功能的调用更加流畅。

       总结而言，小公司通过二次开发现有告警组件，集成多种告警方式，实现了0成本构建统一的告警管理体系。这一策略不仅提高了告警系统的全面性，还增强了其响应速度和处理效率，为企业的日常运营提供了坚实的技术保障。

MySQL数据库的警告问题，怎么解决

       ‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 h，排除第三条。那问题出在什么地方呢？

       分析

       下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的watch源码产生需要两方面的配合：

       metric 数据

       告警规则

       将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

       看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

       不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

       请点击输入描述

       请点击输入描述

       首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

       其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

       capacity（默认值为 ）：控制缓冲队列的大小，

       maxBatchSize（默认值为 ）：控制单次发送到 AlertManager 的最大告警数

       了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的opao源码告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 s 内推送了大约 次，即平均 s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*s = m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

       thanos_alert_queue_alerts_dropped_total

       thanos_alert_queue_alerts_pushed_total

       thanos_alert_queue_alerts_popped_total

       通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

       解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn，实体上的告警规则数量分别有 y1、y2、y3、...、yn，那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize >= (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

       注意事项

       上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

       ‍‍

oracle数据库的警告日志如何查看

       ‍测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 h，排除第三条。那问题出在什么地方呢？

       分析

       下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：

       metric 数据

       告警规则

       将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：

       看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。

       不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：

       请点击输入描述

       请点击输入描述

       首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。

       其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：

       capacity（默认值为 ）：控制缓冲队列的大小，

       maxBatchSize（默认值为 ）：控制单次发送到 AlertManager 的最大告警数

       了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 s 内推送了大约 次，即平均 s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*s = m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：

       thanos_alert_queue_alerts_dropped_total

       thanos_alert_queue_alerts_pushed_total

       thanos_alert_queue_alerts_popped_total

       通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。

       解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn，实体上的告警规则数量分别有 y1、y2、y3、...、yn，那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize >= (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。

       注意事项

       上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。

       ‍‍

如何在prometheus产生告警时自动执行某个脚本文件

       在使用prometheus进行监控时，为了在产生告警时实现自动化操作，如执行特定脚本文件，可以结合webhook功能实现这一需求。webhook提供了一种将告警事件转换为可执行操作的机制，本文将详细介绍如何配置webhook，以及如何通过执行脚本文件自动处理告警信息。

       在prometheus和alertmanager的体系中，告警机制主要通过规则配置文件（rule.yaml）来定义告警条件。当监控到指标值异常时，alertmanager将向指定的webhook发送告警信息。通过配置webhook，我们可以在接收到告警信息的同时，触发自定义脚本执行，实现更精细化的告警处理。

       为了搭建webhook服务，可以访问其官方GitHub仓库（github.com/adnanh/webhook）获取相关文档。对于Ubuntu系列的环境，可以通过apt命令轻松安装webhook服务；其他操作系统环境下，需要通过编译源码的方式安装webhook，并确保服务在端口监听。

       搭建webhook服务后，通过编辑配置文件，配置webhook的访问路径和相关参数。在配置完成后，重启服务以确保配置生效。通过访问http://{ webhook_ip}:{ port}/hooks/{ webhook_id}（默认端口为）的URL，可以验证webhook是否正常工作。在接收到告警信息后，webhook将执行预先配置的脚本文件（如/root/test.sh），并记录执行结果，确保脚本执行的可靠性和可追踪性。

       为了扩展webhook的功能，可以修改其默认端口以适应不同环境需求。通过调整webhook服务的配置文件，添加端口参数，例如将端口更改为，确保服务重启后端口变更生效。

       为了实现特定告警内容的自动化处理，如将Ceph状态异常时的健康详细信息发送到企业微信机器人，可以整合prometheus、alertmanager和webhook。在配置prometheus告警规则和alertmanager告警接收时，确保两者能够无缝对接。通过编写自定义脚本（如/root/trigger.sh），在接收到告警信息时执行特定操作，例如执行命令获取详细信息并发送至企业微信机器人。

       在执行过程中，模拟业务故障（如停止Ceph的osd服务）可以验证告警机制的正确性和脚本执行的有效性。通过检查企业微信机器人收到的消息，确保告警内容准确无误，并且在故障恢复时也能收到相应的恢复告警。

       通过上述配置和实践，webhook不仅简化了告警处理流程，还提供了高度定制化的解决方案，使得在接收到告警时可以执行一系列自动化操作。这不仅提高了问题响应的效率，还增强了监控系统的灵活性和实用性。