最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

环球热头条丨【复盘】搭建日志平台的复盘与思考

来源:博客园
目录
  • 背景
  • 日志规范
  • 日志索引设计
  • 索引分片设计
  • 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就可以组成数据大盘,还可以配置相应的报警。

总结

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

关键词: 数据统计 系统信息