内容简介:团队日志经过规范化后,接下来就需要一个采集方案。本文主要是分享我们团队的方案,供有相同需求的同行参考一下,希望对部分人有所帮助或者启发。本文是接着上一篇讲的,需要了解日志规范化相关内容的,请移步上一篇文章。虽然现在已经进入容器化时代,filebeat, fluentd在私有云环境应用比较多,但是我们当时还没有容器化,所以我们选择了nxlog,目前实践下来,nxlog出色的完成了这个任务。使用下来,总结nxlog优秀的特性如下:缺陷(社区版):
日志采集落地方案
问题背景
团队日志经过规范化后,接下来就需要一个采集方案。本文主要是分享我们团队的方案,供有相同需求的同行参考一下,希望对部分人有所帮助或者启发。本文是接着上一篇讲的,需要了解日志规范化相关内容的,请移步上一篇文章。 日志规范化落地方案
采集端-nxlog
虽然现在已经进入容器化时代,filebeat, fluentd在私有云环境应用比较多,但是我们当时还没有容器化,所以我们选择了nxlog,目前实践下来,nxlog出色的完成了这个任务。使用下来,总结nxlog优秀的特性如下:
- 高性能,低消耗,稳定
- 多平台支持(因为我们是C#,java混合环境)
- 强大灵活的脚本语言
缺陷(社区版):
- 单条日志大小有限制
- 无法统计关键指标
总体来说够用。下面以我们自己的日志格式为例,给出对应的nxlog配置主体部分。
<Extension syslog>
Module xm_syslog
</Extension>
<Extension json>
Module xm_json
</Extension>
#========================================================================
#applog
##======================================================================
<Extension applog_layout>
Module xm_csv
Fields $LogAt, $TraceId, $Department, $Team, $Project, $Host, $ServerIP, $ContextPath, $UriStem, $QueryString, $FormString, $UserAgent, $Level, $Class, $Method, $MethodParams, $Line, $Logger, $IOType, $ExceptionType, $ExceptionMessage, $CustomMessage, $StackTrace, $HawkKey
FieldTypes string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string
Delimiter \t
QuoteChar '"'
EscapeControl TRUE
QuoteMethod All
UndefValue ''
</Extension>
<Extension applog-multi>
Module xm_multiline
HeaderLine /^"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.+/
</Extension>
<Input applog_in>
Module im_file
File '/data/project_*.log'
SavePos TRUE
InputType applog-multi
Exec applog_layout->parse_csv();
Exec to_json();
</Input>
<Input auth_applog_in>
Module im_file
File '/data/auth/project_*.log'
SavePos TRUE
InputType applog-multi
Exec applog_layout->parse_csv();
Exec to_json();
</Input>
<Output applog_out>
Module om_tcp
Host [your_host]
Port [your_port]
</Output>
<Route applog>
Path applog_in,auth_applog_in => applog_out
</Route>
我们日志格式是tab符分割的csv格式,这个配置主要做了如下几件事。
- 多行文本合并
<Extension applog-multi>
Module xm_multiline
HeaderLine /^"\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.+/
</Extension>
- csv格式解析
<Extension applog_layout>
Module xm_csv
Fields $LogAt, $TraceId, $Department, $Team, $Project, $Host, $ServerIP, $ContextPath, $UriStem, $QueryString, $FormString, $UserAgent, $Level, $Class, $Method, $MethodParams, $Line, $Logger, $IOType, $ExceptionType, $ExceptionMessage, $CustomMessage, $StackTrace, $HawkKey
FieldTypes string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string, string
Delimiter \t
QuoteChar '"'
EscapeControl TRUE
QuoteMethod All
UndefValue ''
</Extension>
- 转化为json
Exec applog_layout->parse_csv(); Exec to_json();
- 通过tcp发送出去
<Output applog_out>
Module om_tcp
Host [your_host]
Port [your_port]
</Output>
接收端-logstash
日志接收端,我们使用的是logstash,logstash的优点是配置灵活强大,性能也不差,但是资源吃的比较厉害。但是因为我们还是比较富的,这点资源还不是事儿。下面给出logstash日志接收端的配置。我们使用的logstash版本为2.4.1,其他版本需要自己测试并修改适配。
input {
tcp {
type => "applog"
codec=> json
port => [your_port]
}
}
filter {
mutate {
convert => {
"Line" => "integer"
}
uppercase => [ "Level" ]
lowercase => [ "Department", "Team", "Project", "Host", "ContextPath", "UriStem" ]
}
}
output {
elasticsearch {
hosts => ["127.0.0.1:9200"]
index => "applog-%{+YYYY.MM.dd}"
}
}
上面的配置直接把日志写入es,在初期一般没啥问题,但是日志越来越多,日志系统越来越重要的时候,先写入kafka会是一个非常明智的做法,这样修改一下output部分的配置即可。
output {
if [Level] == "WARN" or [Level] == "ERROR" or [Level] == "FATAL" or [Level] == "WARNING" or [Level] == "EROR" {
kafka {
codec => json
topic_id => "project_error_log"
client_id => "client_id"
bootstrap_servers => "127.0.0.1:9092,127.0.0.2:9092"
retries => 2
}
} else {
kafka {
codec => json
topic_id => "project_info_log"
client_id => "client_id"
bootstrap_servers => "127.0.0.1:9092,127.0.0.2:9092"
retries => 2
}
}
}
这里更进一步将错误日志和info日志分开采集到不同的队列,主要是考虑错误日志比较重要,实时性要求高于一般info日志,同时错误日志数量比一般info日志少很多,分开消费可以保证error日志能及时的采集并消费到es,对于错误监控和问题排查有重大的意义。当然,只有日志到达一定量的时候,你才需要考虑这么做,初期都写到一个队列就可以了。
然后,简单的做法是直接写 java 消费kafka的程序批量写入es。如果条件允许,最好可以用spark,storm,flink任何一个实现这部分。注意一定要批量写入es,不然写入速度会很慢。
这样程序日志规范化和采集已经完成了,日志已经可以用kibana直接查看了。 程序日志采集已经完成,后面会继续介绍我们如何实现日志查询分析和监控。
其中我们的日志监控系统已经开源,有需要的话,欢迎使用: frostmourne(霜之哀伤日志监控系统)
关于内部日志系统的设计实现感兴趣的话,请移步文章: 之家经销商技术部基于Elasticsearch的日志系统设计与实现
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- F5大中华区首席技术官吴静涛:无探针实时应用大数据采集引擎落地实践和AIOps实现
- 图片采集的方向问题
- Kubernetes 下日志采集、存储
- 如何批量采集网页表格数据?
- 前嗅ForeSpider教程:采集CSDN
- Audio Unit采集音频实战
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
断点:互联网进化启示录
[美]杰夫·斯蒂贝尔 / 师蓉 / 中国人民大学出版社有限公司 / 2014-11-1 / CNY 49.00
一部神经学、生物学与互联网技术大融合的互联网进化史诗巨著。 我们正置身网络革命中。互联网的每一丝变化都与你我息息相关。当科技变得无处不在时,它就会改变你我。在《断点》一书中,大脑科学家和企业家杰夫·斯蒂贝尔将带领读者来到大脑、生物与技术的交汇处,向读者展示生物学和神经学是如何与互联网技术发生联系的;我们是如何通过生物学上的前车之鉴,来预测互联网的发展的;互联网在经历增长、断点和平衡后又会发生......一起来看看 《断点:互联网进化启示录》 这本书的介绍吧!