概述

之前搭建ELK时候经常听开发人员反馈说日志的数据和服务器的日志顺序不一致， 看日志给他们带来许多烦恼，这是什么原因导致呢？

问题分析：

kibana向es(elasticsearch)发送请求的时候默认排序为@timestamp字段，然而@timestamp字段的精度是毫秒， 也就是说如果同一毫秒内输出多条日志则在kibana展示的日志就会出现和服务器日志不一致的问题。

具体表现

这里其实只要大家仔细观察后就可以发现了：

查看前后消息：

这里类似数据库的order by timestamp desc ,offset asc,实际上里面代码也是这样写的，而这个问题在8.0版本已经做了修复，最新版本开发人员的改动也是把asc改成了desc而已。

这也就说明可能在timestamp不一致时可能某条本应该顺序的日志会跑到其他地方，这也是导致开发看日志比较费劲的原因。

4、是否可以自定义排序？

管理--高级设置--类别

这个参数决定timestamp的排序，不过surrounding documents里面的就定义不了了

5、总结

关于kibana日志排序总结如下：

1、建议将offset列与message列作为查询目标字段。

2、当日志并发量到达到一定程度时，会出现在同一个时间戳内存在多条日志记录的情况。默认情况下Kibana不能将日志排列为正确的顺序。

3、 FileBeat在提交日志时，会附带offset属性，即日志在文件中的读取位置。先读取的部份在文件前面offset值小，后读取的部份在文件后面offset值大。通过设置按offset升/降排序，可让上下文日志浏览界面，正确显示日志顺序。

登录系统后，管理→Kibana→高级设置→发现，将Tie breaker fields（平分决胜字段）设置为 offset 即可。

有如下几点要说明：

1、发现页面的首页列表，仍然存在相同时间戳内，日志间顺序不正确的问题。此设置仅针对上下文日志浏览界面有效

2、 上下文日志浏览界面，先按时间戳降序排，相同时间戳的数据按offset升序排，类似于sql里的 order by timestamp desc, offset asc。排序方向暂无法自定议。所以，当存在跨时间戳看日志时，当浏览完本时间戳日志时，要向上找到下一个时间戳日志，从其中的第一条开始看，才是连续的顺序。

3、在8.0版本的kibana中，已调整排列方式，时间戳与Tie breaker fields都可自定义排序方向。将不存在上述查询不便的问题

4、为了提升空间使用效率，日志文件采用了滚动生成策略，即每天一个日志文件。当从新的日志文件读取数据时，offset值会基于新文件重新计算。所以不能单纯依据offset完成跨天的统一排序。

5、在实际使用中，正常的使用方式是，先在发现的首页输入关键字查询，而后使用上下文功能查询周围的日志。很少出现需要查看的日志隶属于不同时间戳的情况。所以上述的不便并不影响实际的使用。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~