Linux云计算——docker 告警（六）

一、docker 告警1.1 告警机制与 Alertmanager 核心功能1.1.1 告警逻辑与触发条件布尔值判断机制告警规则基于PromQL 表达式如 up 0 或 cpu_usage 80进行布尔值判断。当表达式返回 true 时触发告警false 则不告警。组件职责分离Prometheus Server 负责计算和判断告警条件Alertmanager 负责处理告警通知的发送。1.1.2 Alertmanager 高级特性分组与去重Grouping Deduplication为避免级联告警淹没核心问题Alertmanager 会将同一故障源如上游 Nginx 宕机导致下游 30 个 Java 节点不可达合并为单条通知。抑制Inhibition当某个组件故障时抑制依赖于该组件的其他服务的告警避免产生大量冗余告警干扰。静默Silence用于在计划内维护如割接、升级期间临时屏蔽告警防止误报。1.2 Prometheus 告警架构与规则配置1.2.1 告警架构与状态流转核心组件交互逻辑数据流遵循 Exporter - Prometheus - Alertmanager - 钉钉DingTalk的路径其中 Alertmanager 负责告警通知的分发。告警生命周期状态告警规则存在三种状态Inactive正常、Pending等待就绪如等待1分钟阈值以及 Firing异常触发。1.2.2 告警规则文件编写布尔值表达式触发机制规则基于 PromQL 表达式如 up 0进行判断结果为 true 时触发告警并支持设置持续时间如 for 1m。自定义标签与消息模板支持在规则中定义独立的标签Labels用于分类并通过 Annotations 字段定义告警消息的主题Summary和详情Description支持变量引用如 {{ $value }}。1.3 钉钉集成与接口原理1.3.1 钉钉机器人配置安全设置与密钥获取在钉钉群添加自定义机器人时必须选择“加签”安全设置并记录生成的 Webhook URL 和 Secret 密钥用于后续鉴权。接口标准对齐强调了接口Interface的本质是标准化的访问入口URL双方必须遵循一致的协议标准如 HTTPS才能实现功能调用。1.3.2 组件配置文件修改DingTalk插件配置修改 configure.yaml 文件填入 Webhook URL 和 Secret支持配置多个群组接收告警。Alertmanager 路由配置修改 alertmanager.yml 文件定义接收者Receivers为 Webhook并将 URL 指向 DingTalk 插件监听的端口如 8060。1.4 全链路测试与验证1.4.1 服务启动与配置检查服务启动顺序需依次启动DingTalk 插件、Alertmanager 和 Prometheus确保组件间网络可达。配置路径校验重点排查了 Prometheus 配置文件中rule_files路径的正确性避免因路径错误导致规则文件无法加载。1.4.2 故障注入与告警触发模拟故障场景手动停止 Node Exporter 服务使 up 指标变为 0触发告警条件。状态流转观察在 Prometheus UI 中观察告警状态从 Inactive 变为 Pending最终变为 Firing。消息接收确认最终在钉钉群中成功接收到由机器人发送的告警消息验证了全链路功能正常。1.5 钉钉告警链路配置逻辑1.5.1 核心组件与职责划分组件架构系统由Prometheus、Alertmanager 和 DingTalk三个核心组件构成。职责分工Prometheus 负责制定告警规则Alertmanager 负责发送告警DingTalk 负责具体的 API 接口对接。1.5.2 端口与网络连接端口映射Prometheus 通过随机端口连接 Alertmanager 的 9093 端口Alertmanager 连接 DingTalk 的 8060 端口。连接验证建议使用 netstat -atp 命令检查 Alertmanager 的连接状态以确保组件间通信正常。1.5.3 配置文件对接逻辑Prometheus配置需在 prometheus.yml 中开启与 Alertmanager 的连接并通过 rule_files 指向告警规则文件路径。Alertmanager配置在 alertmanager.yml 中定义告警路由指定接收告警的 Webhook URL即钉钉群机器人地址。DingTalk配置在 config.yml 中配置 Webhook 地址及加签密钥确保消息能正确发送至指定钉钉群。二、PromQL 语句编写与函数应用2.1 CPU 使用率计算逻辑指标获取利用 node_cpu_seconds_total{modeidle} 获取 CPU 空闲时间通过 [1m] 时间范围选择器获取过去 1 分钟的数据。速率计算使用 irate 函数计算时间序列的瞬时增长率将计数器类型数据转换为百分比形式的空闲率。聚合运算使用 avg 函数计算所有 CPU 核心的平均空闲率再通过 by (instance) 按节点进行分组实现按节点维度的独立运算。最终转换通过 100 - avg(...) 的运算逻辑将空闲率转换为 CPU 使用率压力值。2.2 常用函数汇总聚合函数重点掌握 sum求和、avg平均值、count计数、max最大值、min最小值。排序函数topk 用于获取排名前 N 的样本数据常用于排行榜或异常排查。速率函数rate 和 irate用于计算时间序列的增长率其中 irate 适用于快速变化的计数器。2.3 监控指标体系与面试应答2.3.1 SRE 四大黄金指标延迟Latency请求发出到响应的时间如 Nginx 的请求处理耗时。流量Traffic系统接收的请求量通常以 QPS每秒请求数或 TPS每秒事务数衡量。错误Errors请求处理失败的比率如 HTTP 5xx 状态码的比例。饱和度Saturation系统资源的使用程度如 CPU、内存、磁盘 IO 的利用率。2.3.2 其他关键监控维度系统资源文件描述符数量、Socket 连接数、僵尸/孤儿进程数量。网络与磁盘网络平均延迟、磁盘饱和度。三、Prometheus 监控体系核心指标与实战3.1 Prometheus监控的三大维度及四种核心指标类型明确了业务监控的侧重点3.1.1 监控维度分层系统与服务层监控涵盖服务存活状态、容器运行状态、CPU/内存使用率等基础指标确保底层环境稳定。中间件与数据库监控重点监控MySQL慢查询日志数量、平均查询延迟、线程队列等待数量及连接数等关键性能指标。业务层与API监控关注API接口请求失败数量、HTTP状态码分布、请求延迟P99/P95以及业务特定指标如网盘业务的平均下载速率。3.1.2 指标类型详解Counter计数器适用于单调递增的指标如请求总数、错误数量主要用于计算速率。Gauge仪表盘适用于可增可减的瞬时值如内存使用率、CPU负载、队列长度。Histogram直方图用于分析数据分布统计样本值分布情况常用于网络请求延迟分析。Summary摘要直接存储分位数数据如P99、P95适用于响应时间等指标的百分比统计。3.2 Prometheus 架构与运维实战3.2.1 架构选型与扩展单机与集群方案单机Prometheus建议监控节点数控制在200台左右超过此规模需采用联邦集群架构通过分片采集解决性能瓶颈。存储方案演进在小规模场景下使用Prometheus自带TSDB即可当数据量巨大时建议后端存储迁移至OpenTSDB。3.2.2 日常运维工作流标签治理与文档整理强调通过标签Label区分不同业务和环境如dev/prod避免告警误报需整理资源文档并推动开发规范标签。可视化与告警闭环负责在Grafana中新增业务指标图表并配置Alertmanager进行告警路由分发确保告警信息准确送达。3.3 Docker 与自动化部署规划3.3.1 技术栈演进容器编排进阶进入KubernetesK8s核心作为容器编排。操作系统升级为适配K8s环境改用Rocky Linux 9.7内核5.x版本。3.3.2 自动化部署要求Ansible批量管理学员需掌握Ansible工具实现一次性批量部署三个虚拟机内的Docker服务。脚本编写规范强调在编写部署脚本时需注重可读性与可维护性要求学员具备通过AI辅助生成脚本并自行验证的能力。总结#dockerfile 举例 Dockerfile DROM centos:7 ADD nginx-vts-exporter-0.10.3.linux-amd64.tar.gz /opt COPY nginx.conf /etc/nginx/ COPY start.sh “/” WORKDIR nginx-1.18.0/ RUN ./configure --prefix/usr/local/nginx \ --usernginx \ --groupnginx \ --with-http_stub_status_module \ --add-module/usr/local/nginx-module-vts make make install expose 80 expose 9913 cmd [/start.sh] #/bin/bash nohup /opt/nginx-vts-exporter-0.10.3/nginx-vts-exporter nohup /usr/local/nginx/sbin/nginx -g daemon off 阿里云 创建容器集群ack托管(k8s)进行管理的时候会默认添加监控arms(prometheus )和日志sls(elk)的组件 docker prometheus elk grafana 看板---》 prometheus 数据库9090 告警通知 1、判断是否需要告警 是prometheus自己的功能prometheus可以通过写promql语句条件判断的表达式来判断返回值是否为true以此 来判断是否需要告警例如布尔值判断 返回值”0“或”非0“ up 0 #判断的是当返回值为true的时候触发告警如果是false 则不告警 100 -avg(irate(node_cpu_seconds_total{modeidle}[1m])) by (instance)* 100 80 PromQL语句描述的内容是cpu的使用率 2、告警信息通知给管理人员 altermanager 组件来完成的 exporter 采集数据暴露数据 --》prometheus pull 数据 --》prometheus 告警逻辑判断 ---》alertmanager 告警通知 ---》dingtalk插件 钉钉 告警规则有3个状态 SEC3f6ce52d5a77fed654abfae68b1558e55fee8dfd53d41f184cae9ef7fe1a9cd3 https://oapi.dingtalk.com/robot/send?access_token2b49d94ea9e19d04a92b4af361dff27473e27df5aba9f0db347e14689120269a webhook 接口地址 钉钉告警 钉钉告警 服务对接alertmanger发送告警 dingtalk负责具体的api对接 prometheus告警规则的制定 端口的对接prometheus 9090 --》alertmanager 9093 --》dingstalk 8060 配置文件对接 prometheus.yml (开启alertmanger 组件的连接、指向rules告警规则文件的路径 alertmanager.yml--》告警路由 指向dingtalk的webhook位置钉钉群中机器人的webhhook位置 dingtalk: 在钉钉群创建机器人选择加签的验证方式、复制webhook 的api位置 同步到config.yml文件的webhook1中 docker 把alertmanger 和dingtalk 做出来 100 -avg(irate(node_cpu_seconds_total{modeidle}[1m])) by (instance)* 100 运算cpu的压力值 1 - cpu空闲值 / 总计 node_cpu_seconds_total{modeidle}[1m] 指标cpu统计的过去1min内空闲值的样本数据4次 #irate 函数 速率运算 irate(node_cpu_seconds_total{modeidle}[1m]) 所有节点所有cpu的空闲率 {cpu0, instance192.168.110.129:9100, jobnodes, modeidle} 0.9945340621249336 {cpu0, instance192.168.110.130:9100, jobnodes, modeidle} 0.9980000000000776 {cpu0, instance192.168.110.131:9100, jobnodes, modeidle} 0.9994665955461796 {cpu1, instance192.168.110.129:9100, jobnodes, modeidle} 0.992534328756127 #avg 平均数运算cpu空闲率 avg(irate(node_cpu_seconds_total{modeidle}[1m])) #所有节点的所有cpu 平均的压力值 100 - avg(irate(node_cpu_seconds_total{modeidle}[1m]))*100 #分组,以节点为单位进行分组 by (instance) #得到 每个节点1min前的平均压力值 100 - avg(irate(node_cpu_seconds_total{modeidle}[1m]))by (instance) *100 {instance192.168.110.129:9100} 0.9166666666654493 {instance192.168.110.130:9100} 0.14999999999417923 {instance192.168.110.131:9100} 0.3666666666686069 1、promql语句怎么写你得说出来 100 -avg(irate(node_cpu_seconds_total{modeidle}[1m])) by (instance)* 100 话术由内向外介绍 比如cpu使用率promql ① 总体使用1-cpu使用率 方式得出需要样本数据 ② 使用node_cpu_seonds_total cpu空闲值的指标再使用[1m]表示时间区间 ③ 然后先使用irate做速率运算、再做avg 聚合运算得出平均空闲率 ④ 再用by instance 进行分组 ⑤ 最后 1 - 数据 就等于压力值 2、promql中你用过哪些聚合函数 sum(): min() max() avg() count() topk() 排序 排名 irate() 速率运算 3、prometheus 监控哪些具体的指标 ① 系统 延迟 流量 每秒请求数QPS、每秒事务数TPS 错误 状态码 4xx/5xx 系列 饱和度饱和度是指系统资源的使用情况。包括但不限于CPU、内存、磁盘 I/O、网络带宽等。 fd 文件描述符的使用率 socket 连接数量 文件打开数 僵尸、孤儿进程数量 网络平均延迟 服务 服务的存活健康状态 容器的运行状态 服务的一些个性化监控比如mysql 慢查询日志数量 平均查询延迟 队列的长度 线程任务平均处理时长 socket 连接的平均延迟 http/https 状态码 业务 api 接口请求失败的数量 api 请求延迟 线索平均处理时长最大处理时长 和实际业务 PromQL 的指标类型 ① Counter计数器单调递增的计数器适用于请求数、错误数等。 - 常用函数rate()、irate()、increase() ② Gauge可增可减的仪表盘适用于内存使用率、CPU 使用率等。 - 常用函数delta()、predict_linear() ③ Histogram累积直方图用于分析数据分布。 - 常用函数histogram_quantile() ④ Summary直接存储百分位数的摘要适用于延迟时间、响应大小等。