1.緩慢的響應時間

響應時間是日志數據最常見和最有用的性能，它能讓你知道請求是多長時間被系統響應的。例如Web服務器日志可以讓你洞察請求需要多久才能返回客戶端設備的響應。這時間可以包括采用web服務器背后的不同組件（應用服務器，數據塊）來處理請求的時間，因此它能夠即時查看到你的應用程序是如何運作的。從客戶端設備/ 瀏覽器記錄的響應時間能夠給你一個更全面的了解，因為它也捕捉在app/瀏覽器的頁面加載和網絡延遲時間。

一個好的測量響應時間的法則是1993年Jakob Nielsen發表的3響應時間的限制，這個法則在當下仍然是極具意義的。簡而言之，0.1秒的限制讓用戶覺得是系統的瞬間反應，1.0秒的限制用戶認為是保持不間斷的流動，10秒的限制保持用戶的注意力集中在對話。

緩慢的響應時間模式幾乎總是遵循以下模式：

• response_time>X

其中response_time是字段值，代表服務器或客戶端的響應；“X”是一個閾值。如果閥值超過了字段值，那么你的系統對于用戶來說是個非常糟糕的體驗。

2.內存問題和垃圾回收

內存溢出的錯誤對于系統來說可能是災難性的，由于資源的匱乏往往會造成應用程序的崩潰。因此，當這些事情發生的時候可以創建標簽并且生成警報通知。

內存溢出的問題可以成為垃圾回收的一個目標方向，以此來作為跟蹤方向并得到通知。內存不足的異常和內存泄露的區別在于主要系統的中斷和簡單重啟服務器之間的區別。

此外緩慢的垃圾回收也可能是用戶體驗緩慢的原因，在某些情況下垃圾的回收可能會導致應用程序的運行減緩并且阻塞，知道垃圾回收完成。

下面是用于識別上述列舉的內存相關問題的常見例子：

• 內存不足
• 超過內存限制
• 內存泄漏檢測
• java.lang.OutOfMemoryError
• System.OutOfMemoryException
• memwatch:leak: Ended heapDiff
• GC和統計數據

3.死鎖和線程問題

死鎖可能發生在很多情況下，并且對系統有很壞的影響。死鎖發生時，它不會讓你的系統完全的停止下來而是減緩。總之死鎖就是兩個互相競爭的進程同時等待對方完成。

大多數死鎖模式僅僅包含關鍵字“僵局”,但一些常見的模式遵循以下結構：

• "死鎖"
• "Deadlock found when trying to get lock"
• “處理申請時發生意外：死鎖”

4.資源使用率高（CPU/硬盤/網絡）

在很多情況下系統性能的放緩可能并不是任何大型軟件缺陷造成的，可能是一個簡單的系統上負載增加，但是沒有可用的資源來處理這個問題。

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

• metric=/CPUUtilization/ AND minimum>X
• cpu>X
• disk>X
• 磁盤處于或接近其容量
• 磁盤上沒有足夠的空間
• java.io.IOException異常：設備上沒有剩余空間
• 帶寬不足

5.數據庫查詢緩慢的問題

知道查詢失敗，這可能會有用，因為它識別你的請求只是可能回來時沒有相關的數據，從而幫助你確定數據庫中并沒有用戶需要的數據。然而更微妙的問題是用戶可以獲得正確的數據,但結果是花了很多時間來返回。

跟蹤慢速查詢讓你可以跟蹤你的數據庫查詢執行情況。查詢時間設定可接受的閾值，任何超出這些閾值時可以幫助你識別正在影響的用戶體驗。

實例模式：

• SqlException
• SQL超時
• 長查詢
• 慢速查詢
• 警告：查詢需要較長的時間超過X
• Query_time > X

總而言之，使用日志數據能夠很好地幫助大家識別自己系統存在的問題。