简介LogViewer 是一款面向开发、运维及测试人员的轻量级日志查看工具主要解决大体积日志文件打开慢、检索卡顿的问题。压缩包共 5 个文件以 exe 可执行主程序为核心辅以 chm 帮助文档、html 说明页面、manifest 配置清单和 txt 文本说明整体仅 551KB体积小巧、部署负担低。作者实测可稳定处理 46G 日志文件对 4G 以上日志场景尤为适用已有 941 人学习下载。借助它读者可快速完成服务器排障、应用异常定位和日志内容浏览在低资源占用下保持较流畅的查看体验在服务器巡检、故障复盘等场景中也能减少等待大文件加载的时间。配套帮助文档与说明文本便于初次使用者了解功能边界和基本用法适合需要频繁查阅大型日志、又不想部署重型分析平台的初中级技术人员备用。1. 日志查看工具 logviewer先解决排障现场的可检索再谈界面凌晨两点排一个偶发超时终端里tail -f刷得比心跳快关键字明明在文件里翻回去却找不到上下文——多数团队要的日志查看工具不是再开一个窗口而是把日志 log 变成可检索、可定位、可复现的现场。logviewer 这个资源包就是围绕这个场景做的把本地或内网目录里的日志按时间、级别、来源和关键字切开保留原始行号与上下文适合后端、运维、测试以及需要临时看线上日志又不想把文件到处拷的人。它不替代集中式日志平台定位是排障现场的第一层放大镜先在本机把可疑窗口缩到几十行再决定要不要往更大的平台走。2. 把日志流拆成可检索结构logviewer 的字段模型与增量读取日志查看工具最容易翻车的地方不是界面不好看而是底层把日志当成一堆纯文本。纯文本也能grep但一旦要做时间窗过滤、级别筛选、上下文合并和增量刷新就必须先把每一行拆成稳定字段。logviewer 这类工具的落地顺序应该是先定字段模型再定读取方式最后才是页面上的搜索框和颜色。字段模型不稳后面所有过滤都是玄学读取方式不对文件一轮转页面就停在旧内容上。2.1 先定字段再谈界面时间、级别、来源、消息、上下文我一般先把日志行拆成五类信息时间戳、级别、来源、消息体、上下文归属。时间戳决定能不能做时间窗级别决定能不能快速压掉 INFO 噪音来源决定多文件混看时能不能区分模块消息体是检索目标上下文归属决定多行堆栈、异常栈、SQL 片段能不能跟着主行一起显示。很多日志查看工具只做了关键字高亮没有做“行归属”结果一搜ERROR下面十几行堆栈被当成独立行翻页时断成两截排障时非常难受。字段抽取不要求一开始就覆盖所有格式。常见做法是先支持两三类主流格式再用一条“兜底规则”把不认识的行挂到上一行后面。比如以2025-01-01T00:00:0008:00开头的行视为新记录不以时间戳开头的行视为上一条记录的续行。这样多行堆栈不会丢未知格式也不会把整个解析器卡死。字段名可以和资源包里的配置对齐但内部模型最好固定成“时间、级别、来源、消息、原始行号、续行标记”前端换皮肤不影响索引逻辑。字段作用缺失时的后果时间戳时间窗过滤、排序只能按文件顺序翻跨文件乱序级别压噪音、告警视图所有行一个颜色ERROR 被 INFO 淹没来源多文件混看、模块定位不知道哪条来自哪个服务消息体关键字检索只能全文扫命中率低原始行号回查原文件、对照grep页面行号和文件行号对不上续行标记多行堆栈合并上下文断裂异常栈只剩第一行2.2 增量读取为什么不能只用 readlines从 inode 到 offset很多自建日志查看器一开始都用readlines()全量读日志小的时候没问题几百 MB 以后就开始卡。更麻烦的是增量刷新文件被轮转后旧文件句柄还指着旧 inode新日志写进了新文件页面却一直显示旧内容。这个问题不是界面刷新频率能解决的必须在读取层记录“文件身份 字节偏移”。常见做法是每轮读取前先stat一下路径拿到 inode 和 size如果 inode 变了就重新打开文件并把偏移归零如果 size 比上次小也视为轮转或截断重新读。读取时不要按字符读按字节读到缓冲区再按换行切分最后用探测到的编码解码。这样既能处理大文件也能避免多字节字符被截断。偏移量要落在“完整行之后”不能落在缓冲区中间否则下次刷新会从半行开始出现乱码或重复行。多行合并也要在这一层做新读到的行如果不是时间戳开头就挂到上一条记录上而不是直接 push 到列表里。这样做的好处是前端拿到的永远是“记录”不是“行”分页和上下文都好算。2.3 一个可抄的日志格式探测脚本在把目录接进 logviewer 之前我习惯先跑一个格式探测脚本确认编码、时间戳覆盖率、级别命中率。下面这段脚本只依赖标准库适合放在资源包旁边做前置检查import re import sys from itertools import islice from pathlib import Path # 常见时间戳模式按实际日志格式增删这里只做“行首探测” TIME_PATTERNS [ re.compile(r^\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}), re.compile(r^\d{2}/\d{2}/\d{4} \d{2}:\d{2}:\d{2}), ] LEVEL_PATTERN re.compile(r\b(TRACE|DEBUG|INFO|WARN|WARNING|ERROR|FATAL)\b, re.I) def probe(path: Path, sample_lines: int 2000) - None: text [] used_encoding utf-8 for enc in (utf-8, gb18030): try: with path.open(r, encodingenc, errorsstrict) as f: text list(islice(f, sample_lines)) used_encoding enc break except UnicodeDecodeError: continue if not text: print(ffile{path} empty_or_unreadable) return time_hits sum(any(p.match(line) for p in TIME_PATTERNS) for line in text) level_hits sum(bool(LEVEL_PATTERN.search(line)) for line in text) print(ffile{path} lines{len(text)} encoding{used_encoding}) print(ftime_header_ratio{time_hits / len(text):.2%}) print(flevel_hit_ratio{level_hits / len(text):.2%}) print(sample:) for line in text[:5]: print(repr(line[:160])) if __name__ __main__: # 用法python log_probe.py ./sample-logs/app.log 2000 probe(Path(sys.argv[1]), int(sys.argv[2]) if len(sys.argv) 2 else 2000)逻辑说明脚本先按utf-8严格解码失败后切到gb18030再失败就由调用方决定是否用替换字符模式。采样行数默认 2000只读文件头部不会把大文件拖进内存。时间戳覆盖率和级别命中率是给 logviewer 配置用的覆盖率低于 70% 时不要急着开时间窗过滤先确认日志是不是多行格式或者时间戳不在行首级别命中率异常低时先检查级别字段是不是被写成了中文或者缩写。参数说明第一个参数是日志文件路径第二个参数是采样行数。采样行数不要一上来设成十万头两千行足够判断格式如果日志文件头部是启动 banner、没有业务行可以临时用tail -n 2000截一段再探测。编码探测顺序可以按团队实际调整但不要同时用宽松解码跑统计否则乱码行会被算进覆盖率得到虚假的安全感。2.4 选型本地文件查看器与集中式平台的分工logviewer 这种本地文件查看器优势是轻、快、权限边界清楚日志文件就在这台机器或这个挂载目录里不需要先把数据推到远端也不用等索引构建。它适合排障前十分钟确认报错行、看上下文、对照时间窗、把可疑片段复制出来。集中式平台的优势是跨机器检索、长期留存、聚合告警但它的索引延迟和查询成本不适合所有临时排障。两者不是替代关系合理的分工是先用 logviewer 在本机把问题缩到一个文件、一个时间窗、一个关键字再把确定的线索带到集中式平台做跨服务关联。选型时看三个边界日志是否已经落到本地目录、是否允许把日志内容读到浏览器、是否需要多人同时看同一份日志。如果日志里有令牌、手机号、内部路径优先只监听127.0.0.1并且默认只读如果多人要看至少加一层反向代理鉴权不要直接把端口暴露到公网。资源包如果自带示例配置先按示例跑通再逐项改路径和过滤规则不要一上来就把生产目录挂进去。3. 跑通第一个本地检索从解压到打开 logviewer 的检查顺序拿到 logviewer 资源后最省时间的顺序不是先读全部源码而是先确认入口、依赖和示例日志能不能跑通。很多“工具不能用”的问题最后都落在入口名不对、依赖没装全、日志路径写错这三件事上。下面这套检查顺序按“目录对齐 → 虚拟环境 → 采样日志 → 检索对照”走每一步都有可回退的检查点跑不通时知道该看哪里而不是对着浏览器空白页猜。3.1 目录与入口先对齐资源包常见结构核对先把资源包解压到一个短路径下避免路径里带空格和中文减少启动参数转义问题。常见结构是入口脚本、依赖清单、示例配置、示例日志分开摆放不同资源包的命名可能不同先看根目录有没有README、requirements.txt、config目录和sample目录。入口名不确定时不要靠猜直接用--help探参数如果python logviewer.py --help报模块找不到再检查是不是包内模块启动方式比如python -m logviewer --help。这一步的目标不是记住所有参数而是确认“入口存在、依赖能导入、帮助能打印”。目录核对时重点看三件事日志路径是文件还是目录、配置里有没有写死绝对路径、示例日志编码和你的真实日志是否一致。很多资源包默认读./logs你把日志放在./data/logs页面当然空白。还有一种情况是配置里默认开了增量跟随但示例日志是静态文件页面看起来“不刷新”其实不是故障。先把路径改成示例目录确认能出结果再换真实目录。3.2 用虚拟环境起服务命令、端口与只读挂载依赖不要装到系统 Python 里尤其是日志查看工具经常要读文件、开端口环境越干净越容易排查。下面是一套通用的启动顺序入口名按资源包实际名称替换python3 -m venv .venv source .venv/bin/activate python -m pip install --upgrade pip python -m pip install -r requirements.txt # 先看帮助确认入口和参数名 python logviewer.py --help # 只监听本机只读打开示例目录 python logviewer.py \ --path ./sample-logs \ --host 127.0.0.1 \ --port 8088 \ --readonly逻辑说明虚拟环境把依赖隔离在项目目录内避免和系统里已有包冲突--help用来对齐参数名资源包如果用的是--log-dir而不是--path按帮助输出替换启动命令只监听127.0.0.1避免把日志内容暴露到局域网--readonly是底线日志查看工具不应该有删除、截断、重命名日志的能力。参数说明--path指向日志目录或单个文件先用示例目录--host建议保持本机回环地址--port选一个不冲突的端口8088 被占用就换 8090--readonly如果资源包没有这个参数就在配置里把写操作关掉或者用文件系统权限兜底。Windows 下激活命令换成.venv\Scripts\activate路径分隔符也相应调整。注意不要随手把--host写成0.0.0.0。日志里可能有 token、手机号、内部路径先只在本机看确认脱敏和鉴权方案后再考虑多人访问。3.3 首次加载用采样日志不要直接怼 10GB 文件第一次加载直接指向生产日志目录是很容易翻车的做法页面卡住、内存暴涨、浏览器渲染几万行最后你分不清是工具慢还是日志太大。更稳的方式是先截一段采样日志确认检索、分页、上下文都正常再逐步放大。采样时保留原始行号和格式不要手工改时间戳否则后面验证时间窗会对不上。mkdir -p sample-logs # 用真实日志的一段做样本路径按实际替换 cp /path/to/app.log sample-logs/app.log # 只取前 3000 行做首次加载避免一上来就全量扫描 head -n 3000 sample-logs/app.log sample-logs/sample.log wc -l sample-logs/sample.log逻辑说明cp保留原始文件的一份副本方便对照head截取头部 3000 行既能覆盖启动阶段日志又不会让首次加载等太久wc -l确认样本行数后面页面显示的总行数应该和它对得上。如果日志头部全是启动 banner可以改用tail -n 3000截取尾部或者用sed -n 10000,13000p截中间一段。参数说明-n 3000是采样行数首次跑通可以降到 500样本文件建议单独放一个目录不要和真实日志混在一起避免 logviewer 递归扫描时把副本也读进去。样本目录权限设成只读防止误操作。3.4 验证一次完整检索关键字、时间窗、上下文行页面能打开不等于检索正确。我一般用一条grep做对照同一个关键字、同一个文件、同样的上下文行数页面结果的行号和条数应该能对上。对不上时先查编码再查多行合并规则最后查时间窗时区。下面这条命令用来生成对照基线# 统计关键字命中行号并带 5 行上下文 grep -n -C 5 timeout sample-logs/sample.log | head -n 80 # 只看命中行号方便和页面结果逐条对照 grep -n timeout sample-logs/sample.log | head -n 20 # 统计样本总行数 wc -l sample-logs/sample.log逻辑说明grep -n输出原始行号-C 5带前后 5 行上下文head限制输出避免终端刷屏。页面里搜同一个关键字先看命中条数是否一致再看第一条命中行号是否一致最后看上下文是不是完整。如果页面命中更多可能是把续行也算进了消息体如果页面命中更少可能是时间窗过滤把部分行挡掉了或者编码不一致导致关键字没匹配上。参数说明-C 5的 5 可以换成 logviewer 配置里的context_lineshead -n 80只是终端限制不影响文件本身。对照时不要用grep -i和页面的大小写敏感设置混用否则条数对不上是正常的。时间窗验证时选一个已知时间点前后 10 分钟页面结果应该和sed -n截取的时间段一致。4. 把大日志压到可读窗口过滤、分页与高亮的参数配置日志 log 的检索体验八成取决于过滤链路而不是前端颜色。一个 2GB 的文件如果不做级别过滤和时间窗裁剪搜一个关键字能返回几万行浏览器渲染再快也没法看。logviewer 的配置重点应该放在“先缩小候选集再分页再给上下文最后才高亮”。参数不要拍脑袋先按基线跑再根据日志量和排查习惯微调调大任何一个参数都要知道代价在哪里。4.1 过滤表达式的最小集合级别、时间、来源、关键字过滤条件不要一上来做复杂表达式先覆盖四类级别、时间范围、来源文件、关键字。级别过滤用来压掉 INFO 噪音时间范围用来把跨天日志切成可读窗口来源过滤用来在多文件混看时锁定模块关键字过滤才是最后一步。顺序上建议“时间 → 来源 → 级别 → 关键字”因为时间窗通常能把数据量降一个数量级先做关键字全量扫描最容易卡。级别映射要提前统一。有的日志写WARN有的写WARNING有的写E如果配置里只认ERROR就会漏掉FATAL。常见做法是在配置里维护一张映射表把WARN/WARNING、ERR/ERROR、FATAL/CRITICAL归并到同一档。来源过滤不要只靠文件名最好允许按目录前缀匹配因为同一个服务可能按天轮转出多个文件。参数建议起点作用调大后的代价time_window30 分钟到 2 小时先裁时间范围窗口太大候选集暴涨levelsERROR,WARN压掉低级别噪音只留 ERROR 可能漏掉前因sources当前服务目录多文件混看时锁定范围目录太上层会扫到无关日志keyword一个具体错误码或短语最后收窄太短的关键字命中过多case_sensitive默认关闭兼容大小写差异开启后可能漏掉Timeout4.2 分页与上下文默认 200 行为什么比全部加载稳分页不是体验问题是内存和渲染的边界。一次返回 200 行前端只渲染当前页后端只保留当前窗口的上下文内存曲线是平的一次返回全部命中日志量一大就会把浏览器和后端一起拖慢。上下文行数也要有上限默认 5 行够看普通错误多行堆栈可以单独开“合并续行”视图而不是把上下文调到 50 行。上下文太大时翻页会变得很重而且真正有用的信息反而被淹没。分页参数要和“跟随刷新”一起考虑。跟随模式下新日志不断追加如果当前页是按偏移量算的新行插入会导致页码漂移。常见做法是跟随模式只展示“最新 N 行”不参与历史分页切回历史检索时暂停跟随按时间窗和行号定位。这样既不会错过新日志也不会让正在看的页面突然跳走。4.3 高亮规则配置用 YAML 管住颜色和优先级高亮规则不要写死在代码里放在配置文件里更方便团队统一。下面是一份按常见字段写的示例键名要按资源包实际配置映射不要硬套logviewer: path: ./sample-logs encoding: utf-8 page_size: 200 context_lines: 5 follow: true max_scan_bytes: 268435456 filters: levels: [ERROR, WARN] time_from: 2025-01-01T00:00:0008:00 time_to: 2025-01-01T23:59:5908:00 keyword: timeout highlight: - name: error pattern: (?i)\\b(ERROR|FATAL)\\b color: #c0392b priority: 100 - name: slow pattern: (?i)timeout|timed out|elapsed[0-9]{4,}ms color: #d35400 priority: 80逻辑说明page_size控制单页记录数200 是兼顾可读性和内存的起点context_lines控制命中行前后展示多少行5 行适合普通错误follow控制是否跟随新日志排障时开着做历史对照时关掉max_scan_bytes限制单次扫描上限避免一个超大文件把内存打满。highlight里priority越大越先匹配错误级别的高亮应该压过普通关键字高亮否则一行里颜色会打架。参数说明time_from和time_to必须带时区偏移否则跨时区日志会筛错pattern是正则注意转义YAML 双引号里反斜杠要写成\\bcolor只是示例色值按团队习惯改。max_scan_bytes不要设得比机器可用内存还大256MB 对多数排障场景够用超过就先用时间窗裁一刀。4.4 大文件场景的参数基线日志超过 1GB 时我一般按这套基线起步时间窗先缩到 30 分钟级别只留ERROR,WARN来源限定到当前服务目录关键字用错误码而不是泛词分页保持 200上下文 5 行跟随刷新关闭。等定位到具体文件后再逐步放宽时间窗和级别。这样做的原因是大文件检索的瓶颈通常在“扫描字节数”和“返回行数”不在前端颜色先把候选集压到几千行后面怎么高亮都不会卡。如果资源包支持索引优先让索引覆盖时间戳和级别两个字段不要一上来给消息体做全文索引。消息体变化大索引维护成本高时间戳和级别稳定过滤收益最直接。索引目录要放在本地磁盘不要放在网络挂载上否则刷新延迟会比日志本身还难排查。5. 避坑与排查logviewer 落地的五个常见翻车点日志查看工具的血泪经验基本都集中在“文件在变、编码在变、时间在变”这三件事上。页面能打开只是开始真正难的是轮转后还能不能跟上、中文会不会乱码、大文件会不会卡死、时间窗会不会筛错、级别过滤会不会失效。下面五条按“现象 → 原因 → 解决”写每条都给一个可执行的检查动作遇到问题时不要先改代码先按顺序把现象复现出来。5.1 文件轮转后新日志不刷新句柄还指着旧 inode现象日志文件明明已经轮转新内容也写进了新文件logviewer 页面却停在旧内容刷新按钮也没用。原因通常是读取层只打开了一次文件句柄轮转后旧句柄仍指向旧 inode新文件路径虽然变了进程并不知道。另一种情况是读取层记录了字节偏移但没检查文件大小回退截断后偏移越界读出来是空。解决每轮刷新前先stat路径比较 inode 和 sizeinode 变化或 size 变小就重新打开文件并把偏移归零。可以用下面的命令确认句柄指向LOG/path/to/app.log stat -c inode%i size%s file%n $LOG PID$(pgrep -f logviewer.py | head -n 1) lsof -p $PID 2/dev/null | grep $LOG || echo 未看到句柄逻辑说明stat输出当前路径的 inode 和大小和 logviewer 内部记录的 inode 对比lsof看进程打开的句柄如果句柄指向的文件名带.1或已删除标记说明还在读旧文件。没有lsof的机器可以用/proc/$PID/fd目录替代。参数说明LOG换成实际日志路径PID换成 logviewer 进程号pgrep -f可能匹配到多个进程先确认再操作。5.2 中文乱码和多行堆栈错位编码与合并规则没对齐现象页面里中文变成问号或方块关键字搜不到或者异常堆栈只剩第一行下面几行被当成独立记录。原因一般是读取时用了错误编码或者多行合并规则只认时间戳开头没把at ...、Caused by:这类续行挂到上一条。编码问题还会导致字节偏移和字符偏移混用翻页时出现半行。解决先用探测脚本确认编码再在配置里固定编码不要依赖系统默认。多行合并规则按“新记录开头”判断而不是按“包含关键字”判断。排查编码可以用下面这段python - PY from pathlib import Path p Path(sample-logs/app.log) raw p.read_bytes()[:4096] for enc in (utf-8, gb18030): try: print(enc, raw.decode(enc)[:120]) except UnicodeDecodeError as e: print(enc, fail, e) PY逻辑说明只读前 4096 字节分别用utf-8和gb18030严格解码哪个成功就优先用哪个两个都失败时说明文件可能混合编码或开头是二进制需要先切分文件。参数说明[:4096]可以改成更大但不要一次读整文件sample-logs/app.log换成实际样本路径。解决多行错位时在配置里把续行规则改成“不以时间戳开头即续行”并确认前端展示的是合并后的记录不是原始行。5.3 大文件一搜就卡全量扫描和前端渲染一起上现象输入关键字后页面转圈浏览器内存飙升甚至标签页崩溃。原因通常不是正则太慢而是后端把整个文件扫了一遍又把几万条命中一次性返回给前端渲染。还有一个隐藏原因是上下文行数设得太大每条命中都带几十行返回体积成倍增长。解决先限制扫描字节数和返回条数再开分页。时间窗、级别、来源三个条件至少用两个不要只靠关键字全量扫。前端只渲染当前页滚动加载要按需请求不要一次性塞进 DOM。如果资源包支持索引优先用时间戳和级别索引不支持索引时先用grep在命令行缩小范围再把小文件交给 logviewer 看上下文。5.4 时间窗筛不准时区、时间戳格式和“本地时间”混用现象明明选了 10:00 到 11:00页面却返回 02:00 到 03:00 的日志或者跨天日志少了一段。原因多是日志时间戳带时区、配置里写的是本地时间、浏览器又按本地时区解释三层时区叠在一起。还有一种情况是时间戳格式有T和空格两种解析器只认一种另一种被当成无时间行。解决配置里的时间范围统一带偏移量比如2025-01-01T10:00:0008:00解析器同时支持T和空格分隔页面展示时明确标注时区。可以用下面的命令确认机器时区和 UTC 的差异python - PY from datetime import datetime, timezone print(local:, datetime.now().astimezone().isoformat()) print(utc :, datetime.now(timezone.utc).isoformat()) PY逻辑说明输出本地时间和 UTC 时间用来对照日志里的时间戳。如果日志写的是 UTC配置里却按本地时间筛就会差出整小时。参数说明这段脚本只做对照不改系统时区生产环境改时区影响面大优先在 logviewer 配置里做偏移。5.5 级别过滤失效字段名和大小写不一致现象配置里写了levels: [ERROR]页面还是出现大量 INFO或者WARN能过滤WARNING过滤不了。原因通常是日志里的级别字段名不统一有的是levelERROR有的是[WARN]还有的是小写error解析器只按固定位置取没做归一化。解决先统计样本里的级别分布再决定映射表。可以用grep -oE快速看grep -oE \b(TRACE|DEBUG|INFO|WARN|WARNING|ERROR|FATAL)\b sample-logs/app.log \ | sort | uniq -c | sort -nr逻辑说明提取样本里出现的级别词并计数确认实际有哪些写法如果计数为 0说明级别不在行首或者用了中文需要调整解析规则。参数说明-oE只输出匹配部分sort | uniq -c做频次统计sort -nr按数量倒序。解决时在配置里维护映射WARNING - WARN、ERR - ERROR、FATAL - ERROR匹配时统一转大写。6. 用一条基准日志做回归logviewer 每次改配置后的三组断言改过滤规则最怕“看起来能用”。我习惯准备一条固定基准日志里面放启动、警告、错误、超时、恢复、停止几类行每次改配置后先跑三组断言总行数、ERROR 行号、timeout 上下文窗口。这三组能覆盖分页、级别过滤和上下文合并比手工点页面可靠。下面这段脚本会生成样本并做断言可以直接放在资源包旁边当回归检查from pathlib import Path BASE Path(baseline.log) BASE.write_text( \n.join([ 2025-01-01T00:00:0008:00 INFO boot, 2025-01-01T00:00:0108:00 INFO load config, 2025-01-01T00:00:0208:00 WARN slow disk, 2025-01-01T00:00:0308:00 ERROR timeout calling db, 2025-01-01T00:00:0408:00 ERROR retry failed, 2025-01-01T00:00:0508:00 INFO fallback, 2025-01-01T00:00:0608:00 DEBUG cache hit, 2025-01-01T00:00:0708:00 INFO request done, 2025-01-01T00:00:0808:00 WARN queue high, 2025-01-01T00:00:0908:00 ERROR timeout calling cache, 2025-01-01T00:00:1008:00 INFO recovery, 2025-01-01T00:00:1108:00 INFO stop, ]) \n, encodingutf-8, ) lines BASE.read_text(encodingutf-8).splitlines() # 断言 1总行数防止分页或合并规则把行吃掉 assert len(lines) 12, len(lines) # 断言 2ERROR 行号防止级别过滤或大小写归一化出错 error_lines [i 1 for i, line in enumerate(lines) if ERROR in line] assert error_lines [4, 5, 10], error_lines # 断言 3timeout 命中行号与上下文窗口防止多行合并和上下文行数漂移 timeout_lines [i 1 for i, line in enumerate(lines) if timeout in line.lower()] assert timeout_lines [4, 10], timeout_lines window lines[max(0, timeout_lines[0] - 3): timeout_lines[0] 2] assert len(window) 5, window print(baseline ok, error_lines, timeout_lines)逻辑说明脚本先生成 12 行固定日志再按行号做断言。第一组盯总行数防止分页参数或续行合并把记录数改掉第二组盯 ERROR 行号防止级别映射和大小写处理出错第三组盯 timeout 的行号和上下文窗口防止时间窗过滤和多行合并把上下文截断。页面配置改完后用同一个文件搜ERROR和timeout条数和行号应该和断言一致。参数说明baseline.log可以换成你自己的样本名error_lines [4, 5, 10]和timeout_lines [4, 10]要随样本内容改不要硬套window取第一个 timeout 行前 3 行到后 1 行共 5 行对应配置里的context_lines: 5。如果页面显示 6 行说明上下文边界多算了一行如果显示 3 行说明续行合并把中间行吃掉了。从那以后我每次改 logviewer 的过滤规则都先用这条基准日志跑一遍三组断言再碰真实目录踩过一次时区配置把夜间日志全过滤掉的坑就不敢省这一步了。你拿到 logviewer 资源后也建议先把入口脚本、示例日志和这份基准文件放在同一层按第 3 章的检查顺序跑通再用--help对齐实际参数最后才把路径指向真实日志。希望帮到你。本文还有配套的精品资源点击获取