昨天排查生产问题,Kibana的这个时间设置让人很难受,虽然问题的根因还没有定位。今天我决定在家先把这种让人难受的问题先解决掉。一些系统还是用的ELK那套东西,新的已经迁移到SLS里面。网关时间戳GMT时间和Kibana的时间差16个小时,和东八区的时间差8个小时,应用程序写入到Kibana里面的时间是东八区时间。但是Kibana里面Index Pattern的时候差了16个小时。是怎么回事呢?
问题在于写入的@timestamp已经是东八区时间了,Kibana默认时间设置是根据浏览器里面的时区设置的。
Timezone for date formatting
Which timezone should be used. "Browser" will use the timezone detected by your browser.
Default: Browser
默认将通过浏览器获取当前系统时区,并在日志时间上加上这个时区,比如东8区,将在时间上加8小时再展示。而elasticsearch中的日志时间已经经过了时区处理,因此这里的默认处理方式,对以UTC时间记录的日志是正确的,而以本地时区时间记录的日志处理是错误的。
针对这个问题,可以在kibana的setting->advance中,将dateFormat:tz设置改为UTC/GMT即可。
开发为啥要关注这些运维问题?因为当前的模式采取的开发+运维的方式,你负责的系统你负责运维,云团队只提供基本的平台和技术支持,你需要多少服务器,你需要自己预算。刚开始对这种运维方式挺反感的,感觉这种方式安全度不高,开发可操作的空间比较大,容易让开发对生产的敬畏度不够。之前的工作方式就是开发和运维边界比较清晰,因为要去学习linux命令,学习怎么构建流水线和容器相关知识,这种运维方式也有自己的优势,每个团队的项目自己负责,运维只提供技术支持,减少了运维人员,开发可以更好的DevOps。整个DevOps都有整个团队负责,云团队给你提供“水电煤”。
研发流程就这么多,重要的是根据每个公司的现状,把每个节点要执行的过程,检查点和输出物确定完。再用信息化系统实现。高效的研发流程是确保高质量交付的关键。科学的方法+实践+激发人性的善才能让研发效率更高。