【复盘】搭建日志平台的复盘与思考

• 背景
• 日志规范
• 日志索引设计
• 索引分片设计
• ILM的使用
• 利用日志平台的数据统计
• 总结

背景

20年利用ELK为公司搭建一个日志平台，但由于那时技术和视野有限，遇到的问题感觉还可以有很多好的方式去解决，一直在心里耿耿于怀，所以平时遇到有相关经验的人都会聊一下设计细节，讨论一些解决方案，或者参考一些成熟的系统，思考其优化方向。
搭建文档：
基于ELK系统，搭建支持TB级别日志平台

日志规范

旧的平台日志采集的格式是极其不规范的，没有封装统一的底层日志SDK。各业务各自控制日志格式，导致所有的系统信息、业务信息全都封装成一个大的json串，有些日志一条能达到4M、5M，这种日志在采集、写es都是比较要命，平台花费很大的算力在json的解析上，由于es默认限制json的key是1000，理论上业务的key有无数个，所以这些日志就不可能展开写ES中。
规范的日志上报的key应该是固定个数并且都是非常重要且有意义的，在解析时可以展开存在es中
不规范

  "trace_id":xxxxxx,
  "uid":xxxxxx,
  "ip":xxxxxxx,
  "ai1":xxxxx,
  "ai2":xxxxx,
  "ai3":xxxxx
    ......
}

规范

  "trace_id":xxxxxx,
  "uid":xxxxxx,
  "ip":xxxxxxx,
  "msg":"{"ai1":xxxxx,"ai2":xxxxx,""ai3":xxxxx",......}"

这样就可以把系统信息和业务信息区分开来，如果有增加新的需要解析的字段，平台提供新的SDK供业务测升级。这种规范兼容性也很好msg可以是json格式，也可以直接是一行字符串(nginx的access.log)，后续的查询也会非常的规范。

日志索引设计

旧平台设计方式是有很多的索引，是以服务为单位每天一个索引

server-1-trace-20230227   server-1的trace日志
server-1-info-20230227     server-1的info日志
server-1-error-20230227    server-1的error日志 

同样在kibana查询时也需要创建很多的索引模式，但是由于我们有上百个服务，这样就会有上百个这样的索引。因为每个索引又有很多的分片，管理这些索引也需要很多的成本。
导致的问题：在跨天的时候由于新的索引没有建立，但是有很高的并发写，也就有很多并发创建索引的操作，由于只有master节点可以创建索引，所以这些请求都会转发到master节点导致master的崩溃。旧的解决方式是利用脚本在前一天晚上创建第二天的索引。
其实换个思路，我们为什么要设计这么多索引呢？这么多索引又需要创建很多的配套索引模式去查询。我们可以把服务信息、日志类型当作日志的一个字段，查询的时候按照条件进行查询就可以了
好的方案,只设计少量索引（或者是按照环境VM、POD）利用 rollover进行设计

索引：xxxx-vm-20230227-00000001 (后面是rollover自动添加)
{
    "app":"server-1",
    "log_filr":"/var/log/log_trace.log" ,
    "log_type":"trace",
    "msg":"xxxxx"
}
{
    "app":"server-1",
    "log_filr":"/var/log/log_info.log" ,
    "log_type":"info",
    "msg":"xxxxx"
}

查询时将app、log_type当作条件进行查询，也不需要创建那么多的索引模式。

索引分片设计

旧平台按照索引分片的算法50g数据/片，所以业务接入的时候要评估业务的数据量，然后给其创建相应的索引模版，分片数也要是节点的倍数，尽量保证其分片的均匀，例如我有20个节点，那我的分片数最好就是20、40、60这样。由于索引数量很多，分片数就有好几千个，每个节点上的分片也有很多。
导致的问题：节点之间的负载不均衡，每个节点上分片数大体一致，但是分片的IO请求差别很大，会导致有的节点负载很高，疯狂报警，有些节点几乎没有数据，导致资源浪费。
问题的根源还是索引设计不合理导致的，没有利用rollover进行滚动写入。可以设计索引模版使用滚动更新，每个索引固定分配20分片(节点数)，每个索引保存20*50G或者一天进行rollover

ILM的使用

索引生命周期管理(index lifecycle management，简称ILM)，是ES官方推出的自动管理索引周期的工具集

• Hot：热阶段，索引是活跃的同时支持更新及查询
• Warm：温阶段，索引不支持更新，但可以查询
• Cold：冷阶段，索引不支持更新，但只能少量查询
• Delete：删除阶段，索引可以安全删除
  由于之前的索引多、分片多导致在迁移过程中整个集群工作特别的繁忙，而且迁移时间很长。如果能合理的设计索引以及分片，利用ILM可以很好的节约成本。
  可以再使用ES的Force Merge、Freeze、Read-Only对日志进行更精细的管理。

利用日志平台的数据统计

很多公司的前置网关使用的都是nginx，可以采集acces.log日志单独的解析，单独的索引。作为流量入口这部分数据可以反映整体的流量状态，qps计算、各个入口的成功率等。
定制nginx的日志，接入grafana就可以组成数据大盘，还可以配置相应的报警。

总结

本文没有包含技术细节，只有设计方面的调整。回头看来，很多过程中发现的问题，利用技术手段解决起来很麻烦的事情，可能一开始就是设计的不合理。但是这方面的能力没法一蹴而就，我希望可以通过一步步的复盘和思考来提高这方面的能力。