干运维和自托管的人几乎都遇到过这种场景某天半夜某个服务悄悄挂了或者数据库连接池被打满你第二天早上登录服务器才发现日志里已经刷了几百条ERROR然后开始被领导追着问“为什么不早发现”。用Python监控系统日志并发送警报听起来像是老生常谈但真正做下来会发现里面有不少细节坑——文件轮转、编码、告警去重、进程守护每一项都值得认真处理。这篇文章就把我从零到一搭建这套日志监控警报方案的过程拆开讲一遍代码可以直接抄思路可以复用适配的场景也不只是Linux服务器包括Windows事件日志、FTP传输日志、设备上报日志甚至内容平台的关键词监控底层逻辑都是同一套。先说清楚这套东西适合谁。如果你是个人开发者、小团队运维、或者喜欢自己折腾NAS和软路由的玩家手上有几台机器要盯又不想为这点事情上一套Zabbix或者Prometheus这样重量级的监控平台那这个Python方案几乎是性价比最高的选择。如果你已经在用Zabbix或者Spring Boot监控中心这类专业工具这篇文章也能给你补充一个它们覆盖不到的盲区日志正文里的深层错误信息。1. 先聊清楚这个监控方案到底要解决什么问题1.1 为什么是Python而不是Shell脚本很多人的第一反应是监控日志然后发警报用Shell脚本加cron不就行了grep一下关键词有匹配就发个curl通知。我的回答是能跑但只能解决最浅层的问题。Shell脚本最大的问题在于状态管理——它默认是无状态的每次cron触发都是从头开始扫描整个日志文件时间一长要么重复告警轰炸要么需要用非常别扭的方式记录上次读取位置。如果你要处理的日志文件很大每次都全量grep性能和时效性都跟不上。Python在这方面天然合适。它有足够灵活的字符串和正则处理能力可以精确提取日志里的IP、错误码、耗时数字它能很方便地实现类似tail -f的增量读取机制维护文件偏移和inode状态最重要的是它有丰富的第三方库发钉钉、企业微信、邮件、Webhook都是一两行代码的事。再加上Python在运维圈子的普及度后面有人要接手维护也不至于看不懂。1.2 一个日志监控程序应该具备哪些核心能力我在动手写之前先把需求拆成了五个核心点。第一是增量读取不能每次启动都从头扫一遍要只处理新追加的日志内容这决定了时效和资源占用。第二是自动感知文件轮转logrotate是Linux系统日志的基本操作监控程序必须能在日志文件被改名、压缩、重建后无缝切换否则一旦轮转程序就彻底哑火。第三是可配置的匹配规则不同服务关注的关键词完全不一样规则必须外置到配置文件里而不是写死在代码中。第四是多渠道告警告警要能发到钉钉群、企业微信、邮箱最好还能转发给自己的Webhook接口方便二次集成。第五是告警抑制错误爆发的时候日志一分钟能刷几百行如果每行都发一条通知别说清醒的同事连你手机的电池都扛不住。2. 动手前的准备工作环境、依赖与日志认知2.1 环境选型与依赖安装我的运行环境是Ubuntu 22.04 LTSPython版本是3.10。Python 3.8以上都行如果你的服务器还在用2.7建议先花十分钟升级一下因为后面的类型标注和语法特性在2.7上完全跑不了。依赖库其实很少核心是requests用来发各种HTTP类型的Webhook告警如果最后选择用邮件告警可以只用标准库的smtplib连第三方库都不需要装。我喜欢把依赖写进requirements.txt用pip一次性装完pip3 install requests pyyaml严格来说pyyaml也不是必须的配置用JSON也能写后面我会解释为什么我认选YAML而不是JSON。安装完之后建议用一条命令验证下requests是否正常导入python3 -c import requests; print(requests.__version__)这一步看着简单实际上能排除很多环境问题。我在另外一台CentOS机器上就遇到过pip install之后仍然ImportError的情况后来发现是机器上同时装了Python 3.6和3.9pip默认指向了3.6而python3命令指向了3.9安装到了错误的解释器里。2.2 读懂你的日志格式、级别与轮转机制在写监控代码之前我建议你先花十分钟研究一下目标日志的长相。以Nginx错误日志为例典型的一行是2025/01/06 14:23:45 [error] 18234#18234: *789 connect() failed (113: No route to host) while connecting to upstream, client: 192.168.1.10, server: api.example.com这一行里能提取的东西非常多——时间、日志级别、进程号、错误类型、客户端IP、影响的服务域名。你要做的不是简单匹配“error”这个单词而是设计足够精细的正则去抓取关键字段。另外要注意Windows系统的事件日志和Linux日志格式差异极大比如很多人在事件查看器里看到的“事件ID 153源为nvlddmkm”的错误描述就是典型的Windows驱动异常日志这类日志监控如果你用Python的win32evtlog库来做处理思路和Linux完全是两个世界。还有一个必须理解的概念是日志轮转。Linux下logrotate的常见策略是当天日志写到app.log轮转时把它改名成app.log.1然后重新创建一个空的app.log。如果程序一直持有旧文件的文件描述符它读到的是已经被改名甚至压缩的旧文件新增日志全部漏掉。这个坑我会在下一章重点讲实现方案。3. 核心代码实现从tail -f到自己造轮子3.1 基础骨架增量读取日志文件增量读取的核心思路其实就是在文件末尾开始读每次有新内容就处理没有就短暂休眠等待。我用一个LogFileFollower类来封装这个能力代码分三个部分打开文件、感知轮转、读取新行。import os import time class LogFileFollower: 模拟 tail -f 行为的文件增量读取器 def __init__(self, path, encodingutf-8, errorsignore): self.path path self.encoding encoding self.errors errors self.file None self.inode None self._open() def _open(self): # 用二进制模式打开避免在文件写入一半时出现 UnicodeDecodeError self.file open(self.path, rb) # 记录当前文件的 inode用于后续判断文件是否发生轮转 self.inode os.fstat(self.file.fileno()).st_ino # 定位到文件末尾只读新追加的内容 self.file.seek(0, os.SEEK_END) def check_rotation(self): 检测文件是否被 logrotate 轮转如果轮转了则重新打开新文件 try: current_inode os.stat(self.path).st_ino except FileNotFoundError: # 文件被移走后重建的间隙先保留旧句柄避免崩溃 return if current_inode ! self.inode: self.file.close() self._open() def read_new_lines(self): while True: self.check_rotation() raw self.file.readline() if not raw: time.sleep(0.2) return # 二进制模式读出来的是 bytes解码成字符串再返回 line raw.decode(self.encoding, errorsself.errors).rstrip(\n) yield line这里我故意用了二进制模式而不是文本模式原因影藏在细节里。日志文件写入的时候不是原子的如果程序正在写入一行日志而你的读取端正好读到了半个中文字符文本模式解码直接抛UnicodeDecodeError整个监控进程可能就此中断。二进制模式先拿bytes再手动decode配合errorsignore最多丢半个字符但进程不会崩。这是非常典型的实战细节常规教程不会写。调用方式很简单follower LogFileFollower(/var/log/nginx/error.log) for line in follower.read_new_lines(): print(line)这个循环是阻塞式的后面把规则匹配和告警逻辑加进去就行。3.2 文件轮转处理的完整实现上面代码里check_rotation就是处理轮转的关键。它的原理是对比文件当前的inode和打开时的inode一旦发现不一致说明这个路径已经指向了一个新文件旧文件要么被改名要么被删了。这时要做的就是关掉旧句柄重新打开新文件从新文件的末尾开始读。logrotate有两个典型配置会影响这个逻辑一个是copytruncate一个是create。如果是copytruncate模式日志文件会被复制一份然后原地截断这种情况inode不变我们的follower仍然持有的是同一个文件不会出问题但需要额外处理文件大小回退的情况否则follower内部的偏移量会超过文件真实大小readline会一直读到空值。我一般建议在read_new_lines里加一条判断如果当前文件大小小于上次读取的偏移量就重新seek到0。如果是create模式文件被改名成app.log.1同时创建一个全新的app.loginode发生变化上面的逻辑会自动处理。还有一种极端情况是日志目录不存在或者文件被删除os.stat会抛FileNotFoundError这里我们的处理是保留旧句柄不崩溃等文件恢复后继续读代价是这段时间内日志会丢失但至少程序活着。3.3 告警规则配置用YAML管理正则与阈值规则匹配部分我在代码架构上做了一个比较彻底的决定把正则与告警阈值全部外置到配置文件。用YAML而不是JSON是因为YAML支持注释团队里其他人维护的时候能直接看到每条规则是干什么的JSON写注释还得额外扩展字段非常别扭。下面是一份我实际在用的配置# config.yaml logs: - name: nginx-error path: /var/log/nginx/error.log rules: - name: upstream_failed regex: connect\\(\\) failed|Connection refused level: error - name: worker_crash regex: worker process .* exited on signal level: critical - name: app-backend path: /var/log/myapp/app.log rules: - name: oom regex: OutOfMemoryError|Cannot allocate memory level: critical alert: webhook: url: https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKEN mail: enable: true smtp_server: smtp.qq.com smtp_port: 465 username: monitorexample.com password: your-password from: monitorexample.com to: [opsexample.com] suppress: max_per_hour: 10加载配置用pyyaml非常简单import yaml with open(config.yaml, r, encodingutf-8) as f: config yaml.safe_load(f)重点说说规则匹配引擎。我第一个版本用的是非常朴素的代码每来一行日志就遍历所有规则用re.search判断是否命中。但实际跑下来发现两个问题一是日志行里可能同时命中多个规则导致重复告警二是有些规则频次要统计每分钟错误数量单纯的逐行匹配做不到。后来我把匹配引擎改成了分层结构第一层是日志文件级别先粗筛这个文件里是否有任何规则命中的行第二层再精细化判断命中了哪条规则、属于哪个级别但严格限制同一行最多只发送一条告警避免重复通知。3.4 告警发送钉钉、企业微信、邮件一个都不能少告警通道我封装成了一个独立的sender模块每种通道一个函数接口保持统一。这里以钉钉Webhook为例这是目前我实测最稳、最快的方式import requests import time def send_dingtalk(webhook_url, message): payload { msgtype: text, text: { content: f[{time.strftime(%Y-%m-%d %H:%M:%S)}] {message} } } resp requests.post(webhook_url, jsonpayload, timeout5) result resp.json() # 钉钉返回 errcode 0 表示成功非0需要仔细看错误信息 if result.get(errcode, -1) ! 0: # 告警发送失败不能静默吞掉至少要打印到本地监控日志 print(f[alert-error] DingTalk send failed: {result})邮件发送可以用smtplib加MIMEText实现SSL端口465QQ邮箱和163都比较稳定。企业微信的Webhook和钉钉的思路一致不过JSON格式略有差异把msgtype和content换一下就行。我特别想提醒一点告警发送过程本身要有失败容错。requests.post设置了timeout5如果通道的Webhook服务暂时抽风或者网络抖动发送会抛异常。我在实际代码里会套一层try/except发送失败时至少把待发送的消息写入一个本地文件防止告警丢得无声无息。这种情况虽然少见但一旦发生就是雪上加霜——系统故障的时候没人收到通知。3.5 告警去重与抑制别被日志刷爆通知告警抑制是我调得最久的一块。第一次上线没做抑制某次数据库连接池故障导致后端疯狂打错误日志一小时之内钉钉群里刷了一千多条告警群里直接变成刷屏现场管理员不得不先把机器人禁掉。这种告警风暴的危害甚至比漏报还大真正关键的告警淹没在噪音里人变成“狼来了”效应最后没人认真看通知了。我的方案是滑动时间窗口计数。用一个deque记录每次发送告警的时间戳每来一条新告警就先把窗口外的时间戳弹出去然后判断窗口内的数量是否超过了限制。这样比简单粗暴地每小时只发N条更灵活既能容忍短时间的小突发又能阻止真正的风暴from collections import deque class AlertSuppressor: def __init__(self, max_per_hour10): self.max_per_hour max_per_hour self.history deque() def allow(self): now time.time() # 清理60秒之前不是3600秒之前的记录 while self.history and now - self.history[0] 3600: self.history.popleft() if len(self.history) self.max_per_hour: return False self.history.append(now) return True使用的时候每次告警前调用suppressor.allow()返回True才发通知返回False就把这条错误记录到本地日志里作为审阅备案。这样即使错误风暴来了每小时最多收到10条足够暴露问题又不会刷爆通知。4. 让程序稳定跑起来systemd守护与日志记录4.1 注册为systemd服务写好的Python脚本直接挂后台跑肯定不靠谱终端一关进程就没了。我用systemd把它做成系统服务管理起来非常干净。unit文件放在/etc/systemd/system/logmonitor.service[Unit] DescriptionPython Log Monitor Afternetwork.target [Service] Typesimple ExecStart/usr/bin/python3 /opt/logmonitor/main.py Restartalways RestartSec10 WorkingDirectory/opt/logmonitor StandardOutputappend:/var/log/logmonitor/logmonitor.log StandardErrorappend:/var/log/logmonitor/logmonitor.log Userroot [Install] WantedBymulti-user.target这里有两个细节值得展开讲。第一个是Restartalways和RestartSec10这意味着就算监控程序自己挂了系统也会在10秒后自动拉起最大限度保证监控本身不出空窗期。第二个是Userroot如果你的日志文件是应用系统写入的普通用户文件其实用那个用户启动更合理但我见过太多次Python脚本因为权限不够读不到日志的情况所以在权限可控的场景下直接用root最省心。不过要注意如果日志文件属于某个服务用户用root读虽然没问题但程序自身的日志和配置权限也要做好管理。配置好后依次执行sudo systemctl daemon-reload sudo systemctl enable logmonitor.service sudo systemctl start logmonitor.service systemctl status logmonitor.service4.2 程序自身的日志与异常观测监控程序自己必须写好日志否则排查问题时连它有没有告警过都看不出来。我在程序里加了logging模块配置把程序日志写到固定文件同时按天轮转。日志级别设置为INFO这样能看到启动信息、每条规则命中情况、告警发送结果。一个典型的日志片段长这样2025-01-06 14:23:45 INFO matched rule upstream_failed in nginx-error at line 2025/01/06 14:23:45 [error] ... 2025-01-06 14:23:45 INFO alert sent to DingTalk如果日志里出现大量alert-error比如“send failed”说明告警通道出问题了要优先排查Webhook配置或网络。5. 实战中高频踩坑与排查速查表5.1 编码问题引发的乱码与匹配失败我在测试阶段用中文日志做过一次验证结果发现正则死活匹配不上后来一查原来日志文件是GBK编码而Python默认按UTF-8解码读出来的全部是乱码。日志文件用UTF-8是主流但Windows程序生成的日志很容易是GBK或者UTF-16尤其是在读Windows事件日志导出的文件时。解决办法是在读取阶段就指定编码比如LogFileFollower里加一个encoding参数按实际情况传gbk或utf-16-le。还有一个隐蔽的坑是文件里混着BOM头先检查第一行是否以\xef\xbb\xbf开头有就去掉。5.2 日志轮转后程序“罢工”我第二版代码上线后遇到过一个很诡异的问题logrotate执行完监控程序还在跑但再也不输出任何告警。后来排查发现我们的logrotate配置用的是create模式轮转后新文件权限变成了600而Python脚本用非root用户运行读不到新文件。os.stat能正常执行但不代表open能成功权限错误直接抛在了read_new_lines内部程序没崩但告警全断了。这个坑的根本解法是两种要么用root运行监控程序要么在logrotate配置里加上“create 0644 root root”这样显式设置新文件的权限。5.3 告警轰炸与漏报并存告警抑制配置成每小时10条之后真实低频率错误反而容易被漏掉。比如某个告警每小时只在整点出现一次如果前面风暴阶段把配额占满了整点这条就被抑制掉了但问题可能恰恰是整点那次才值得关注。后来我把抑制策略改成了按规则维度分别计数每条规则的配额独立这样高频率的重复错误不会占用其他规则的配额告警分配合理很多。5.4 常见问题速查表现象可能原因排查方法程序启动后没有匹配到任何日志编码配置错误日志为GBK而解码用UTF-8手动用file命令查看文件charset调整encoding参数日志轮转后告警中断新文件权限不足或inode检测逻辑未覆盖copytruncate检查logrotate配置确认create权限用strace查看open是否报权限错误钉钉通知偶尔丢失Webhook发送失败后没有重试机制检查requests的timeout和异常捕获失败时写入本地告警缓存告警内容里时间不准确服务器时区未设置为本地时区使用timedatectl检查必要时设置Asia/Shanghai程序内存缓慢上涨读取大文件时读取偏移未正确更新增加大小回退判断保险起见每次readline后记录当前offset匹配规则误报太多正则在字符边界上没有严格控制对于单词型关键词建议正则加上\b边界必要时结合上下文行匹配6. 这套方案的场景扩展从日志监控到一切“变更感知”6.1 与Zabbix、Prometheus监控中心的差异与互补很多朋友问我Zabbix和Prometheus那么成熟为什么还要自己写Python。我的回答是监控平台擅长的是指标采集与可视化但它们对日志正文的深度处理能力有限。Zabbix能监控文件大小变化、进程存活、系统负载但你要它匹配一行日志里的IP黑名单并通知到对应负责人配置起来非常痛苦。Prometheus加Loki也能做日志监控但一套Loki搭建下来没有小半天搞不定个人玩家或者小团队不值得。我实际的做法是两者结合Zabbix负责系统级的CPU、内存、磁盘监控报警阈值和图表交给它Python脚本专注业务日志里的错误识别和快速通知。两者不冲突反而是很好的互补。热搜词里的“spring boot实现监控”“普罗米修斯监控”本质都绕不开这个思路——指标归指标日志归日志事件归事件它们应该是面向同一系统的不同观测维度。6.2 拓展文件、接口、设备事件统一监控把这套监控方案向上抽象一层你会发现核心逻辑是“感知变更触达通知”不只是日志文件能作为数据源文件系统变化、接口返回数据、设备状态回调都可以纳入同一个框架。比如海康威视摄像头的事件告警通过ISAPI接口回调到Python脚本后本质上和读Nginx日志发钉钉是同一个动作。再比如一些嵌入式设备上报的环境数据冷链冷库的温湿度记录只要输出格式是文本或能通过接口拉取就能适配进这套监控引擎。热搜词里还有“闲鱼关键词监控”“抖音新作品监控助手”这类需求本质上也是循环轮询某个数据源匹配关键词变化后触发通知。我强调一下做这类监控首先要确认数据源本身的合规性优先使用官方提供的订阅、推送能力或者在有授权的接口上运行。技术层面的实现思路和日志监控完全同构一个while True循环、一个数据拉取器、一个匹配规则、一个通知sender四个模块拼起来就是一套通用的事件通知系统。6.3 后续可以继续演进的地方如果这套脚本已经稳定运行了一两个月可以考虑给它加一个简单的健康检查比如心跳文件或者调用外部API上报自身存活状态。另外一个实用方向是把告警内容结构化不同字段拼成JSON写到ES然后配合现有的告警平台做聚合分析这样就能把“接到一条告警”升级成“看清一个趋势”。我个人在实际使用中还有一个体会告警文案比告警通道更重要。一开始我写的通知就是一行错误原文大家收到也不知道先找谁处理。后来我改成模板化文案把规则名、错误级别、日志来源、具体内容和初步排查建议都拼进去群里收到告警后基本就知道下一步该干嘛。这种细节上的打磨才是日志监控真正好用和难用的分水岭。如果你也在为多台服务器的日志告警发愁不妨从这套精简方案开始跑个一两周再根据实际情况调整规则和抑制策略慢慢就会找到最适合自己团队的那套配置。