hl：用 Rust 打造的极速日志排查神器，让你专注于问题本身

你有没有这样的经历：服务器出问题了，打开几个 GB 的日志文件，等半天才加载完，然后用 grep 慢慢筛，眼睛都看花了还没找到问题？或者用 humanlog 这类工具美化一下日志，结果处理 2GB 文件要等一分多钟，黄花菜都凉了。

今天要聊的这个使用 rust 开发的工具 hl，处理同样的文件只要 1.1 秒。不是 11 秒，是 1.1 秒。它是怎么做到的？更重要的是，它凭什么能让日志排查这件“苦差事”变得不那么痛苦？

1. 速度狂魔

先看几个实测数据（在 M1 Max 上测试 2.3GB、600 万行日志）：

• hl: 1.1 秒
• hlogf: 8.7 秒（慢 8 倍）
• fblog: 34 秒（慢 30 倍）
• humanlog: 79 秒（慢 70 倍）

这不是微优化，这是量级上的碾压。速度不只是“快一点”的问题。当你在生产环境排查故障，每一秒都是真金白银。1 秒和 79 秒的差距，意味着你是 30 秒内定位问题止损，还是盯着屏幕干着急两分钟——这时候老板已经在问“修好了没”第三遍了😅。

2. 自动索引

hl 有个绝活：用 -s 参数可以按时间顺序排序所有日志，即使面对多个文件也能自动建立索引。首次扫描速度约 2 GiB/s，之后按时间范围筛选根本不用重新扫全文。更牛的是，如果日志文件增长了，它能以 10 GiB/s 的速度跳过未修改的部分重新索引

# 按时间范围筛选，瞬间完成
hl example.log --since 'Jun 19 11:22:33' --until yesterday

# 实时追踪多个日志源并按时间排序
hl -F --tail 100 app1.log app2.log app3.log

❝以前处理多台服务器的日志，要么手动合并排序（累死人），要么用 ELK 这种重型方案（杀鸡用牛刀）；现在你可以直接一条命令搞定。

hl -F <(kubectl logs -l app=service-1 -f) \
      <(kubectl logs -l app=service-2 -f)

几个 Pod 的日志自动按时间戳归并，实时追踪，100ms 同步间隔。这才是“轻量级分布式日志”的正确打开方式。

3. 查询语言

以前筛日志是这样的：

cat app.log | grep ERROR | grep -v "known issue" | grep "user_id=123"

终于不用写一堆 grep 管道了，现在可以这样：

# 逻辑表达式，一目了然
hl app.log -q 'level > info or status-code >= 400 or duration > 0.5'

# 组合条件
hl app.log -q '(request in (95c72499, 9697f7aa)) or (method != GET)'

# 字段存在性检查
hl app.log -q 'exists(.price) and price > 100'

支持 and/or/not、比较运算符、正则匹配、集合运算，甚至可以从文件加载筛选值：

hl app.log -q 'user_id in @suspicious_users.txt'

你不需要记住 grep、awk、sed 的奇怪参数组合，也不用写正则表达式手抖半天。直接说“我要找状态码大于等于 400 或者 耗时超过 0.5 秒的请求“，工具就懂了。

❝好的工具不是让你学新语法，而是让你用“人话”描述需求。

4. 细节拉满

非 JSON 前缀处理

很多日志是这样的：[INFO] 2024-01-01 12:00:00 {"user":"alice"}

加个 --allow-prefix 就能解析，不用预处理。

时区随心切

默认 UTC，但你可以：

hl app.log -L  # 本地时区
hl app.log -Z Europe/Berlin  # 指定时区

字段隐藏/显示

# 只看 provider 字段
hl app.log --hide '*' --hide '!provider'

# 隐藏 headers 和 body，但保留 headers.content-type
hl app.log -h headers -h body -h '!headers.content-type'

主题系统

内置多套配色主题，还能自定义。甚至可以用 fzf 预览选主题：

hl --list-themes | fzf --color='bg+:23,gutter:-1,pointer:210' --highlight-line --preview-window 'right,border-left,88%,<142(up,88%,border-bottom)' --preview="hl -t '%b %d %T' --input-info minimal -c --theme {} sample/*.log"

这些细节单独看不起眼，但组合起来就是“专业工具”和“能用的玩具”的区别。就像 iPhone 的震动反馈，你说不出它好在哪，但用习惯了别的手机就觉得少了点什么。

5. 开源且克制

hl 的定位很清晰：本地日志查看器。它不想取代 ELK/Loki，不做日志收集、不做持久化存储，只专注“让你在终端里快速看懂日志”这一件事。

安装也简单：

# macOS
brew install hl

# Linux
curl -sSfL https://github.com/pamburus/hl/releases/latest/download/hl-linux-x86_64-musl.tar.gz | tar xz

# Windows (Scoop)
scoop install hl

配置文件可选，环境变量优先级清晰，命令行参数可覆盖一切——符合 Unix 哲学的“做好一件事”。

❝技术选型的本质是“用最小的复杂度解决当前的问题”。

不是所有场景都需要 Elasticsearch 集群。有时候你只是想在笔记本上快速排查问题，或者在跳板机上看看日志——这时候 hl 这种“零依赖、开箱即用”的工具才是最优解。

6. 结语

工具的价值在于“消失感”，最好的工具是让你忘记它的存在。

以前看日志，你要想“用 grep 还是 awk？怎么转义这个正则？为什么颜色乱了？”——你在和工具较劲。

用 hl 之后，你直接想“这个 500 错误是哪个接口？前后发生了什么？”——你在和问题较劲。

这才是效率工具的终极意义：把时间还给思考，而不是操作。下次服务器出问题，别急着打开 Kibana 等半天加载。试试 hl，也许 1 秒钟你就找到答案了。