作者回复: 抱歉我没有材料来说明应该记录哪些日志。
不过我觉得你说的这些日志信息基本上涵盖了,如果要补充的话,我建议对于每一次用户的请求,在入口处生成一个唯一的请求编号,对于这次请求经过的所有服务,都统一带上这个唯一请求编号,以后定位问题是,根据请求编号,就可以快速的发现是在哪一个服务出现问题。这是我在实践中觉得特别有效的一个字段。
另外异常信息、错误堆栈非常有用,必须确保记录下来了。
其实具体要哪些信息,你可以站在故障排查和数据统计的角度思考,哪些信息是有帮助的,然后记录下来。
最重要是先搭建起来一套日志管理的体系,然后实际应用中逐步补充完善。
作者回复: 我觉得不必非要强行整合在一起,因为对于监控来说,理论上来说可以有多个数据源,我对Grafana不够熟悉,不太确认但我想应该可以同时获取展示来自InfluxDB和ES的数据。
你可以考虑以下方案(仅供参考,我没有验证过可行性):nlog的数据还是放在es,系统度量用appmetrices+influxdb+grafana,然后在grafana上集成其余的你想监控的从es查询的数据。
我有见过类似的架构:
wavefront(类似于grafana)获取metrices和ES查询的数据。
作者回复: 是的,基于日志有监控系统,可以直观从图表实时看到数据变化,会有自动报警。
数据量大不是问题,现在基于大数据的数据检索方案已经比较成熟了。
自动修复我不知道是不是有,目前应该还不成熟,也就是自动重启下服务,未来也许会有AI能直接处理线上故障吧:)
作者回复: 拿ELK来说,是在Logstash那一层做过滤和解析,必须现过滤和解析检索才能高效。
是的,如果系统很多很复杂,必须要链路跟踪是哪个环节出的问题。
作者回复: 感谢分享,已拜读。这一篇是关于如何搭建系统的,后续是不是还会有基于这个系统集成应用程序日志,以及对应用程序监控的文章?期待:)
作者回复: 谢谢分享👍
作者回复: 你可以搜索一下关键字:“ELK ElastAlert 报警”应该可以找到不少记录,比如说:
https://blog.51cto.com/seekerwolf/2121070
https://segmentfault.com/a/1190000017553282
作者回复: 我觉得应用程序的日志也应该考虑放进去,对排查问题很有帮助。
应用程序的异常信息、错误堆栈非常有用,必须确保记录下来了。
举个例子来说,你的一个手机App,一些特定场景下,某个API请求出错,而这个API可能背后会连接多个服务或者数据库,这样的场景下,光靠nginx日志是不够的,必须要有应用程序的日志配合才好定位。
你可以参考上一篇我提到了一个requestId的实践。
作者回复: 👍确实如此,因为这样的系统对于复杂应用的故障定位来说,太有用了太有必要了。