本文主要介绍如何使用CloudLens for SLS定位和解决iLogtail日常使用中的常见问题之一：包括STAT_LIMIT_ALARM, DIR_EXCEED_LIMIT_ALARM等诊断错误的文件/目录数超限问题，。
目标读者
数字化系统开发运维（DevOps）工程师、稳定性工程师（SRE）、可观测平台运维人员等。
背景介绍
iLogtail 是阿里云日志服务（SLS）团队自研的可观测数据采集 Agent，拥有的轻量级、高性能、自动化配置等诸多生产级别特性，可以署于物理机、虚拟机、Kubernetes 等多种环境中来采集遥测数据。目前 iLogtail 已有千万级的安装量，每天采集数十 PB 的可观测数据，广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景，在实战中验证了其强大的性能和稳定性。
CloudLens for SLS是日志服务推出的一款应用，帮助用户监控和管理日志服务Project、Logstore等资产，提升用户对日志服务资产的管理效率、快速了解其消耗情况。
使用场景
文件日志采集是日志采集Agent最常见的数据采集场景，iLogtail目前支持主机上文件采集以及容器场景下的文件采集。但是文件采集在实战中会遇到各种各样的问题，基于此场景，CloudLens for SLS集成了针对iLogtail的状态监控，可以实时的反馈当前iLogtail Agent的运行状况。
本文主要介绍如何使用CloudLens for SLS定位和解决iLogtail日常使用中的常见问题之一：iLogtail文件、目录数超过上限的问题。
问题描述
问题发现
CloudLens for SLS页面，点击报表中心下采集监控，然后查看iLogtail异常监控-关键错误（必须处理）
在关键错误表格中，会展示当前影响iLogtail采集的重要错误，对于这些错误必须处理，否则可能会造成日志采集丢失，采集性能低下等问题。示例中主要出现了STAT_LIMIT_ALARM和DIR_EXCEED_LIMIT_ALARM两种错误；在页面的下方，有文件、目录数超过上限问题（STAT_LIMIT_ALARM, DIR_EXCEED_LIMIT_ALARM）对应的表格，其中会详细展示超限的类型、路径和配置文件上限。
问题影响范围
在容器和主机场景下，都有可能出现文件、目录数超过上限的问题，导致部分文件和目录不会被采集，导致日志丢失。
原理介绍
iLogtail在监听配置的文件目录时会占用一定量的内存，为了控制资源占用，iLogtail会限制自己所占用的CPU和内存，对于iLogtail可监控的文件数，使用了与mem_usage_limit正相关的计算方法，具体如下：
在主机环境下，
mem_usage_limit的默认值为384，所以单个iLogtail采集配置可监控的最大文件数是384 / 100 * 5000 = 15000。在容器环境下，如果是daemonset方式部署
logtail-ds，mem_usage_limit会默认从alibaba-log-configuration中的mem-limit获取配置，其默认值为512，所以单个iLogtail采集配置可监控的最大文件数是512 / 100 * 5000 = 25000。注意，这里的25000是指当前主机上所有被采集的容器的文件数之和。
STAT_LIMIT_ALARM原理：
采集配置的日志路径下所有匹配的文件数、文件目录数（不包含采集黑名单中的文件目录）超过了上述计算公式的上限。
单个采集配置计算公式：mem_usage_limit/100x5,000
单个Logtail客户端所有采集配置计算公式：mem_usage_limit/100x50,000
DIR_EXCEED_LIMIT_ALARM原理：
采集配置的日志路径下所有匹配的文件目录数（不包含采集黑名单中的文件目录）超过了上述计算公式的上限。
单个Logtail客户端所有采集配置计算公式：mem_usage_limit/100x5,000
具体场景与方案建议
场景一：主机文件数/目录数过多超过上限
问题原因
iLogtail配置的日志路径的前半部分，表示iLogtail监听的目录，该目录下如果目录数过多，超过了mem_usage_limit/100x5000的限制，会出现目录数过多的警告。主机上mem_usage_limit默认为384，所以默认单个配置的文件（包括目录）上限为：384 / 100 x 500 = 15000。
如何定位
通过CloudLens For SLS 查看关键错误和文件、目录数超过上限问题（STAT_LIMIT_ALARM, DIR_EXCEED_LIMIT_ALARM）。
解决方案
检查配置中日志路径是否合理，可以尽可能“精确”地设置日志路径，比如实际要采集的目录是/var/log/nginx/access.log，可以把路径配置成/var/log/nginx而不是/var或者/var/log。
比较有用的命令：查找某个目录下的子目录及文件是否过多，以/var/log目录为例：find /var/log/ | wc -l。
如果日志路径不能更精确了，但是子目录中存在不必要收集日志的子目录，可以通过设置采集黑名单的方式将需要忽略的子目录设置排除。
或者通过设置最大监控目录深度，减少监听不必要的子目录，0表示只监控本层目录。
如果确实需要监听的目录或者文件数较多，可以通过调大iLogtail启动参数中的
mem_usage_limit来支持更多的监听。单个iLogtail配置支持的最大监听文件数是mem_usage_limit/100x500。
修改：/usr/local/ilogtail/ilogtail_config.json
场景二：容器文件数/目录数过多超过上限
问题原因
iLogtail配置的日志路径的前半部分，表示iLogtail监听的目录，该目录下如果目录数过多，超过了mem_usage_limit/100x5000的限制，会出现目录数过多的警告。
ACK容器环境下，在kube-system命名空间下的配置项alibaba-log-configuration中配置的mem-limit为512，这个mem-limit会作用到集群的logtail的daemonset，在容器环境下默认单个配置的文件（包含目录）配置上限为512 / 100 x 5000 = 25000。
注意：alibaba-log-configuration中的mem-limit不能超过resources.limits.memory的配置，避免容器内容资源超限导致K8s杀掉logtail-ds。
如何定位
通过CloudLens For SLS 查看关键错误和文件、目录数超过上限问题（STAT_LIMIT_ALARM, DIR_EXCEED_LIMIT_ALARM）。在告警详情中会展示类似The polling stat count of this docker config has exceeded limit, current count: 25001 total count:25001 path: /var/log/toomany的字样。
解决方案
检查配置中日志路径是否合理，可以尽可能“精确”地设置日志路径，比如实际要采集的目录是/var/log/nginx/access.log，可以把路径配置成/var/log/nginx而不是/var或者/var/log。
如果目录中有很多轮转后的历史日志，可以定期删除或者设置轮转文件数量，定时删除不必要的目录和文件。
如果确实需要监听的目录或者文件数较多，通过以下步骤调大
mem_usage_limit。调大
kube-system命名空间下的配置项alibaba-log-configuration中配置的mem-limit
然后重新部署
kube-system命名空间下的守护进程集：logtail-ds来使mem_usage_limit生效。单个iLogtail配置支持的最大监听文件数是mem_usage_limit/100x5000。
注意：
容器场景可以使用K8s相关过滤条件，过滤掉不需要采集日志的容器，定位到真正需要采集的容器的日志文件，可以避免容器场景下类似问题。
业务日志输出配置建议
将日志文件存放在特定的目录中，与其他程序运行文件、库分开存放，使得iLogtail监听目录最小化。
输出日志文件时，采用轮转机制，设置一定的日志轮转数量，可以避免过多的历史日志文件占用磁盘，同时也可以减少监听的文件数。定期删除不必要的历史目录和文件。
日志打印目录层级树不要设置过多，目录层级尽量扁平化。
参考资料
极简模式设置采集黑名单：https://help.aliyun.com/document_detail/137903.html
日志服务采集数据常见的错误类型：https://help.aliyun.com/document_detail/89808.html
通过DaemonSet-控制台方式采集容器文本日志：https://help.aliyun.com/document_detail/66655.html
关于iLogtail
iLogtail作为阿里云SLS提供的可观测数据采集器，可以运行在服务器、容器、K8s、嵌入式等多种环境，支持采集数百种可观测数据（日志、监控、Trace、事件等），已经有千万级的安装量。目前，iLogtail已正式开源，欢迎使用及参与共建。
GitHub: https://github.com/alibaba/ilogtail
官网：https://help.aliyun.com/document_detail/65018.html
钉钉群：iLogtail社区
