1. 目标读者
数字化系统开发运维（DevOps）工程师、稳定性工程师（SRE）、可观测平台运维人员等。
2. 背景介绍
iLogtail 是阿里云日志服务（SLS）团队自研的可观测数据采集 Agent，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，可以署于物理机、虚拟机、Kubernetes 等多种环境中来采集遥测数据。目前 iLogtail 已有千万级的安装量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景，在实战中验证了其强大的性能和稳定性。
CloudLens for SLS是日志服务推出的一款应用，帮助用户监控和管理日志服务Project、Logstore等资产，提升用户对日志服务资产的管理效率、快速了解其消耗情况。
3. 使用场景
文件日志采集是日志采集Agent最常见的数据采集场景，iLogtail目前支持主机上文件采集以及容器场景下的文件采集。但是文件采集在实战中会遇到各种各样的问题，基于此场景，CloudLens for SLS集成了针对iLogtail的状态监控，可以实时的反馈当前iLogtail Agent的运行状况。
本文主要介绍如何使用CloudLens for SLS定位和解决iLogtail日常使用中的常见问题之一：iLogtail异常重启问题。
4. 问题描述
4.1 问题发现
CloudLens for SLS页面，点击报表中心下采集监控，然后查看iLogtail异常监控-Logtail重启列表(必须处理)
里面会展示当前project下，有重启的iLogtail信息，包括最近重启时间、主机名、IP、当前iLogtail的CPU占用、内存占用、包含的采集配置数和重启次数。
如果是手动重启，这里的信息可以忽略，但是如果是非手动的异常重启，那么就会带来如下的一些问题。
4.2 问题影响范围
容器场景下，如果checkpoint没有持久化，那么iLogtail重启之后，checkpoint会丢失，这样有可能会导致日志采集重复或者采集丢失
主机场景下，CPU或者内存过高，导致iLogtail重启，也会导致有少量数据重复。
如果重启频率过高，会影响数据采集，比如日志不能被及时采集，有可能会导致比较大的采集延迟。
5. 具体场景与方案建议
5.1 场景一：主机场景下CPU过高或者内存过高导致iLogtail主动重启
问题原因
为了控制资源占用，iLogtail会限制自己所占用的CPU和内存，CPU使用率、内存使用率跟数据量、计算量息息相关，在数据量比较大的情况下，有可能会超过设置的CPU或者内存限制，当iLogtail感知到资源超限之后，会主动重启，来确保自己的资源占用不会过高。
比如iLogtail配置里，cpu限制为0.4，内存限制为512，实际使用内存一旦超过512，iLogtail就会主动重启。
如何定位
通过CloudLens For SLS 查看iLogtail的CPU和内存占用
解决方案
调整CPU和内存配置：参考推荐参数
5.2 场景二：K8s DeamonSet场景下CPU过高或者内存过高导致K8s强制重启iLogtail容器
问题原因
比如K8s的内存配置的是512MB, 但是iLogtail的配置里，内存却配置了1024MB。这种情况下，当数据量过大的情况下，iLogtail使用的内存超过512MB之后，K8s会主动把容器重启，从而导致iLogtail被动重启。
如何定位
查看logtail-ds页面，发现有Pod重启
点击详情，查看事件，发现里面有PodOOMKilling的事件，就说明是内存OOM导致K8s强制重启iLogtail容器
解决方案
为了减少主动重启带来的数据重复或者丢失现象，推荐使用iLogtail采集进度持久化。
调整CPU和内存配置。K8s场景DaemonSet模式下需要修改两个地方
alibaba-log-configuration里的cpu-core-limit和mem-limit
logtail-ds里的的资源限制
修改完之后，需要重启下logtail-ds才能生效。
5.3 场景三：K8s 场景下livenessProbe失败导致K8s强制重启iLogtail容器
问题原因
K8s场景下，iLogtail有两种探测方式：
命令行探测：
livenessProbe:
exec:
command:
- /etc/init.d/ilogtaild
- status
initialDelaySeconds: 30
periodSeconds: 30该方式为最基础的探测方式，各种场景下通用，如果出现异常，则证明iLogtail主进程有异常。
Http请求探测：
livenessProbe:
failureThreshold: 3
httpGet:
path: /liveness
port: 7953
scheme: HTTP
initialDelaySeconds: 35
periodSeconds: 60
successThreshold: 1
timeoutSeconds: 1该方式有一定的条件限制，目前在iLogtail DeamonSet模式下适用，默认对于Sidecar模式不适用。
如何定位
Sidecar模式部署iLogtail，查看业务Pod页面，发现有重启现象
点击详情，查看事件，发现里面有iLogtail的probe failed的事件，且重启的原因是因为探测失败。
解决方案
选择合适的探测方式。如果是Sidecar的部署方式，请使用命令行探测方式。详细配置参考文档。
5.4 场景四：长时间通信失败
问题原因
iLogtail会定期监测自己与外界的网络请求情况。
iLogtail会定时与ConfigServer通信，用来获取最新的采集配置，如果由于网络问题，导致iLogtail长时间（1h）获取不到采集配置，iLogtail会主动重启。
iLogtail长时间（12h），没有成功发送数据，iLogtail会主动重启
如何定位
在/usr/local/ilogtail/ilogtail.LOG文件里搜索关键字：prepare force exit，如果能够搜到内容，则说明出现该问题。
解决方案
排查网络问题，确保iLogtail跟SLS网络通畅
5.5 场景五：被外部误杀进程
问题原因
iLogtail启动的时候，会运行两个进程，第一个是守护进程，第二个是主进程
如果主进程被杀掉，守护进程会把主进程再拉起来。
比如我们手动把主进程杀掉
可以看到守护进程又拉起了另外一个主进程
如何定位
排查是否有误杀iLogtail的脚本或程序
解决方案
修复脚本或者程序，将iLogtail进程排除在管控范围之外
6. 参考资料
关于iLogtail
iLogtail作为阿里云SLS提供的可观测数据采集器，可以运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据（日志、监控、Trace、事件等），已经有千万级的安装量。目前，iLogtail已正式开源，欢迎使用及参与共建。
钉钉群：iLogtail社区
