推荐用 subprocess.Popen 启动 tail -f 实时监听日志，避免 open() 卡 EOF 或轮询失效；需处理 logrotate 导致的进程退出、编码、半行等问题，正则匹配优于 in 查找，统计应边读边聚合防内存溢出。
用 tail -f 配合 Python 读取实时日志流，别直接 open() 文件
日志文件持续追加时，open('app.log').readlines() 会卡在 EOF，且无法感知新行。必须用类似 Unix tail -f 的行为——监听文件末尾、阻塞等待新增内容。
推荐用 subprocess.Popen 启动 tail -f，避免轮询或 inotify 复杂封装：
import subprocess
proc = subprocess.Popen(['tail', '-f', '/var/log/app.log'], stdout=subprocess.PIPE, stderr=subprocess.DEVNULL, text=True)
for line in proc.stdout:
if 'ERROR' in line or '500' in line:
print(f"告警: {line.strip()}")
- Windows 用户需改用
Get-Content app.log -Wait（PowerShell）或安装tail工具，Python 原生无跨平台tail -f等价物 -
text=True必须显式指定，否则返回bytes，字符串匹配会失败 - 不要用
while True: time.sleep(1); f.seek(0, 2); ...轮询——CPU 白耗、漏行、inode 变更（logrotate）时失效
正则过滤比 in 查找更准，但别写太复杂的 pattern
日志格式不统一时，'ERROR' in line 会误报（比如 URL 含 error=timeout），也漏掉带堆栈的多行错误。必须用正则锚定关键字段。
例如匹配 Nginx access log 中状态码 5xx 且响应时间 >1s：
立即学习“Python免费学习笔记（深入）”；
import re
pattern = r'(\d+\.\d+\.\d+\.\d+) - .*? "(GET|POST) .*?" (\d{3}) \d+ (\d+\.\d+)'
for line in proc.stdout:
m = re.match(pattern, line)
if m and m.group(3).startswith('5') and float(m.group(4)) > 1.0:
print(f"慢错请求: {m.group(1)} {m.group(3)} {m.group(4)}s")
- 用
re.match()而非re.search()，避免从中间匹配导致误判（如日志前缀含 IP） - 避免
.*开头的贪婪匹配，易回溯爆炸；优先用[^ ]*或\S+限定字符集 - 如果日志量极大（>10MB/s），预编译
re.compile(pattern)，否则每次调用都重新解析正则
按时间窗口聚合统计时，用 collections.defaultdict + 时间戳截断，别存全量
想算“每分钟 500 错误数”，不能把所有日志行缓存再分组——内存爆掉。得边读边归档，只保留当前窗口数据。
简单做法：用字典以分钟级时间戳为 key 计数：
from collections import defaultdict
from datetime import datetime
<p>counts = defaultdict(int)
def get_minute_key():
return datetime.now().strftime('%Y-%m-%d %H:%M')</p><p>for line in proc.stdout:
if ' 500 ' in line:
counts[get_minute_key()] += 1</p><h1>每分钟打印一次，清空上一分钟（实际应加锁或用线程安全结构）</h1><pre class="brush:php;toolbar:false;">now_min = get_minute_key()
if now_min != list(counts.keys())[-1]:
print(f"{list(counts.keys())[-1]}: {counts.pop(list(counts.keys())[-1], 0)} 个 500")
- 真实场景需考虑时区（
datetime.now()是本地时区，日志可能是 UTC） - 若需滑动窗口（如最近 60 秒），得用有序字典或
heapq维护时间队列，不然旧数据永远残留 - 单进程统计没问题，但多进程/多机器时，这类计数必须交由 Redis 或 Prometheus 处理，Python 进程内字典不共享
遇到 logrotate 后文件被删或重命名，tail -f 会静默退出
tail -f 在日志被 mv 或 rm 后不再输出新内容，但进程不报错，脚本就卡死在 for 循环里——这是最隐蔽的故障点。
- 必须检查
proc.poll()是否非 None，一旦退出就重启tail -f子进程 - 更健壮的做法是监听 inotify 事件（Linux）或使用
watchdog库，但增加依赖；简单脚本加个循环重试即可 - logrotate 配置里加上
copytruncate（而非create）可避免 inode 变更，tail -f能继续读原文件描述符
真正难的不是写逻辑，而是处理日志源本身的不稳定性——文件消失、编码乱码、半截行、时钟漂移。先保住数据流不断，再谈分析精度。
