使用日志数据分析系统性能的5种方法


最近,我们查看了一些最常见的行为,这些行为是我们由25,000个用户组成的社区在他们的日志中查找的,特别关注web服务器日志。事实上,我们的研究确定了由我们的客户创建的前15个web服务器标签和警报--您可以在我们的community insights部分-您还可以根据模式轻松地创建标记或警报,以识别系统中的这些行为。

本周我们关注的是使用日志数据进行性能分析。再一次,我们查看了25,000多个用户的社区,确定了人们使用日志数据分析系统性能的5种方式。一如既往,客户数据被匿名化,隐私受到保护。在接下来的一周中,我们将深入到这些领域中的每一个更详细的内容,并将以客户如何使用日志来帮助识别和解决其系统中的此类问题的第一手帐户为特色。Top Uses of Log Data for System Performance

我们的研究查看了社区中超过200k个模式,以确定日志数据中的重要事件。特别关注与性能相关的问题,我们确定以下5个领域为用户群中的趋势和常见领域:

1.响应时间慢:响应时间是日志数据中最常见,最有用的性能度量之一。它们可以让您立即了解请求需要多长时间才能被返回。例如,web服务器日志可以让您了解请求向客户端设备返回响应所需的时间。这可能包括web服务器(application servers,DBs)后面的不同组件处理请求所花费的时间,以便能够立即查看应用程序的执行情况。从客户端设备/Broswer记录响应时间可以为您提供一个更加完整的画面,因为它还可以捕获应用程序/浏览器中的页面加载时间以及网络延迟。

测量响应时间的一个好的经验法则是follow the 3 response time limits 正如Jakob Nielsen在1993年发表的关于“可用性工程”的文章中所概述的那样,这在今天仍然适用。简而言之,0.1秒是让用户感觉到系统立即做出反应的极限,1.0秒是让用户的思想流动不被打断的极限,10秒是让用户的注意力集中在对话上的极限。

慢响应时间模式几乎总是遵循以下模式:

  • RESPONSE_TIME>X

其中response_time是表示服务器或客户端响应的字段值,'X'是阈值,如果超过该阈值,则希望突出显示事件或发送通知,以便您和您的团队意识到某人的用户体验不佳。

2.内存问题和垃圾回收:当Outofmemory错误发生时,它们可能是非常灾难性的,因为它们通常会导致应用程序由于缺乏资源而崩溃。因此,您希望在这些事件发生时了解这些事件,建议您在这些事件发生时创建标记并通过警报生成通知。

然而,outofmemory问题的一个领先指标可能是您的垃圾回收行为,因此跟踪该行为并在堆使用空间与空闲空间超过特定阈值时获得通知,或者垃圾回收花费了很长时间,这可能特别有用,并且通常可以向您指出内存泄漏的方向。在内存不足异常之前识别内存泄漏可能是主要系统中断和简单的服务器重新启动直到问题得到修补的区别。

此外,垃圾回收速度慢或时间长也可能是用户体验应用程序行为慢的原因之一,因为在垃圾回收过程中,系统会减慢速度,或者在某些情况下会阻塞,直到垃圾回收完成(例如,使用“停止世界”垃圾回收)。

下面是一些常见模式的示例,用于识别上面概述的一些内存相关问题:

  • 内存不足
  • 超过内存限制
  • 检测到内存泄漏
  • java.lang.OutOfMemoryError
  • System.OutOfMemoryException
  • MemWatch:Leak:Ended heapDiff
  • GC和stats

3.死锁和线程问题

死锁可能以多种形状和大小出现,当它们发生时,可能会产生非常糟糕的影响--从使系统完全停止到简单地减慢它的速度,无处不在。简而言之,僵局是两个或多个相互竞争的动作都在等待另一个完成的情况,因此双方都没有完成。例如,我们说一组进程或线程是死锁当每个线程都在等待只有集合中的另一个进程才能导致的事件时。

毫不奇怪,死锁是我们的五大性能相关问题之一,我们的用户编写模式来在他们的系统中检测这些问题。

大多数死锁模式只包含关键字'deadlock',但一些常见模式遵循以下结构:

  • “死锁”
  • ‘尝试获取锁时发现死锁’
  • ‘处理请求时发生意外错误:死锁;’

4.资源使用率高(CPU/磁盘/网络)

在许多情况下,系统性能的减慢可能不是由于任何重大软件缺陷造成的,而是由于系统上的负载不断增加,但却没有更多的可用资源来处理这一问题。例如,跟踪资源使用情况可以让您看到何时需要额外的容量,以便启动更多的服务器实例。

分析资源使用时使用的示例模式:

  • Metric=/cpuutilization/和最小值>X
  • CPU>X
  • 磁盘>X
  • 磁盘已达到或接近容量
  • 磁盘空间不足
  • java.io.IOException:设备上没有剩余空间
  • 带宽不足

5.数据库问题和查询速度慢

了解查询失败的时间非常有用,因为它允许您识别请求返回时可能没有相关数据的情况,从而帮助您识别用户何时没有获得他们需要的数据。然而,更微妙的问题可能是,当用户得到正确的结果,但结果需要很长时间才能返回时,尽管技术上系统可能很好,没有bug,但用户体验缓慢可能会损害您的顶行。

跟踪慢速查询允许您跟踪DB查询的执行情况。为查询时间设置可接受的阈值,并报告任何超出这些阈值的内容,可以帮助您快速识别用户体验何时受到影响。

示例模式:

  • SQLException
  • SQL超时
  • 长查询
  • 慢速查询
  • 警告:查询花费的时间超过X
  • Query_time>X

一如既往,如果您认为我们遗漏了您喜欢在日志中跟踪的任何重要问题,请告知我们。要开始跟踪您自己的系统性能,create a free account 并包括上面列出的这些模式,以自动创建与您的系统相关的标记和警报。