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

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

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

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

• response_time>X

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

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

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

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

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

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

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

3.死鎖和線程問題

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

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

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

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

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

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

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

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

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

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

實(shí)例模式：

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

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