「运维」和「研发」，谁是真正造成故障的始作俑者？（开发人员在运维阶段发现系统缺陷）

「运维」和「研发」，谁是真正造成故障的始作俑者？（开发人员在运维阶段发现系统缺陷）

事件

从图中，我们可以看到发生错误的详细 URL, 发生的时间，发生的次数，同类型错误出现的次数。通过这几个指标数据，可以分析出错误出现的频率，接下来，我们就可以通过查看提供的详细堆栈信息，来分析错误的具体原因了，如下图：

通过图中提供的跟踪详细，可以看到是字符串转换异常的错误，发生代码行是 UserServiceImpl:94 这个类中的 94 行代码报错，帮助使用者定位到出现错误的具体的代码行，这样解决问题就很简单了。

上图只是其中一种错误情况，我们接下来看错误列表中的其他错误，如下图:

通过上图，同样可以看到发生错误的详细 URL, 发生的时间，发生的次数，同类型错误出现的次数，及错误信息，从错误信息可以看出是 Redis 拒绝连接的错误，接着分析堆栈信息，如下图：

从图中可以看出是 ApplicationInstanceServiceImpl.java:66 这个类中的 66 行代码出了问题，接着去对应代码分析，最终定位出是 Redis 数据库的问题。

JVMs

JVMs 从内存，线程来分析 Application 的运行情况：

内存

Heap Memory Usage PS Gen Garbage Collection Class Count

这个四个角度来分析内存的使用情况和 GC 的回收时间及次数。

如果 Heap Memory Usage 和 PS Old Gen 的内存使用率比较多，我们可以选择扩大堆内存或者多个 JVM 堆内存独立采用负载均衡来解决。

线程

线程图展示了线程数量的动态变化，以及线程池中不同状态的线程分布。就可以很直观的分析出 Application 的并发线程的情况。