日志数据分析的效果（让你轻松分析系统性能）(1)

1.缓慢的响应时间

响应时间是日志数据最常见和最有用的性能，它能让你知道请求是多长时间被系统响应的。例如Web服务器日志可以让你洞察请求需要多久才能返回客户端设备的响应。这时间可以包括采用web服务器背后的不同组件（应用服务器，数据块）来处理请求的时间，因此它能够即时查看到你的应用程序是如何运作的。从客户端设备/ 浏览器记录的响应时间能够给你一个更全面的了解，因为它也捕捉在app/浏览器的页面加载和网络延迟时间。

一个好的测量响应时间的法则是1993年Jakob Nielsen发表的3响应时间的限制，这个法则在当下仍然是极具意义的。简而言之，0.1秒的限制让用户觉得是系统的瞬间反应，1.0秒的限制用户认为是保持不间断的流动，10秒的限制保持用户的注意力集中在对话。

缓慢的响应时间模式几乎总是遵循以下模式：

其中response_time是字段值，代表服务器或客户端的响应；“X”是一个阈值。如果阀值超过了字段值，那么你的系统对于用户来说是个非常糟糕的体验。

2.内存问题和垃圾回收

内存溢出的错误对于系统来说可能是灾难性的，由于资源的匮乏往往会造成应用程序的崩溃。因此，当这些事情发生的时候可以创建标签并且生成警报通知。

内存溢出的问题可以成为垃圾回收的一个目标方向，以此来作为跟踪方向并得到通知。内存不足的异常和内存泄露的区别在于主要系统的中断和简单重启服务器之间的区别。

此外缓慢的垃圾回收也可能是用户体验缓慢的原因，在某些情况下垃圾的回收可能会导致应用程序的运行减缓并且阻塞，知道垃圾回收完成。

下面是用于识别上述列举的内存相关问题的常见例子：

3.死锁和线程问题

死锁可能发生在很多情况下，并且对系统有很坏的影响。死锁发生时，它不会让你的系统完全的停止下来而是减缓。总之死锁就是两个互相竞争的进程同时等待对方完成。

大多数死锁模式仅仅包含关键字“僵局”,但一些常见的模式遵循以下结构：

4.资源使用率高（CPU/硬盘/网络）

在很多情况下系统性能的放缓可能并不是任何大型软件缺陷造成的，可能是一个简单的系统上负载增加，但是没有可用的资源来处理这个问题。

在分析资源使用模式的示例使用：

5.数据库查询缓慢的问题

知道查询失败，这可能会有用，因为它识别你的请求只是可能回来时没有相关的数据，从而帮助你确定数据库中并没有用户需要的数据。然而更微妙的问题是用户可以获得正确的数据,但结果是花了很多时间来返回。

跟踪慢速查询让你可以跟踪你的数据库查询执行情况。查询时间设定可接受的阈值，任何超出这些阈值时可以帮助你识别正在影响的用户体验。

实例模式：

总而言之，使用日志数据能够很好地帮助大家识别自己系统存在的问题。

本站文章除注明转载外，均为本站原创或翻译

,