补救 构建监控平台查看系统运行与SQL执行情况
关于系统的可观测性,有logs(日志),traces(跟踪),metrics(指标)。
系统频繁宕机,可能的原因有:1.慢sql;2.代码语法调用低级,如循环调用外部api;3.循环调用sql语句。
为了从系统情况和代码两个层面对系统进行监控,需要通过log,traces,metrics来监控系统。
此篇不是说明搭建,而是对系统排查的过程进行记录和总结,提供一些参考参考。
Prometheus、Grafana展示监控数据
在23年中下旬,遇到频繁宕机时,其中最严重的导致系统停机4、5个小时以上。当前公司内部只有ELK和Zipkin,可以查看细致的日志和调用链,但是无法查看系统当前的运行情况。所以搭建了指标系统,对服务器和重要服务进行监控。当发现系统负载较高是,可以排查到是具体的哪个服务产生了异常导致系统雪崩。进而可以使用zipkin和log进行细化排查。
logs 搭建ELK(Elastic Search、Logstash、Kibana)构建日志监控系统
在入职公司时,已经搭建了ELK系统,可以通过Kibana监控系统的日志,分析错误。
切换数据源为druid,监控慢sql
当系统宕机,只看到满屏的服务降级,没有办法找到改进的方向。当前系统使用的是springboot默认的数据库连接HikariCP。HikariCP的性能比druid好,但是功能没有druid强大,我们需要对sql进行监控来调优。对部分系统服务更换druid也没有产生性能问题,就把所有的系统进行了更换。更换druid后,可以打开druid的打印sql功能,通过日志监控sql执行情况,也可以通过druid提供的监控面板对慢sql进行排序。
通过此举,除了部分统计sql优化比较困难,其余的慢sql都得到了优化。
traces 使用Zipkin对调用链进行监控
除了优化sql外,代码因为个人能力,或者工期等原因,其中部分代码存在质量问题。
在入职公司时,已经搭建了zipkin,通过zipkin,可以查看调用时长最长的接口,再查看源码,寻找缓慢的原因。
如果肉眼无法查看到问题,可以通过arthas进行排查。
arthas 阿里开源的java诊断工具
arthas是阿里开源的java诊断工具,可以通过arthas对java应用进行诊断,包括查看方法调用,修改变量值,查看线程状态等。
通过arthas提供的IDEA插件,生成trace命令,查看长耗时的部分,再进行优化。
总结
通过新搭建的promutheus,结合已有的ELk和Zipkin。并且切换为druid连接池提供有意义的慢sql日志信息。结合arthas进行代码排查。