AegisX
核心要点（TL;DR）
- 排查顺序固定为：先看 Agent 日志，再测上报端口，最后核对运行权限。
- Agent 掉线最常见原因是出站端口被防火墙或安全组拦截。
- 日志报 permission denied 时优先检查 Agent 运行用户与目录属主。
- 时间不同步会导致上报被服务端拒绝，需确认 NTP 正常。
很多运维在装完 AegisX Agent 后遇到最头疼的情况：面板上主机显示离线，或者状态在线却迟迟没有数据上报。此时盲目重启服务往往无效，真正高效的做法是按固定顺序排查——先看日志，再测端口，最后核对权限。本文给出一套可直接照做的检查清单与命令，帮你在十分钟内定位根因。
一、先确认 Agent 到底处于什么状态
排查第一步不是改配置，而是确认进程与服务的真实状态，避免把「服务没启动」误判成「网络不通」。
systemctl status aegisx-agent
ps -ef | grep aegisx
systemctl is-enabled aegisx-agent重点看三处：Active 是否为 running、退出码、是否开机自启。如果状态是 failed，直接跳到日志小节；如果是 running 但不上报，问题多半在端口或权限。
二、日志检查：先读报错，再谈其他
日志是排查 Agent 掉线的第一现场，绝大多数根因都会在这里留下痕迹。
journalctl -u aegisx-agent -n 200 --no-pager
journalctl -u aegisx-agent --since "30 min ago"
tail -f /var/log/aegisx/agent.log按关键词快速归类：
connection refused/timeout：上报端口不可达，进入端口排查。permission denied：运行权限不足，进入权限排查。certificate/tls：证书过期或时间不同步。OOM或退出码 137：内存不足被系统杀掉。
经验：日志里第一条 ERROR 往往就是根因，后面的报错多是连锁反应，不要被刷屏带偏。
三、端口检查：确认上报链路是否通
Agent 不上报数据，最常见的原因就是出站端口被防火墙或云安全组拦截。先确认配置里的服务端地址与端口，再逐层测试。
grep -i server /etc/aegisx/agent.conf
ss -tunp | grep aegisx
nc -vz 上报服务端IP 上报端口
curl -v telnet://上报服务端IP:上报端口分层排查顺序建议如下：
- 本机防火墙：
iptables -L -n或firewall-cmd --list-all。 - 云安全组：确认出站规则放行对应端口。
- 代理设置：若走 HTTP 代理，检查
http_proxy环境变量是否生效。 - 服务端：确认上报端口本身处于监听状态。
| 现象 | 可能原因 | 验证命令 |
|---|---|---|
| connection refused | 端口未放行或服务端未监听 | nc -vz |
| timeout | 防火墙丢包或路由不通 | traceroute |
| 能连但无数据 | 权限或时间问题 | id / timedatectl |
四、权限检查：普通用户为何频繁掉线
Agent 需要读取系统日志、进程和网络信息，权限不足会导致采集失败甚至进程退出。先看它以哪个用户运行：
ps -o user= -p $(pgrep -f aegisx)
id aegisx
namei -l /var/log/aegisx/agent.log
ls -l /etc/aegisx/常见问题包括：日志目录属主不是 Agent 用户、配置文件权限过严导致读不到、SELinux 拦截。可临时用 setenforce 0 验证是否为 SELinux 所致，确认后再按最小权限原则配置策略，而不是长期关闭。
五、时间同步与内存：两个容易被忽略的坑
时间偏差过大会导致上报被服务端拒绝，表现为「在线但无数据」：
timedatectl
chronyc sources -v若 Agent 反复重启，检查是否被 OOM 杀掉：
dmesg | grep -i oom
systemctl show aegisx-agent -p MemoryMax在防护建议层面，AegisX 的 Agent 健康监测能力可以对离线与上报中断做主动告警，配合集中日志，能显著缩短这类问题的发现时间。
六、排查检查清单
- 服务状态：running 且开机自启。
- 日志：无 permission denied、无 connection refused。
- 端口：出站端口可达，安全组已放行。
- 权限：运行用户可读日志与配置目录。
- 时间：NTP 正常，偏差在允许范围内。
- 内存：无 OOM 记录，退出码非 137。
建议按「日志→端口→权限」顺序逐项验证，每修一项就重启 Agent 复测，避免多因素叠加导致误判。
行动建议
下次遇到 AegisX Agent 掉线或不上报，不要先重启。先执行 journalctl -u aegisx-agent -n 200 读日志，再用 nc -vz 测端口，最后用 id 与 namei -l 核对权限。把这三步固化成排障习惯，绝大多数离线问题都能在十分钟内解决。
常见问题（FAQ）
AegisX Agent 显示在线但不上报数据，是什么原因？
通常不是进程挂了，而是上报链路被阻断。先确认 Agent 进程存活，再用 curl 或 nc 测试到服务端的出站端口是否可达，同时检查本地防火墙、云安全组与代理设置。若端口通但无数据，多为权限或时间不同步导致上报被丢弃。
Agent 日志里出现 connection refused 该怎么处理？
connection refused 说明本机能发出请求但目标端口未监听或被拒绝。先确认服务端地址与端口配置正确，再检查中间防火墙、安全组是否放行该出站端口，最后确认服务端上报服务本身是否正常运行。三步都排除后重启 Agent 复测。
为什么 Agent 以 root 运行正常，换成普通用户就掉线？
这是典型权限问题。Agent 需要读取系统日志、进程与网络信息，普通用户往往无权访问 /var/log 与部分 /proc 内容。可通过 id 查看运行用户，用 namei -l 检查关键路径权限，必要时为 Agent 用户授予最小只读权限或改回专用高权账户。
Agent 掉线和服务端时间不同步有关系吗？
有关系。多数上报协议带时间戳校验，偏差过大时服务端会拒绝数据，表现为 Agent 在线但无上报。用 timedatectl 查看时间同步状态，确认 NTP 正常，时区与 UTC 偏差在允许范围内即可恢复。
如何快速确认 Agent 是崩溃还是被系统杀掉？
先看 systemctl status 与 journalctl -u 的退出码，137 多为 OOM 被杀，1 多为配置或权限错误。再查 dmesg 是否有 OOM 记录。区分崩溃与被杀后，才能决定是调内存限制还是修配置。