ELK规范使用

2020-05-29 00:00:00 字段规范日志研发格式

ELK的灵活性、使用场景，在很多文章中都有介绍，包括官方文档。当你看到这篇文章时，我假设你已经知道你要用ELK解决什么问题。

其实，正是ELK提供的灵活性，特别是早期提供的傻瓜式用法（schemaless），让很多人认为使用ELK没有任何约束。有些弊端在数据量小的时候没有感知，有些弊端在非精细化使用时也不会注意到。

这篇文档主要想讨论：在大规模使用下，需要注意的一些基本约定，这些约定对管理和使用体验上的价值。

日志的类型

很多同学其实没有想过这个问题，或者没有站着数据分析的维度去想过这个问题。数据化运营已经是如今互联网公司核心的能力之一。传统的公司，很多数据分析的数据都是来自数据库。而互联网公司，有大量的数据来自日志，量级可能是数据库的几十到上百倍。所以，从大的方面，日志至少分为两类：

1、业务日志

来自业务需求所做的埋点日志，这种日志类似数据库表，只是通过日志形式收集，提升效率。

2、研发运维日志

（1）研发同学分析系统性能指标等埋点日志

（2）研发同学诊断系统问题的Trace日志、各种开源软件等产生的系统日志

当把日志进行了分类之后，其实日志规范就很容易制定了，而且这样分也方便后续架构改进、容灾降级、故障评估等各种需求，因为毕竟业务日志是重要的。

日志收集的架构大同小异，每个组件也会随着需求不断迭代和优化，ELK基本pipeline如下：

用户把日志打到磁盘上，我们通过logstash从磁盘把日志实时的收集放入kafka。在kafka中的日志，平台会根据用户需求选择性的同步到hive和elasticsearch。同步到Elasticsearch的日志，用户可以实时检索和分析。

存放规范

根据上面的日志分类，对于两类日志，我们按照不同的路径存放，具体存放路径如下：

我们会使用{topic_name} 作为kafka上的topic_name和hive上的table_name；

对于第三方系统日志，如mysql，mongodb，redis等，如果能做变更好也按照研发运维日志规范存放，如果已经投产无法变更，目前只能做hardcode适配；

建议日志命名(topic_name)规则为：

{business_name}_{service_name}_{optional}

示例：

业务日志：bike_order_api

研发运维日志：bike_order_error

因为业务日志会动态增长，按照size切割并设置maxBackup可能因为日志量太大存在覆盖写问题。建议使用DailyRollingFileAppender，不限定单个文件大小。

预定义schema，统一使用json格式输出

分三种情况：

（1）应用程序主动打印的debug日志

必须遵循标准的规范日志格式，这样输出的日志易于通过字段过滤、聚合并追踪问题，需要stackTrace的只要把stack做format输出即可。格式如下：

log4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5level %logger{36} - %msg%n

相关文章