1.緩慢的響應(yīng)時間

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

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

緩慢的響應(yīng)時間模式幾乎總是遵循以下模式：

• response_time>X

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

2.內(nèi)存問題和垃圾回收

內(nèi)存溢出的錯誤對于系統(tǒng)來說可能是災(zāi)難性的，由于資源的匱乏往往會造成應(yīng)用程序的崩潰。因此，當(dāng)這些事情發(fā)生的時候可以創(chuàng)建標(biāo)簽并且生成警報通知。

內(nèi)存溢出的問題可以成為垃圾回收的一個目標(biāo)方向，以此來作為跟蹤方向并得到通知。內(nèi)存不足的異常和內(nèi)存泄露的區(qū)別在于主要系統(tǒng)的中斷和簡單重啟服務(wù)器之間的區(qū)別。

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

下面是用于識別上述列舉的內(nèi)存相關(guān)問題的常見例子：

• 內(nèi)存不足
• 超過內(nèi)存限制
• 內(nèi)存泄漏檢測
• java.lang.OutOfMemoryError
• System.OutOfMemoryException
• memwatch:leak: Ended heapDiff
• GC和統(tǒng)計數(shù)據(jù)

3.死鎖和線程問題

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

大多數(shù)死鎖模式僅僅包含關(guān)鍵字“僵局”,但一些常見的模式遵循以下結(jié)構(gòu)：

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

4.資源使用率高（CPU/硬盤/網(wǎng)絡(luò)）

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

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

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

5.數(shù)據(jù)庫查詢緩慢的問題

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

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

實例模式：

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

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