【komari 接手第一天】agent 架构整理结果

agent 装在需要被监控的服务器上，采集这台机器的各种运行数据，上传给服务端面板。

以下是架构整理的结果：

- cmd/ —— 入口层，负责解析命令行、读懂用户输入的是什么命令，再调用 internal 里对应的业务逻辑；这一层本身不该有业务逻辑，只做转发，是很薄的一层

- internal/

- app/ —— 核心业务逻辑所在，启动采集器采集机器数据，再创建上报器把这些数据发送到服务端

- collector/ —— 负责采集这台机器的各项指标，比如 CPU、内存、磁盘、GPU 使用情况，采完就完事，不管怎么发出去

- config/ —— 定义了 agent 要用到的所有配置参数，比如连哪个面板地址（Endpoint）、用哪个 Token 认证、多久采集一次数据（Interval），并负责从命令行/文件/环境变量里读进来、读完校验一遍

- connectivity/ —— 统一管理和服务端的连接方式（HTTP、WebSocket、用哪个 DNS、优先 IPv4 还是 IPv6），别的模块要发请求就直接用它，不用各写一套

- discovery/ —— 用户只需给一个发现密钥，agent 就自动拿着密钥去连接服务端、完成注册

- reporter/ —— 负责把 collector 采到的数据整理好，通过和服务端的连接发送出去，负责"数据怎么发"这一步

- rpc/v2/ —— 定义 agent 和服务端沟通用的消息格式（请求、响应、事件），reporter 和 task 发消息前都要按这个格式打包

- task/ —— 目前只有一个任务：ping 一个目标服务器（支持 ICMP、TCP、HTTP 三种方式），拿到延迟结果

- version/ —— 就存了一个当前版本号，编译的时候写进去，运行时上报给服务端

- pkg/idna/ —— 跟这个 agent 业务完全无关、可以单独拿走用的小工具

功能上的两个改动

除了目录结构的整理，这次还砍掉了两个功能：

删除了执行服务端下发命令的功能。 原来的实现里，agent 是可以接收并执行服务端下发的命令的（远程执行、终端、文件传输那一整套）。这次把它删掉了——现在这个项目的定位就是探针：只负责采集数据、上报数据，不做运维操作。服务端能远程在目标机器上执行任意命令，本身是一块不小的风险敞口，也和"探针"这个定位对不上，所以拿掉了。

删除了自动更新的功能。 原来 agent 会自己检查更新、下载、替换自己的二进制。这个也删了。装 agent 的大多是生产服务器，一般不希望程序自己悄悄更新自己——更新这件事最好是可控的、手动触发的，而不是 agent 自己决定什么时候换掉自己。以后要更新，走手动部署就行。

目前进度

这些改动目前都还在重构分支上，还没合并到主分支，也还有一些工作量没处理完。

关于架构这件事

顺带说一下架构本身。架构从逻辑上体现了对整个系统的理解程度——架构设计得好不好，直接决定了这个系统以后好不好维护、好不好扩展，甚至也会影响性能。

这次 agent 这边代码量不算大，重构的压力还好；真正的大头是服务端，那边代码量大得多，后面会是更主要的工作。

GitHub：https://github.com/komari-probe