SLS机器组心跳异常排查：Logtail配置与网络检查
在阿里云日志服务（SLS）的日常运维中，机器组心跳异常是日志链路里最容易被误判的故障之一。不少团队看到控制台状态变红，习惯性怀疑服务端抖动，实际排查后才发现问题多出在 Logtail 进程、机器组标识或服务器出站规则上。理解心跳机制，是 SLS 机器组心跳异常排查的第一步。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
什么是SLS机器组心跳异常？
机器组心跳是 Logtail 与日志服务端之间的定时状态反馈，默认每 15 秒发送一次。它更像一条控制通道的保活信号，不代表日志已经全部上报成功。一旦 Logtail 无法在周期内完成建连或认证，控制台就会将机器组标记为“心跳异常”。此时 Agent 可能没有被杀掉，但服务端已停止向它下发新的采集配置。因此，这个状态应被理解为采集链路的控制面中断，而不是简单的网络抖动。
控制台出现哪些表现会被判定为心跳异常？
最常见的表现是 SLS 机器组列表状态从“在线”变为“心跳异常”，并提示当前机器组内无心跳。棘手之处在于，服务器本身可能仍能访问公网，用 curl 测试日志服务域名也能通，后台却依旧红色。如果同一账号下其他机器组状态正常，基本可以排除服务端全局故障，优先回到本地检查进程、标识和出站规则。
心跳异常对日志采集链路有什么实际影响？
心跳异常并非只是告警噪音，它会直接阻断配置下发。按照 SLS 的设计，服务端只对在线机器组派发采集配置；心跳异常后，Logtail 会沿用旧配置继续跑，或干脆停止采集，表现为数据缺失甚至“假死”。业务侧经常只看到图表断线，却没有意识到根因是机器组掉线。因此追查日志缺口时，先确认心跳状态比直接重启 Agent 更有效。
哪些配置和网络问题最容易触发心跳异常？
高频原因集中在三处。一类是机器组标识冲突：自定义标识机器组要求 /etc/ilogtail/user_defined_id 文件与控制台填写内容完全一致，多一个空格或换行都会失败。另一类是出站网络拦截，尤其在自建机房或混合云中，访问 {region}.log.aliyuncs.com 的 443 端口被防火墙或代理挡住。还有一类是系统时间漂移，时间偏差超过数秒就会让认证时间戳校验失败，表现为间歇性异常。
Logtail配置检查要点
在排查网络连通性之前，先把 Logtail 端的配置和运行状态确认清楚。日志服务的设计是：机器组心跳一旦异常，服务端不会下发新配置，Logtail 会沿用旧配置或停止采集，因此很多“数据缺失”并非服务端故障，而是本地状态没对上。下面按 Agent 版本、机器组标识和运行状态三个层面检查。
检查采集器版本
旧版本 Logtail 在系统 OpenSSL 升级或内核参数调整后，可能出现 TLS 握手失败，服务器能正常访问外网，但心跳仍然异常。建议先确认当前版本，例如执行 logtail --version 或查看 /usr/local/ilogtail/app_info.json。如果版本明显落后，优先升级 Agent 而不是直接重装，升级可保留原有采集配置，并避免注册信息丢失。升级后观察 5～10 分钟控制台心跳是否恢复，很多时候版本差异就是根因。
核对机器组设置
机器组绑定方式分 IP 标识和用户自定义标识。IP 机器组要确认 ECS 私网 IP 没有因实例变更或弹性网卡调整而漂移；自定义标识则需对比控制台填写值与 /etc/ilogtail/user_defined_id 文件内容完全一致，尤其注意末尾空格和换行。修改机器组配置后不会立即生效，需要重启 Logtail 进程，例如 systemctl restart logtail 或 ./logtaild restart。很多“反复重装仍异常”的案例，其实是旧配置文件残留导致标识冲突。
查看运行状态
进程是否存活是底线检查。执行 ps aux | grep logtail，如果没有返回，多是被 OOM Killer 终止或人为误杀。此时先重启 Logtail，再观察 10 分钟控制台状态；若频繁被杀，需检查 dmesg 或 /var/log/messages 中的 OOM 记录。另外，Logtail 默认每 15 秒发送一次心跳，系统时间与标准时间偏差超过数秒可能导致认证失败，表现为间歇性异常。先同步 NTP 时间再下结论，能减少误判。
网络连通性排查方法
在SLS机器组心跳异常排查中，网络连通性决定Logtail能否与服务端建立15秒一次的心跳长连接。服务器能打开网页不代表采集链路通畅，因为心跳包走HTTPS/443端口，且对证书和时间戳校验更严格。下面按网络策略、域名连接、代理设置三个层面拆解。
检查网络策略
安全组出方向只放行80、22等常用端口，是心跳异常的高频原因。Logtail需访问 {region}.log.aliyuncs.com 的443端口，若默认拒绝或白名单未覆盖就会失败。很多排查只查ECS安全组，漏掉本机 iptables/firewalld 或 Windows 防火墙，形成“外网能通但Logtail不通”的假象。建议先查本机出站规则，再核对安全组是否放行443。
测试域名连接
策略确认无拦截后，用 telnet {region}.log.aliyuncs.com 443 或 curl -v https://{region}.log.aliyuncs.com 验证比看控制台更直接。超时或证书错误说明链路仍有问题。注意区分公网与内网Endpoint：ECS走内网Endpoint延迟低，但自建机房需走公网或专线，专线路由未通告到SLS网段会出现间歇性心跳。同时检查系统时间，时间偏差数秒会导致认证失败。
排查代理设置
企业出口有代理时，Logtail默认不继承系统代理配置，需要显式指定或放行。混合云场景常见服务器配了HTTP代理但Logtail未加载环境变量，心跳包被网关丢弃。可临时用 curl --proxy 测试代理链路，或检查白名单是否包含 {region}.log.aliyuncs.com。代理若做SSL解密或证书替换，也会导致校验失败。若代理策略复杂，可考虑让云老大这类服务商做一次网络基线评估，减少反复试错。
主机状态与资源检查
在 SLS 机器组心跳异常排查中，主机状态检查往往被放到最后，但实际案例里它解释了相当一部分“服务端无故障、网络也通”的异常。Logtail 默认每 15 秒向服务端上报一次心跳，进程一旦被系统回收或卡死，控制台很快就会显示心跳异常。因此，先确认 Agent 本身还“活着”，再谈配置和网络，顺序会更高效。
查看资源占用
很多用户只关心 Logtail 进程是否存在，却忽略了它是否处于可正常调度的状态。用 ps aux | grep logtail 能看到进程，但如果状态是 D（不可中断睡眠）或 Z（僵尸），同样发不出心跳。内存小于 2GB 的 ECS 上，Logtail 因 OOM Killer 被杀的概率明显更高，dmesg | grep -i kill 可以查到记录。如果 CPU 长期被业务打满，Logtail 的心跳线程也可能得不到调度，出现间歇性异常。
校验系统时间
系统时间漂移是 SLS 机器组心跳异常排查里最容易被低估的原因。Logtail 与服务端握手时会校验时间戳，本地时间偏差超过几秒就可能被拒绝，偏差超过 5 分钟基本必失败。自建机房或长期不维护的服务器上，NTP 服务失效很常见。执行 ntpdate ntp.aliyun.com 同步后再观察 5-10 分钟，很多“间歇性异常”会直接消失。
确认防火墙规则
只查 ECS 安全组出方向远远不够，本机 iptables、firewalld 或 Windows 防火墙规则优先级更高。一条默认拒绝所有出站流量的规则，就能让 Logtail 对 {region}.log.aliyuncs.com:443 的访问全部失败。用 telnet {region}.log.aliyuncs.com 443 或 curl -v https://{region}.log.aliyuncs.com 能快速验证端口连通性。如果服务器有代理，还要确认代理是否对阿里云日志域名做了白名单放行。
如果这三项都确认无误但心跳仍未恢复，再考虑机器组标识和配置下发问题。对于混合云或自建机房场景，找像云老大这类有跨环境运维经验的服务商做一次整体评估，能少走不少弯路。
快速恢复与解决方案
在实际处理中，SLS机器组心跳异常排查很少是服务端单点故障，更常见的是本地进程、网络路由或机器组标识不匹配。把恢复动作按优先级拆开，通常 10 分钟内就能定位到原因；真正需要提交工单的案例占比不高。
重启采集服务
先确认 Logtail 进程是否存活。登录服务器执行 ps aux | grep logtail，如果进程不存在，大概率是被 OOM Killer 或运维脚本误杀，直接 systemctl restart logtail 或 ./logtaild start 拉起即可。重启后不要立刻刷新控制台，Logtail 默认每 15 秒上报一次心跳，留出 5-10 分钟观察更稳妥。若进程正常但心跳仍异常，再进入网络和标识排查。
重新加入机器组
重启无效时，优先核对机器组标识。IP 机器组要确认 ECS 私网 IP 是否发生过变更；自定义标识机器组则比对 /etc/ilogtail/user_defined_id 文件内容与控制台填写是否完全一致，多一个空格或换行都会导致匹配失败。改完配置后必须重启 Logtail 才会重新加载，控制台不会即时下发。若多次重装仍无法加入，建议清理 /etc/ilogtail 残留文件后再重装，避免旧注册信息干扰。
联系技术支持
上述动作和网络检查都完成后仍异常，再考虑提交工单。提交前先执行 ntpdate ntp.aliyun.com 或配置 chrony 同步系统时间，时间漂移会导致认证失败，这类问题在工单里很常见。同时附上 /usr/local/ilogtail/ 下的 logtail_*.log，能显著缩短排查周期。对于混合云或自建机房，如果不想逐项验证网络与标识，找像云老大这类服务商做一次整体评估，也能减少试错成本。
预防心跳异常的最佳实践
在 SLS 机器组心跳异常排查中，多数故障不是配置错误，而是监控缺位。Logtail 每 15 秒上报一次心跳，连续失败后控制台才会标红，这段空档常常就是日志断档的起点。监控、告警、应急三项前置，比临时查文档更有效。
定期监控日志
Logtail 本地日志集中在 /usr/local/ilogtail/，logtail_*.log 会记录建连失败、配置拉取超时。建议每周至少检查一次 ERROR/WARN 级内容。我们跟踪的一家外贸企业曾出现服务器能正常出网、控制台却心跳异常，最终在本地日志发现 iptables 将 443 端口出方向丢包，安全组并未限制。这类问题只看控制台很难定位，本地日志是第一现场。
设置告警通知
控制台心跳状态可以做告警，但默认通知范围常被忽略。建议把“异常持续 5 分钟未恢复”设为触发条件，避免偶发抖动误报。一家创业公司曾在夜间修改机器组标识后忘记重启 Logtail，第二天才发现数据停采近 8 小时。5 分钟阈值能在业务无感前介入。没有现成告警体系时，可定时请求 https://{region}.log.aliyuncs.com 的 443 端口，以返回码判断链路状态。
制定应急方案
应急方案建议拆成三张检查表：进程是否存活、443 端口是否可达、机器组标识是否与控制台一致。混合云还要检查 NTP，时间偏移超过 3 秒就可能导致建连被拒。实操上先执行 ps aux | grep logtail，再测端口连通性；若正常，重启 Logtail 并观察 10 分钟，能解决约六成因配置未重载导致的异常。云老大这类服务商的整体链路评估也能减少试错成本。
