1. 从告警风暴到数据洞察为什么我要做这个统计脚本做运维的同行大概都有过这种体验凌晨两点被一通电话叫醒打开手机一看某个核心业务的告警在半小时内刷了上百条等你手忙脚乱处理完第二天复盘的时候却发现自己根本说不清楚——这个月到底哪些告警最频繁哪些主机是“告警钉子户”哪些时间段是故障高发期Zabbix自带的报表功能不是不能用但要么维度不够灵活要么导出格式不趁手想做个自定义的周报月报靠手点页面能点到怀疑人生。这就是我做这个Python统计脚本的出发点。核心思路很直接把Zabbix数据库里的告警数据捞出来用Python做二次加工生成一份能直接拿去做汇报、做容量规划、做告警治理的统计报表。它解决的不是“监控有没有告警”的问题而是“告警数据能不能变成决策依据”的问题。适合谁参考有一定Python基础、日常跟Zabbix打交道的运维工程师、SRE以及需要定期输出监控运营报告的技术管理者。哪怕你只是刚接触Zabbix不久只要跟着思路走也能把这套东西跑起来。我先把结论摆在这儿这套脚本的价值不在于代码有多复杂而在于它把“告警”从一个被动响应的事件变成了一个可以主动分析的数据资产。下面我会从整体设计、核心细节、实操落地、踩坑排查几个维度把整个项目掰开揉碎讲清楚。2. 整体设计思路与方案选型拆解2.1 为什么选择直连数据库而不是调APIZabbix提供了比较完整的API理论上通过API也能拿到告警数据。我一开始也试过走API这条路但很快就放弃了原因有三个。第一API的告警查询接口在数据量大时性能堪忧。Zabbix的event.get接口每次返回条数有限制要翻页拉取一个中等规模的环境一个月动辄几十万条事件靠API翻页拉取光是网络往返的时间就够泡杯茶了。第二API返回的数据结构是嵌套的JSON字段冗余多解析起来还要额外做一层清洗。第三也是最关键的——我需要的很多统计维度比如按主机分组、按触发器分组、按时间段聚合本质上都是SQL擅长的聚合操作直接在数据库层面用GROUP BY搞定比拉回来在Python里循环高效得多。所以最终方案定为Python通过数据库驱动直连Zabbix的MySQL/PostgreSQL库用SQL做聚合查询Python负责调度、加工和输出。这个分工很清晰数据库干它擅长的聚合Python干它擅长的格式化和自动化。注意直连生产数据库一定要用只读账号并且尽量在从库上执行避免统计查询拖垮主库影响监控写入。2.2 统计维度的设计逻辑做统计最怕的是“为了统计而统计”堆一堆没人看的数字。我在设计维度时遵循一个原则每个维度都要能回答一个具体的运维问题。具体拆成了这么几类按主机维度回答“哪些机器告警最多”。这是做硬件更换、配置优化、下线老旧设备的直接依据。按触发器维度回答“哪类问题反复出现”。比如某个磁盘空间触发器天天报说明要么阈值不合理要么扩容没跟上。按告警级别维度回答“告警的严重程度分布”。如果Warning占了一大半说明阈值设置过于敏感需要做告警降噪。按时间段维度回答“什么时候是故障高发期”。这个对排班和值班人力安排很有参考价值。按告警状态维度回答“有多少告警被真正处理了”。未恢复的告警数量是衡量运维响应质量的硬指标。这几个维度不是拍脑袋想的是我在实际做告警治理时一个个问出来的需求。你可以根据自己的场景增减但建议至少保留主机、触发器、级别这三个它们的信息量最大。2.3 技术栈与依赖选择技术栈上我没有追求花哨选的都是最稳妥的组合组件选型选择理由数据库驱动PyMySQL / psycopg2纯Python实现部署无编译依赖跨平台省心数据处理Pandas聚合、透视、排序一把梭省去大量手写循环报表输出openpyxl生成带格式的Excel方便直接发给非技术同事定时调度系统crontab简单可靠不引入额外的调度框架配置管理YAML数据库连接、统计周期等参数外置改配置不用动代码有人可能会问为什么不用SQLAlchemy这类ORM。我的考虑是这个项目的SQL都是为统计定制的聚合查询用ORM反而要把SQL拆成别扭的链式调用可读性下降。直接写SQL配合参数化查询防注入既直观又高效。Pandas在这里的作用主要是把查询结果做透视表pivot_table和二次排序比纯Python字典操作简洁太多。2.4 数据流向的整体串联整个脚本的数据流是这样的读取YAML配置 → 建立数据库连接 → 按维度执行多条聚合SQL → 结果集转DataFrame → 透视与排序 → 写入Excel多Sheet → 可选发送邮件通知。每一步都是独立的函数方便单独调试和复用。比如你只想跑主机维度的统计直接调用对应的函数就行不用把整个流程走一遍。这种模块化设计在后期加维度时特别省事加一个新统计就是加一个函数加一条SQL的事。3. 核心细节解析与实操要点3.1 Zabbix告警数据的表结构认知要把统计做对首先得搞清楚Zabbix的告警数据到底存在哪几张表里。这是整个项目的地基地基没打牢后面统计出来的数字全是错的。核心涉及两张表events和triggers再关联hosts和functions、items。events表是告警事件的流水账每一条告警的产生和恢复都在这里。关键字段有这么几个eventid是自增主键source标识事件来源0是触发器事件这是我们要的object标识对象类型0是触发器objectid关联到具体的触发器IDclock是事件发生的Unix时间戳value表示事件状态1是问题产生0是问题恢复severity是告警级别0到5分别对应未分类、信息、警告、一般严重、严重、灾难acknowledged表示是否被确认。triggers表存的是触发器定义triggerid是主键description是触发器名称priority是级别。通过events.objectid triggers.triggerid就能把事件和触发器关联起来。主机信息要通过functions和items表绕一下triggers通过functions.triggerid关联functions.itemid关联到itemsitems.hostid再关联到hosts。这条链路有点长但没办法Zabbix的表结构就是这么设计的。实际写SQL时如果嫌关联太多影响性能可以先只统计到触发器维度主机维度单独用另一条SQL查。提示不同Zabbix版本的字段名可能略有差异比如老版本events表可能没有某些字段。动手前先用DESCRIBE events;确认一下表结构别照搬。3.2 时间范围与时间戳的处理Zabbix所有时间字段存的都是Unix时间戳秒级整数这对做时间段统计其实是个好事因为可以直接用整数比较效率高。但要注意时区问题——数据库里存的是UTC时间戳展示时要转成本地时间。我的处理方式是在Python里用datetime计算好统计周期的起止时间戳作为参数传给SQL。比如统计最近7天就是now - 7*86400到now。这里有个细节now的取值要用数据库的当前时间还是Python的当前时间我建议用Python算好再传进去这样脚本在任意机器上跑统计口径都一致不会因为数据库服务器时区不同而漂移。时间段维度的统计稍微麻烦一点需要把时间戳按小时或按天分组。MySQL里可以用FROM_UNIXTIME(clock, %Y-%m-%d)把时间戳转成日期字符串再分组PostgreSQL里用to_timestamp(clock)配合date_trunc。这一步的写法因数据库而异我在代码里做了适配。3.3 告警级别的映射与中文展示Zabbix的severity字段是0到5的数字直接展示成数字没人看得懂。我在Python里建了一个映射字典SEVERITY_MAP { 0: 未分类, 1: 信息, 2: 警告, 3: 一般严重, 4: 严重, 5: 灾难 }这个映射在生成报表时统一套用保证所有Sheet里的级别展示一致。别小看这个细节报表是给人看的可读性直接决定了它会不会被真正使用。我见过太多技术报表因为全是数字和英文缩写最后躺在共享盘里吃灰。3.4 未恢复告警的识别逻辑“未恢复告警”是运维最关心的指标之一但它的识别逻辑有个坑。一条告警的产生和恢复是两条独立的events记录产生时value1恢复时value0它们的objectid触发器ID相同。要找出当前仍未恢复的告警逻辑是对每个触发器找到它最近一条事件如果这条事件的value1说明还没恢复。这个逻辑用SQL实现可以用子查询取每个触发器的最大eventid再判断其value。注意不能用clock取最大因为同一秒可能有多个事件用eventid更可靠它是严格递增的。SELECT e.objectid, t.description, e.clock, e.severity FROM events e JOIN triggers t ON e.objectid t.triggerid WHERE e.eventid IN ( SELECT MAX(eventid) FROM events WHERE source 0 AND object 0 GROUP BY objectid ) AND e.value 1 AND e.source 0 AND e.object 0;这条SQL是排查“僵尸告警”的利器跑出来的结果就是当前所有还挂着没恢复的问题。3.5 配置外置与参数化查询数据库连接信息、统计周期、输出路径这些都不应该硬编码在脚本里。我用一个YAML文件管理database: host: 127.0.0.1 port: 3306 user: readonly_user password: your_password dbname: zabbix report: days: 7 output_dir: ./reports top_n: 20top_n控制每个维度只展示前N名避免报表里塞几百行没人看。参数化查询这块所有用户输入或配置传入的值都用占位符绝不字符串拼接这是防SQL注入的基本功也是保护生产库的底线。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把环境搭起来。Python版本建议3.8以上太老的版本Pandas支持不好。依赖就四个一条命令搞定pip install pymysql pandas openpyxl pyyaml如果你用的是PostgreSQL把pymysql换成psycopg2-binary。装完之后建议先写个最简单的连接测试确认能连上数据库、能查到数据再往下做。我见过不少人一上来就写完整脚本结果跑不通排查半天发现是连接参数写错了白白浪费时间。4.2 数据库连接与查询封装连接这块我封装了一个上下文管理器保证连接用完一定关闭避免连接泄漏import pymysql import yaml from contextlib import contextmanager def load_config(pathconfig.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) contextmanager def get_connection(cfg): conn pymysql.connect( hostcfg[database][host], portcfg[database][port], usercfg[database][user], passwordcfg[database][password], databasecfg[database][dbname], charsetutf8mb4, cursorclasspymysql.cursors.DictCursor ) try: yield conn finally: conn.close()用DictCursor的好处是查询结果直接是字典列表转DataFrame时pd.DataFrame(rows)一行搞定不用手动映射字段名。4.3 各维度统计SQL的编写主机维度统计统计周期内每台主机的告警总数按数量倒序SELECT h.host AS hostname, COUNT(*) AS alert_count FROM events e JOIN triggers t ON e.objectid t.triggerid JOIN functions f ON t.triggerid f.triggerid JOIN items i ON f.itemid i.itemid JOIN hosts h ON i.hostid h.hostid WHERE e.source 0 AND e.object 0 AND e.value 1 AND e.clock %s AND e.clock %s GROUP BY h.host ORDER BY alert_count DESC LIMIT %s;这里只统计value1问题产生的事件因为恢复事件不算“告警次数”。clock的范围用参数传入LIMIT控制返回条数。触发器维度统计类似把GROUP BY换成t.description即可。级别维度则是GROUP BY e.severity。时间段维度用日期函数分组SELECT FROM_UNIXTIME(e.clock, %%Y-%%m-%%d %%H) AS hour_slot, COUNT(*) AS alert_count FROM events e WHERE e.source 0 AND e.object 0 AND e.value 1 AND e.clock %s AND e.clock %s GROUP BY hour_slot ORDER BY hour_slot;注意FROM_UNIXTIME里的%在Python的字符串格式化里要写成%%转义这是个容易踩的小坑。4.4 用Pandas做透视与二次加工SQL查出来的原始结果往往还需要二次加工。比如级别维度我想同时看到每个级别的数量和占比用Pandas几行就搞定import pandas as pd df pd.DataFrame(rows) df[级别名称] df[severity].map(SEVERITY_MAP) total df[alert_count].sum() df[占比] (df[alert_count] / total * 100).round(2).astype(str) % df df.sort_values(alert_count, ascendingFalse)占比这个指标特别有用一眼就能看出告警的集中度。如果某个级别占了70%以上那基本可以确定告警策略需要调整了。4.5 生成多Sheet的Excel报表最后用pd.ExcelWriter把所有维度的结果写进一个Excel文件每个维度一个Sheetoutput_path f{cfg[report][output_dir]}/zabbix_alert_report_{today}.xlsx with pd.ExcelWriter(output_path, engineopenpyxl) as writer: host_df.to_excel(writer, sheet_name按主机统计, indexFalse) trigger_df.to_excel(writer, sheet_name按触发器统计, indexFalse) severity_df.to_excel(writer, sheet_name按级别统计, indexFalse) timeline_df.to_excel(writer, sheet_name按时间段统计, indexFalse) unresolved_df.to_excel(writer, sheet_name未恢复告警, indexFalse)文件名带上日期方便归档和对比。如果你想让报表更美观可以在写完之后用openpyxl调整列宽、加表头样式但这是锦上添花先把数据跑对再说。4.6 定时任务配置脚本调通之后用crontab挂上定时执行。比如每天早上8点生成前一天的报表0 8 * * * /usr/bin/python3 /opt/scripts/zabbix_alert_report.py /var/log/zabbix_report.log 21日志重定向一定要加不然脚本报错了你都不知道。日志文件建议配合logrotate做轮转避免越积越大。4.7 一个完整的执行流程记录我把整个流程串一遍你照着走就行。第一步确认数据库表结构用DESCRIBE events;和DESCRIBE triggers;核对字段。第二步把配置填进YAML文件先用只读账号测试连接。第三步单独跑主机维度的SQL确认能查出数据且数字合理。第四步逐个维度验证每加一个维度就跑一次别一次性全写完再调。第五步生成Excel打开检查格式和内容。第六步挂crontab观察两天的日志确认稳定。这个顺序是我踩过坑之后总结的按部就班来出问题的概率最低。5. 常见问题与排查技巧实录5.1 统计数字对不上怎么办这是最常见的问题报表里的告警数和Zabbix页面显示的对不上。排查思路按这个顺序来先确认时间范围是否一致Zabbix页面默认可能用的是本地时间而你SQL里用的是UTC时间戳差了几个小时数字自然对不上。再确认source和object的过滤条件只统计触发器事件的话必须是source0 AND object0漏了这个条件会把自动发现等事件也算进去。最后确认value的过滤只算产生事件就是value1如果产生和恢复都算了数字会翻倍。5.2 查询太慢拖垮数据库数据量大的环境一条聚合SQL跑几分钟是常事。优化方向有几个一是给events表的clock字段加索引如果原本没有的话二是在从库上跑别碰主库三是缩小统计范围别一次查半年按周或按月分段查再汇总四是把LIMIT用上很多维度你只需要Top N没必要全量排序。5.3 中文乱码问题生成的Excel里中文变乱码八成是编码问题。数据库连接时charset要设成utf8mb4YAML文件读取时指定encodingutf-8写Excel时openpyxl默认就是UTF-8一般不会有问题。如果还是乱码检查一下数据库本身的字符集设置。5.4 常见问题速查表问题现象可能原因解决方向连接超时网络不通或防火墙拦截检查网络连通性和端口开放查询结果为空时间范围或过滤条件错误放宽条件逐步排查数字偏大未过滤source/object/value补全过滤条件数字偏小时间戳时区不一致统一用UTC时间戳计算Excel打不开文件被占用或写入中断检查是否有同名文件被打开脚本报KeyError配置项缺失或拼写错误核对YAML配置的键名5.5 几个我踩过的坑第一个坑是FROM_UNIXTIME的百分号转义。在Python字符串里写SQL%Y会被当成格式化占位符必须写成%%Y这个坑我调了半小时才反应过来。第二个坑是LIMIT的参数化有些数据库驱动不支持把LIMIT的值作为参数传入得用字符串拼接这时候一定要确保这个值是整数类型转换过的不能直接拼用户输入。第三个坑是Pandas的map遇到映射字典里没有的值会返回NaN如果Zabbix版本新增了级别映射字典没更新报表里就会出现空值所以映射字典要留个默认值兜底。提示脚本第一次上生产前建议先用一个小的测试环境或者手动构造几条数据验证逻辑别直接对着生产库跑万一SQL写错了把库拖慢影响的是整个监控系统。5.6 报表怎么用才有价值最后说点经验层面的东西。报表生成出来只是第一步关键是怎么用。我的做法是每周固定花半小时看这份报表重点看三个变化告警总数是升是降、Top主机有没有新面孔、未恢复告警有没有积压。如果某个主机连续几周都在Top榜上那就该安排人去现场看看了可能是硬件老化也可能是业务量涨了需要扩容。报表的价值不在于数字本身而在于它帮你把注意力引导到真正需要关注的地方。这套脚本我用了挺长时间中间根据实际需求改过好几版比如加了环比对比、加了告警确认率统计你可以根据自己的场景慢慢迭代先跑起来再优化。 
长河君 · 2026/10/14 16:37:23 · 阅读 1.2k Zabbix告警数据统计脚本：Python直连数据库生成多维度报表
1. 从告警风暴到数据洞察为什么我要做这个统计脚本做运维的同行大概都有过这种体验凌晨两点被一通电话叫醒打开手机一看某个核心业务的告警在半小时内刷了上百条等你手忙脚乱处理完第二天复盘的时候却发现自己根本说不清楚——这个月到底哪些告警最频繁哪些主机是“告警钉子户”哪些时间段是故障高发期Zabbix自带的报表功能不是不能用但要么维度不够灵活要么导出格式不趁手想做个自定义的周报月报靠手点页面能点到怀疑人生。这就是我做这个Python统计脚本的出发点。核心思路很直接把Zabbix数据库里的告警数据捞出来用Python做二次加工生成一份能直接拿去做汇报、做容量规划、做告警治理的统计报表。它解决的不是“监控有没有告警”的问题而是“告警数据能不能变成决策依据”的问题。适合谁参考有一定Python基础、日常跟Zabbix打交道的运维工程师、SRE以及需要定期输出监控运营报告的技术管理者。哪怕你只是刚接触Zabbix不久只要跟着思路走也能把这套东西跑起来。我先把结论摆在这儿这套脚本的价值不在于代码有多复杂而在于它把“告警”从一个被动响应的事件变成了一个可以主动分析的数据资产。下面我会从整体设计、核心细节、实操落地、踩坑排查几个维度把整个项目掰开揉碎讲清楚。2. 整体设计思路与方案选型拆解2.1 为什么选择直连数据库而不是调APIZabbix提供了比较完整的API理论上通过API也能拿到告警数据。我一开始也试过走API这条路但很快就放弃了原因有三个。第一API的告警查询接口在数据量大时性能堪忧。Zabbix的event.get接口每次返回条数有限制要翻页拉取一个中等规模的环境一个月动辄几十万条事件靠API翻页拉取光是网络往返的时间就够泡杯茶了。第二API返回的数据结构是嵌套的JSON字段冗余多解析起来还要额外做一层清洗。第三也是最关键的——我需要的很多统计维度比如按主机分组、按触发器分组、按时间段聚合本质上都是SQL擅长的聚合操作直接在数据库层面用GROUP BY搞定比拉回来在Python里循环高效得多。所以最终方案定为Python通过数据库驱动直连Zabbix的MySQL/PostgreSQL库用SQL做聚合查询Python负责调度、加工和输出。这个分工很清晰数据库干它擅长的聚合Python干它擅长的格式化和自动化。注意直连生产数据库一定要用只读账号并且尽量在从库上执行避免统计查询拖垮主库影响监控写入。2.2 统计维度的设计逻辑做统计最怕的是“为了统计而统计”堆一堆没人看的数字。我在设计维度时遵循一个原则每个维度都要能回答一个具体的运维问题。具体拆成了这么几类按主机维度回答“哪些机器告警最多”。这是做硬件更换、配置优化、下线老旧设备的直接依据。按触发器维度回答“哪类问题反复出现”。比如某个磁盘空间触发器天天报说明要么阈值不合理要么扩容没跟上。按告警级别维度回答“告警的严重程度分布”。如果Warning占了一大半说明阈值设置过于敏感需要做告警降噪。按时间段维度回答“什么时候是故障高发期”。这个对排班和值班人力安排很有参考价值。按告警状态维度回答“有多少告警被真正处理了”。未恢复的告警数量是衡量运维响应质量的硬指标。这几个维度不是拍脑袋想的是我在实际做告警治理时一个个问出来的需求。你可以根据自己的场景增减但建议至少保留主机、触发器、级别这三个它们的信息量最大。2.3 技术栈与依赖选择技术栈上我没有追求花哨选的都是最稳妥的组合组件选型选择理由数据库驱动PyMySQL / psycopg2纯Python实现部署无编译依赖跨平台省心数据处理Pandas聚合、透视、排序一把梭省去大量手写循环报表输出openpyxl生成带格式的Excel方便直接发给非技术同事定时调度系统crontab简单可靠不引入额外的调度框架配置管理YAML数据库连接、统计周期等参数外置改配置不用动代码有人可能会问为什么不用SQLAlchemy这类ORM。我的考虑是这个项目的SQL都是为统计定制的聚合查询用ORM反而要把SQL拆成别扭的链式调用可读性下降。直接写SQL配合参数化查询防注入既直观又高效。Pandas在这里的作用主要是把查询结果做透视表pivot_table和二次排序比纯Python字典操作简洁太多。2.4 数据流向的整体串联整个脚本的数据流是这样的读取YAML配置 → 建立数据库连接 → 按维度执行多条聚合SQL → 结果集转DataFrame → 透视与排序 → 写入Excel多Sheet → 可选发送邮件通知。每一步都是独立的函数方便单独调试和复用。比如你只想跑主机维度的统计直接调用对应的函数就行不用把整个流程走一遍。这种模块化设计在后期加维度时特别省事加一个新统计就是加一个函数加一条SQL的事。3. 核心细节解析与实操要点3.1 Zabbix告警数据的表结构认知要把统计做对首先得搞清楚Zabbix的告警数据到底存在哪几张表里。这是整个项目的地基地基没打牢后面统计出来的数字全是错的。核心涉及两张表events和triggers再关联hosts和functions、items。events表是告警事件的流水账每一条告警的产生和恢复都在这里。关键字段有这么几个eventid是自增主键source标识事件来源0是触发器事件这是我们要的object标识对象类型0是触发器objectid关联到具体的触发器IDclock是事件发生的Unix时间戳value表示事件状态1是问题产生0是问题恢复severity是告警级别0到5分别对应未分类、信息、警告、一般严重、严重、灾难acknowledged表示是否被确认。triggers表存的是触发器定义triggerid是主键description是触发器名称priority是级别。通过events.objectid triggers.triggerid就能把事件和触发器关联起来。主机信息要通过functions和items表绕一下triggers通过functions.triggerid关联functions.itemid关联到itemsitems.hostid再关联到hosts。这条链路有点长但没办法Zabbix的表结构就是这么设计的。实际写SQL时如果嫌关联太多影响性能可以先只统计到触发器维度主机维度单独用另一条SQL查。提示不同Zabbix版本的字段名可能略有差异比如老版本events表可能没有某些字段。动手前先用DESCRIBE events;确认一下表结构别照搬。3.2 时间范围与时间戳的处理Zabbix所有时间字段存的都是Unix时间戳秒级整数这对做时间段统计其实是个好事因为可以直接用整数比较效率高。但要注意时区问题——数据库里存的是UTC时间戳展示时要转成本地时间。我的处理方式是在Python里用datetime计算好统计周期的起止时间戳作为参数传给SQL。比如统计最近7天就是now - 7*86400到now。这里有个细节now的取值要用数据库的当前时间还是Python的当前时间我建议用Python算好再传进去这样脚本在任意机器上跑统计口径都一致不会因为数据库服务器时区不同而漂移。时间段维度的统计稍微麻烦一点需要把时间戳按小时或按天分组。MySQL里可以用FROM_UNIXTIME(clock, %Y-%m-%d)把时间戳转成日期字符串再分组PostgreSQL里用to_timestamp(clock)配合date_trunc。这一步的写法因数据库而异我在代码里做了适配。3.3 告警级别的映射与中文展示Zabbix的severity字段是0到5的数字直接展示成数字没人看得懂。我在Python里建了一个映射字典SEVERITY_MAP { 0: 未分类, 1: 信息, 2: 警告, 3: 一般严重, 4: 严重, 5: 灾难 }这个映射在生成报表时统一套用保证所有Sheet里的级别展示一致。别小看这个细节报表是给人看的可读性直接决定了它会不会被真正使用。我见过太多技术报表因为全是数字和英文缩写最后躺在共享盘里吃灰。3.4 未恢复告警的识别逻辑“未恢复告警”是运维最关心的指标之一但它的识别逻辑有个坑。一条告警的产生和恢复是两条独立的events记录产生时value1恢复时value0它们的objectid触发器ID相同。要找出当前仍未恢复的告警逻辑是对每个触发器找到它最近一条事件如果这条事件的value1说明还没恢复。这个逻辑用SQL实现可以用子查询取每个触发器的最大eventid再判断其value。注意不能用clock取最大因为同一秒可能有多个事件用eventid更可靠它是严格递增的。SELECT e.objectid, t.description, e.clock, e.severity FROM events e JOIN triggers t ON e.objectid t.triggerid WHERE e.eventid IN ( SELECT MAX(eventid) FROM events WHERE source 0 AND object 0 GROUP BY objectid ) AND e.value 1 AND e.source 0 AND e.object 0;这条SQL是排查“僵尸告警”的利器跑出来的结果就是当前所有还挂着没恢复的问题。3.5 配置外置与参数化查询数据库连接信息、统计周期、输出路径这些都不应该硬编码在脚本里。我用一个YAML文件管理database: host: 127.0.0.1 port: 3306 user: readonly_user password: your_password dbname: zabbix report: days: 7 output_dir: ./reports top_n: 20top_n控制每个维度只展示前N名避免报表里塞几百行没人看。参数化查询这块所有用户输入或配置传入的值都用占位符绝不字符串拼接这是防SQL注入的基本功也是保护生产库的底线。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把环境搭起来。Python版本建议3.8以上太老的版本Pandas支持不好。依赖就四个一条命令搞定pip install pymysql pandas openpyxl pyyaml如果你用的是PostgreSQL把pymysql换成psycopg2-binary。装完之后建议先写个最简单的连接测试确认能连上数据库、能查到数据再往下做。我见过不少人一上来就写完整脚本结果跑不通排查半天发现是连接参数写错了白白浪费时间。4.2 数据库连接与查询封装连接这块我封装了一个上下文管理器保证连接用完一定关闭避免连接泄漏import pymysql import yaml from contextlib import contextmanager def load_config(pathconfig.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) contextmanager def get_connection(cfg): conn pymysql.connect( hostcfg[database][host], portcfg[database][port], usercfg[database][user], passwordcfg[database][password], databasecfg[database][dbname], charsetutf8mb4, cursorclasspymysql.cursors.DictCursor ) try: yield conn finally: conn.close()用DictCursor的好处是查询结果直接是字典列表转DataFrame时pd.DataFrame(rows)一行搞定不用手动映射字段名。4.3 各维度统计SQL的编写主机维度统计统计周期内每台主机的告警总数按数量倒序SELECT h.host AS hostname, COUNT(*) AS alert_count FROM events e JOIN triggers t ON e.objectid t.triggerid JOIN functions f ON t.triggerid f.triggerid JOIN items i ON f.itemid i.itemid JOIN hosts h ON i.hostid h.hostid WHERE e.source 0 AND e.object 0 AND e.value 1 AND e.clock %s AND e.clock %s GROUP BY h.host ORDER BY alert_count DESC LIMIT %s;这里只统计value1问题产生的事件因为恢复事件不算“告警次数”。clock的范围用参数传入LIMIT控制返回条数。触发器维度统计类似把GROUP BY换成t.description即可。级别维度则是GROUP BY e.severity。时间段维度用日期函数分组SELECT FROM_UNIXTIME(e.clock, %%Y-%%m-%%d %%H) AS hour_slot, COUNT(*) AS alert_count FROM events e WHERE e.source 0 AND e.object 0 AND e.value 1 AND e.clock %s AND e.clock %s GROUP BY hour_slot ORDER BY hour_slot;注意FROM_UNIXTIME里的%在Python的字符串格式化里要写成%%转义这是个容易踩的小坑。4.4 用Pandas做透视与二次加工SQL查出来的原始结果往往还需要二次加工。比如级别维度我想同时看到每个级别的数量和占比用Pandas几行就搞定import pandas as pd df pd.DataFrame(rows) df[级别名称] df[severity].map(SEVERITY_MAP) total df[alert_count].sum() df[占比] (df[alert_count] / total * 100).round(2).astype(str) % df df.sort_values(alert_count, ascendingFalse)占比这个指标特别有用一眼就能看出告警的集中度。如果某个级别占了70%以上那基本可以确定告警策略需要调整了。4.5 生成多Sheet的Excel报表最后用pd.ExcelWriter把所有维度的结果写进一个Excel文件每个维度一个Sheetoutput_path f{cfg[report][output_dir]}/zabbix_alert_report_{today}.xlsx with pd.ExcelWriter(output_path, engineopenpyxl) as writer: host_df.to_excel(writer, sheet_name按主机统计, indexFalse) trigger_df.to_excel(writer, sheet_name按触发器统计, indexFalse) severity_df.to_excel(writer, sheet_name按级别统计, indexFalse) timeline_df.to_excel(writer, sheet_name按时间段统计, indexFalse) unresolved_df.to_excel(writer, sheet_name未恢复告警, indexFalse)文件名带上日期方便归档和对比。如果你想让报表更美观可以在写完之后用openpyxl调整列宽、加表头样式但这是锦上添花先把数据跑对再说。4.6 定时任务配置脚本调通之后用crontab挂上定时执行。比如每天早上8点生成前一天的报表0 8 * * * /usr/bin/python3 /opt/scripts/zabbix_alert_report.py /var/log/zabbix_report.log 21日志重定向一定要加不然脚本报错了你都不知道。日志文件建议配合logrotate做轮转避免越积越大。4.7 一个完整的执行流程记录我把整个流程串一遍你照着走就行。第一步确认数据库表结构用DESCRIBE events;和DESCRIBE triggers;核对字段。第二步把配置填进YAML文件先用只读账号测试连接。第三步单独跑主机维度的SQL确认能查出数据且数字合理。第四步逐个维度验证每加一个维度就跑一次别一次性全写完再调。第五步生成Excel打开检查格式和内容。第六步挂crontab观察两天的日志确认稳定。这个顺序是我踩过坑之后总结的按部就班来出问题的概率最低。5. 常见问题与排查技巧实录5.1 统计数字对不上怎么办这是最常见的问题报表里的告警数和Zabbix页面显示的对不上。排查思路按这个顺序来先确认时间范围是否一致Zabbix页面默认可能用的是本地时间而你SQL里用的是UTC时间戳差了几个小时数字自然对不上。再确认source和object的过滤条件只统计触发器事件的话必须是source0 AND object0漏了这个条件会把自动发现等事件也算进去。最后确认value的过滤只算产生事件就是value1如果产生和恢复都算了数字会翻倍。5.2 查询太慢拖垮数据库数据量大的环境一条聚合SQL跑几分钟是常事。优化方向有几个一是给events表的clock字段加索引如果原本没有的话二是在从库上跑别碰主库三是缩小统计范围别一次查半年按周或按月分段查再汇总四是把LIMIT用上很多维度你只需要Top N没必要全量排序。5.3 中文乱码问题生成的Excel里中文变乱码八成是编码问题。数据库连接时charset要设成utf8mb4YAML文件读取时指定encodingutf-8写Excel时openpyxl默认就是UTF-8一般不会有问题。如果还是乱码检查一下数据库本身的字符集设置。5.4 常见问题速查表问题现象可能原因解决方向连接超时网络不通或防火墙拦截检查网络连通性和端口开放查询结果为空时间范围或过滤条件错误放宽条件逐步排查数字偏大未过滤source/object/value补全过滤条件数字偏小时间戳时区不一致统一用UTC时间戳计算Excel打不开文件被占用或写入中断检查是否有同名文件被打开脚本报KeyError配置项缺失或拼写错误核对YAML配置的键名5.5 几个我踩过的坑第一个坑是FROM_UNIXTIME的百分号转义。在Python字符串里写SQL%Y会被当成格式化占位符必须写成%%Y这个坑我调了半小时才反应过来。第二个坑是LIMIT的参数化有些数据库驱动不支持把LIMIT的值作为参数传入得用字符串拼接这时候一定要确保这个值是整数类型转换过的不能直接拼用户输入。第三个坑是Pandas的map遇到映射字典里没有的值会返回NaN如果Zabbix版本新增了级别映射字典没更新报表里就会出现空值所以映射字典要留个默认值兜底。提示脚本第一次上生产前建议先用一个小的测试环境或者手动构造几条数据验证逻辑别直接对着生产库跑万一SQL写错了把库拖慢影响的是整个监控系统。5.6 报表怎么用才有价值最后说点经验层面的东西。报表生成出来只是第一步关键是怎么用。我的做法是每周固定花半小时看这份报表重点看三个变化告警总数是升是降、Top主机有没有新面孔、未恢复告警有没有积压。如果某个主机连续几周都在Top榜上那就该安排人去现场看看了可能是硬件老化也可能是业务量涨了需要扩容。报表的价值不在于数字本身而在于它帮你把注意力引导到真正需要关注的地方。这套脚本我用了挺长时间中间根据实际需求改过好几版比如加了环比对比、加了告警确认率统计你可以根据自己的场景慢慢迭代先跑起来再优化。