问题描述:
用户在SLS的控制台上查不到想要的日志
解决过程:
用户的日志会从写入ECS到被Logtail监控,到Logtail解析日志并上传到服务器最后被控制台上查询出来。一步步判断是哪一个环节出了问题,可以简单概括成:
1、检查中间的硬件链路是否OK
2、检查用户的文件是否实时产生,字符集是否正常(UTF-8)
3、检查Logtail对日志文件的监控、解析、往服务器发日志的过程里是否有环节出现问题
4、检查SLS服务器上是异常/用户操作错误导致其实有数据但查不到的情况
(1)链路整理检查。先检查硬件链路。工单一开始用户就提到心跳是正常的。核实了一下确实没问题,那这部分可以跳过。
(2)用户自己tail -f看一下的日志文件,确实实时产生。字符集用户也确认是UTF-8无误。
(3)检查Logtail
检查Logtail对日志文件的处理部分。这里的步骤比较多,但是都会把异常信息写到ilogtail.LOG里。所以可以先检查一下这个文件里面的内容。
(3.1)看到用户提供的日志里有一些配置成功后,SLS服务器下发给Logtail的关于配置的信息内容。这里就是之前提到的ECS对日志文件的监控配置的部分。
查看WARNING和ERROR级别的日志,发现有
[WARNING] [7271] Failed to get the file first line time:XXX
根据错误的日志,可以得知原因是首行匹配导致的。
(3.2)用户重新配置并解决首行的正则问题后,发现了新的报错:
[ERROR] [25549] file:/xxxx inclue in multi config
这个报错是因为ECS里一个日志文件只能同时被一个Logstore读取。
如果用户的一个日志会存在各种不同的日志,需要被不同的Logtail收集的话,建议把不同类型日志写入不同的日志文件。
(3.3) 这时虽然用户的日志能被收集到,但是监控日志发现有这样的报错:
end data fail, error_code:SLSWriteQuotaExceed error_message:Write quota exceed
从报错上可以判断是因为Logtail往服务器发数据的时候超过了限额导致的。目前SLS对外公测阶段是每个Project提供1M/分钟的流量。
如果流量大于这个会报错。因为用户确实有需要这么多,在和用户以及产品协商后,给调整到一个比较合适的流量限额。用户的问题解决。
总结一下这个排查没日志问题的思路,需要先检查是否是网络链路的问题。在确定心跳无问题且用户日志是无问题后,检查了Logtail的日志文件,根据不同的报错信息定位并解决问题。
SLS的问题不需要特别多的排查技巧,只要根据链路一步步排查即可。虽然查不到日志还有其他的原因导致的,但是绝大多数的原因都能通过观察Logtail的日志来解决。