6.4.4 logstash配置

针对公司不同的日志类型,日志来源以及日志处理方式,logstash的配置也不同

1. app日志直接打kafka

app > kafka > logstash > elasticsearch > kibana

首先app将日志直接输出到kafka中,topic为gen_log_valid

然后由logstash从kafka中fetch日志,经过处理

最后sink到elasticsearch中保存,kibana中得以展现。

针对于不同语言的应用程序,打日志的手段不一样,但大致相同:

  1. 定义log formatter,将日志格式化为json

  2. 定义log appender,将日志输出一份到kafka

1.1. 考虑

  • 中间引入kafka作为broker,方便日志组件的运维,理论上只要保证kafka的可用性,日志就不会丢

  • 使用json作为日志格式只要有几方面考虑:

    • 便于做日志管理

    • 便于使用日志做业务方面的统计分析

    • 将日志规范提前,可以简化logstash的配置

    • elasticsearch原生就是文档类型的

    • 无需使用grok提取,解放logstash计算性能,也无需根据格式变更而变更logstash配置

  • app直接打kafka,如果app到kafka组件故障,有可能会影响业务,这完全看app对日志部分的处理逻辑

2. app日志打本地文件

其中kafka为可选组件

与1中的过程类似,差别就是通过log agent组件filebeat去收集app本地的日志,然后输出到kafka中。

2.1. 考虑

  • 相比于1,可以无需关心kafka appender,也就和kafka解关联,也算对app更少的侵入吧。

3. 其他日志

其他日志,比如syslog等,都有现成的配置,现成的grok规则配置

4. logstash关键配置示例

对于logstash的配置,这是使用按照日志流转阶段和插件类型组合命名配置文件,最终读取配置文件,会将配置合并。

4.1. kafka input实例

prod_output_es:

dev_output_es

prod_output_kafka_json

prod_output_kafka_plain

说明:

  • 打tag说明日志来源,日志类型等信息

  • codec决定如何解析输入流日志,很重要

如果只是单纯的想将kafkaA的日志流转到kafkaB,那么不要指定codec,这样日志内部的字段并不会被解析,也就不会符合其他filter或者output的条件。

4.2. kafka output示例

这里主要用于kafka之间的日志同步,对应的场景,就是国外kafka同步到国内kafka然后走日志校验流程。

说明:logstash会默认给流转的日志增加host以及时间戳,所以如果要保证原格式不动,需要提取message字段,另外如4.1.所说,kafka之间同步,codec不要指定,或者指定为plain。

4.3. filebeat input示例

用于接收filebeat直连logstash模式。

4.4. tcp input示例

用于接收tcp直连logstash模式,其中一个应用就是kong的日志收集,使用tcp log插件,不过需要注意的是kong日志中有个api.methods类型不一致的问题,会导致日志进不来。

5. logstash的其他配置文件

5.1. logstash.yml

说明:在5.x以后,还有一个queue相关的参数,默认为memory。如果设置为persisted,可以使用磁盘作为队列存储,算是kafka的简单实现吧,生产上使用过一段时间,故障重启时会因为队列问题起不来,随意就不使用了。另外我们前置kafka队列,已经算是一层缓冲了,所以在logstash上做缓冲也就可有可无了。

5.2. jvm.options

说明:主要是堆内存设置,按实际情况来,无规定。

5.3. /etc/default/logstash

说明:

有人说:装了jdk,还是没法启动logstash,什么问题?,配置文件里配置了JAVACMD,自装的位置不匹配,修改即可。

有人说:为啥我的CPU使用率nice部分很高,nice不是和优先级相关的吗?,首先需要理解nice cpu的含义,低优先级程序运行的cpu使用率,而该配置文件中,指定了LS_NICE="19",优先级很低。

最后更新于

这有帮助吗?