对于日志收集的客户端,其work pipeline通常包括三个过程:input,process,output。
input: 适配各类日志接入源,目前logtail支持文本文件、syslog(tcp流式)两种形式数据写入。
process:自定义日志处理逻辑,常见的有:日志切分、日志编码转换、日志结构化解析、日志过滤等等。
output:定义日志输出,例如logtail以http协议写数据到日志服务。
今天要介绍logtail在日志处理阶段的两个新功能:转码、过滤。
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsIyZlBnauMmNzMDMhR2MhhTM1EmNwcTZhFGO2MGNwYTYyE2M3ImMhNWN1gjZ3YzLcNXZslmZxl3Lc12bj5ycj5Wd5lGbh5Sdvhmen5WYo1ibj1ycz92Lc9CX6MHc0RHaiojIsJye.jpeg)
日志服务限制数据的字符编码为utf-8,这也是logtail在发送数据阶段对于字符编码的要求。
但可能一些较老的应用组件在处理中文的时候,会打印gbk编码的数据到日志文件。
这种情况下,你可以在logtail配置的高级选项中,选择日志文件编码为”gbk“。那么,logtail在采集日志时,会对日志内容先做gbk到utf-8的编码转换,再进行后续处理。
logtail目前支可以支持utf-8和gbk两种文件编码格式。对于gbk格式,logtail使用linux系统的iconv api,编码转换过程中会额外消耗机器计算资源。
问:如何判断我的gbk日志文件是否可以通过logtail收集? 答:在linux shell下使用iconv命令进行转码测试,假设日志文件名为gbk.log,执行命令:
iconv -f gbk -t utf-8 gbk.log -o gbk_to_utf8.log
如果执行成功则说明文件编码是gbk;如执行失败(类似iconv: illegal input sequence at position 2743错误),则说明文件不是合法的gbk编码,无法通过logtail做编码转换,请尝试调整应用输出的日志文件编码格式为utf-8。
举一个web服务器的例子,nginx每时每刻接收大量请求,并在access.log记录这些请求:
对于问题调查的场景,http 200请求的日志量通常是巨大的,如果我们希望降低日志存储的成本,只上传发生异常的请求日志,应该怎么来做呢?
在今天,你可以打开logtail配置的高级选项,设置过滤器来解决数据过滤的问题。
如上图所示,分别对url字段和status字段设置了两个过滤器。指定字段key存在且value符合正则表达式的日志会被保留。
定义多个过滤器的时候,判断条件是“与”的关系,满足所有过滤器设置的日志是合法的,否则被丢弃。
对于一条日志,当url字段与"(posts.)|(gets.)"匹配成功且status字段与"[345]d+"匹配成功的时候(只采集post、get请求且状态码非200的日志),logtail将该日志上传至日志服务,如下图所示:
如果设置过滤器的字段名在日志里找不到,那么这条日志也是不合法的,需要被丢弃。默认情况下,用户没有任何过滤器设置的情况下,所有被logtail读取并解析成功的日志数据都会写入日志服务。