LogLite 远程日志怎么跑起来？我把 Agent 和桌面端整理了一版

原文：ffzd
链接：https://mp.weixin.qq.com/s/GYbdLMxLiSiH7yiqKDEJxg

前几篇 LogLite 发出去以后，我原本以为大家最关心的会是大文件打开速度。
结果不是。
本地日志搜索器那篇数据最好，远程日志那篇也站住了 1000+ 阅读。再加上评论区一直有人提线上机器、SSH、远程日志，我就有点意识到：这个东西已经不太像一个 Wails Demo 了。
一开始我只是想写一个文章里的例子。
用 Go + Wails 做个桌面端，能打开日志目录，能搜一下关键词，能 tail 一下，证明 Go 做桌面小工具是可行的。
但做到远程日志以后，方向变了。
它开始从“演示 Wails 怎么用”，变成了一个更具体的工具：
开发者排查问题时，用来快速查看本地和远程日志。
我把这个想法也跟同事聊了一下。他也觉得这个方向可以单独做，不应该一直藏在文章 Demo 里顺手改一点。尤其远程日志这块，如果继续往下走，就要认真考虑项目结构、发布包、权限、安全、部署体验、多服务器管理这些东西。
所以我准备把 LogLite 单独提出来，后面倾斜一点时间和资源，把它当成一个真正的小工具继续做。
这篇先不拆太多代码，主要把现在的两个部分整理清楚：桌面端能做什么，Agent 能做什么，怎么跑起来，以及后面准备往哪里补。
现在分成两个项目
LogLite 现在可以按两个部分看：
LogLite Desktop
LogLite Agent
桌面端跑在本机，负责界面、连接、日志展示、搜索、实时 tail。
Agent 跑在服务器上，负责读取指定目录里的日志文件，然后通过 HTTP 和 WebSocket 把能力暴露给桌面端。
大概是这样：
┌────────────────────┐
│ LogLite Desktop    │
│ Windows 桌面端     │
└─────────┬──────────┘
│ HTTP / WebSocket
┌─────────▼──────────┐
│ LogLite Agent      │
│ Linux 服务器进程   │
└─────────┬──────────┘
│
指定日志目录
这套设计没有中心服务。
也就是说，它现在不是 ELK / Loki 那种日志平台。Agent 不会在后台持续采集所有日志，也不会把日志统一上传到一个中心库里。
桌面端什么时候连，Agent 才什么时候按需读取。
这个取舍挺重要。
我现在想解决的不是“公司级日志平台怎么搭”，而是更小的一类问题：
我维护了几台机器
日志就在服务器目录里
临时排查时总要 SSH 上去翻
有时候还要同时看几个文件
每次 tail、grep、切目录都挺烦
这种场景里，上完整日志平台太重，但一直手敲命令又不舒服。
LogLite 暂时就卡在中间：一个桌面端，加一个很轻的 Agent。
桌面端现在能做什么
LogLite Desktop 最早做的是本地日志查看。
那时它能打开本机目录，列出日志文件，点开以后看尾部内容。后来又陆续加了搜索、搜索结果跳转、上下文、暗色模式、实时 tail。
现在桌面端主要有这些能力：
打开本地日志目录
查看本地日志文件列表
读取日志尾部内容
关键词搜索
搜索结果跳转
日志级别筛选
暗色模式
本地实时 tail
连接远程 Agent
查看远程日志文件列表
读取远程日志尾部内容
远程关键词搜索
远程实时 tail
配置远程地址和 Token
界面上看起来还是一个日志工具。
左边选文件，右边看内容。需要搜索时输入关键词，需要盯新增日志时打开实时 tail。
这里我一直没有让前端背着完整日志文件跑。
不管是本地还是远程，打开文件时默认都是看尾部内容。大文件搜索也尽量放在 Go 侧处理，前端只负责展示结果。
这个思路后面还会继续保留。
桌面应用最容易犯的错，就是把一个几百 MB 甚至几个 GB 的文本直接当字符串塞进界面。小文件看不出来，一碰到真实日志就会卡。
所以 LogLite 的桌面端不会追求“像编辑器一样打开整个文件”。它更像一个排查入口：先看最近发生了什么，再按关键词去搜。
Agent 现在能做什么
Agent 是远程日志这篇里新加出来的东西。
它本质上是一个纯 Go 编译的小服务，放在服务器上跑。
当前 Linux amd64 版本大概：
6.22 MB
不用装 Node，也不需要额外运行时。传到服务器上以后，给执行权限，配置监听地址、Token 和日志目录就能跑。
启动方式大概是这样：
chmod +x ./loglite-agent-linux-amd64
./loglite-agent-linux-amd64

-listen 0.0.0.0:8089

-token
‘<随机 Token>’

-log-dir /opt/my-app/logs/2026-06-01
桌面端再填：
地址：http://:8089
Token：******
连接成功以后，桌面端就能看到 Agent 暴露出来的日志文件。
现在 Agent 已经做了这些事：
读取白名单目录下的日志文件
返回日志文件列表
读取指定文件尾部内容
执行单文件关键词搜索
通过 WebSocket 推送实时 tail 增量
Token 校验
路径越权拦截
日志文件轮转后的基础处理
这里有两个点我比较在意。
一个是白名单目录。
Agent 启动时必须指定允许访问的日志目录。桌面端看到的是类似
dir-0/node.log
这样的虚拟路径，而不是服务器上的真实路径。
如果有人构造
../../etc/passwd
这种路径，Agent 会拦住。
远程读文件这种能力不能随便开。能不能读到日志是一回事，能不能顺手读到服务器上的其他文件，是另一回事。
另一个是实时 tail。
它不是每次把整个文件重新发给桌面端，而是记录当前 offset，通过 WebSocket 推送新增内容。日志继续写，桌面端继续追加。
如果文件被清空或者轮转，Agent 会按当前实现重新读取尾部。
这个逻辑还不算完美，但已经够支撑一个最小版本。
为什么要把它单独提出来
之前 LogLite 一直跟着文章走。
写 Wails 本地日志查看器，就加打开目录和 tail。
评论区问 10G 日志，就写一篇大文件实测。
发现只会打开还不够，就补成本地日志搜索器。
有人提远程日志，就做了 Agent。
这条线走到现在，已经有点不适合继续当“文章附带 Demo”了。
因为后面要做的东西，不是再加一个按钮那么简单。
比如：
Desktop 和 Agent 的仓库结构怎么分
发布包怎么整理
Windows 桌面端怎么给别人直接下载
Linux Agent 怎么提供不同架构版本
远程连接配置怎么保存
Token 和权限怎么配置得更稳
多台服务器怎么管理
目录浏览怎么做才不会乱扫
文档怎么写，别人才能真的跑起来
这些事情都不难，但都需要投入。
如果继续把它当公众号文章里的临时 Demo，就很容易每次只补一个功能，代码和发布方式都跟着文章走。
我和同事聊这个想法时，他提醒我，远程日志这个场景其实比“Wails 示例项目”更有独立价值。
这句话让我挺认同。
因为读者真正关心的也不是我用了哪个桌面框架，而是：
这个工具能不能少开几个终端
能不能不用每次登录服务器
能不能快速看到日志
能不能搜到关键错误
能不能安全一点
能不能让别人也跑起来
所以后面 LogLite 会往独立项目上整理。
Wails 仍然是桌面端的实现方式，但它不会再是标题里的唯一主角。
下一版先补运行体验
如果按产品想象，一口气能列很多东西。
多服务器管理、HTTPS、用户体系、日志索引、K8s、告警、集中存储，哪个听起来都能做。
但我现在不想一下子把它拉成一个大平台。
下一版更想先把基础体验整理好：
Desktop 和 Agent 的目录结构拆清楚
补 README 和运行方式
提供 Windows 桌面端构建产物
提供 Linux Agent 构建产物
整理本地模式和远程模式说明
保存远程连接配置
补远程目录浏览
优化 Agent 白名单目录配置
把安全边界写清楚
这些东西不花哨，但很关键。
因为现在的问题不是“我本机能不能跑”，而是“别人拿到以后能不能跑”。
一个工具真正从文章 Demo 往项目走，第一步不是加十个功能，而是让运行方式变得稳定。
至少要做到：
下载桌面端
下载 Agent
服务器启动 Agent
桌面端填地址和 Token
能看到日志文件
能打开
能搜索
能 tail
这条链路跑顺以后，再去谈多机器、权限、索引，才比较踏实。
现在还没做的东西
有些边界也要先说清楚。
LogLite 现在还没有这些能力：
多服务器分组管理
HTTPS 配置向导
用户体系
细粒度权限
跨机器聚合搜索
跨文件远程搜索
日志索引
Kubernetes 日志
自动安装脚本
完整日志轮转兼容
当前 Demo 默认是 HTTP 和 WebSocket。
内网临时使用还行，但不要直接把 Agent 端口裸露到公网。真要放到正式环境，至少应该走内网、VPN、SSH 隧道，或者在前面加 Nginx 做 HTTPS 反向代理。
我不想把这个边界藏起来。
远程日志工具看起来只是“读个文件”，但它本质上是在服务器上开了一个读日志的入口。这个入口越好用，越要认真处理权限和暴露面。
所以短期内我会先把权限、白名单、部署说明写清楚。
先让它安全地解决小问题，再考虑做大。
这篇先算一个项目说明
这篇不像前几篇那样专门讲某个功能实现。
更像是把 LogLite 从文章 Demo 里拿出来，重新说一遍它现在是什么：
一个桌面端
一个服务器 Agent
按需查看远程日志
不做中心化日志采集
先解决日常排查里最烦的几步
这条路我准备继续做下去。
不是因为它听起来像一个很大的平台，而是因为它现在已经能解决一个很具体的问题：少登录几次服务器，少切几个终端窗口，少在一堆日志目录里手动翻。
后面我会先把仓库、运行方式和发布包整理出来。
等它真的能被别人顺手跑起来，再继续往里面加目录浏览、多服务器保存、权限配置这些功能。
先让它成为一个能用的小工具。
这比继续把它当文章素材，更有意思一点。

---

💬 本文评论区已开启，欢迎在下方留言交流。
本文转载自微信公众号，如有侵权请联系删除。