Bug地狱 #2 构建监控平台查看系统运行与SQL执行情况

补救 构建监控平台查看系统运行与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进行代码排查。