Why? 爲什麼要做應用性能監控？
首先，我們要知道應用性能監控具體指什麼？以及目的：
監控是一套完整的“監視+報警”的系統。對於像我們這樣的App開發者來說，應用性能監控是衡量App的第一道關卡，如果應用的質量不好，會給用戶帶來最直接的體驗傷害。App上線後，開發者是無法7*24實時獲取到用戶使用及體驗情況的，這時就需要一套優質的監控工具。
那麼，我們到底需要監控哪些指標？
安卓和iOS的客戶端監控指標就有很多不同，比如說安卓需要的是Java、Native、ANR錯誤等等，iOS需要的是Objective-C、Swift、C++層的錯誤等等。
在定義錯誤指標上，最基礎的是不同類型的錯誤數，如果考慮到錯誤數與整體應用使用量的對比，可以考慮用比值的方式，比如可以定義錯誤率：
總結下來，我們可以統計不同類型錯誤在某一個時間範圍內的錯誤數、錯誤率、影響用戶數、影響用戶佔比等指標。在指標的細化分類上，我們還可以用不同的維度定義監控，比如版本號。
如果要關注錯誤的發生次數，及錯誤的影響用戶數，則可以在錯誤數的基礎上，根據用戶排重計算得來影響用戶數。
如何定義獨立用戶呢？我們可以考慮用設備ID辨別，比如imei、idfa、AndroidID等等，如果這些信息很難獲取，也可以使用業務上的用戶ID，比如登錄賬號，會員名等。除此之外，使用第三方SDK提供的設備識別定義ID也是個不錯的選擇。在使用這類ID排重後，就可以得到錯誤的影響用戶數。
如果我們已知錯誤的影響用戶數，但無法確定它的影響範圍佔比，則可以看以下這個指標：
總結下來，我們可以統計不同類型錯誤在某一個時間範圍內的錯誤數、錯誤率、影響用戶數、影響用戶佔比等指標。在指標的細化分類上，我們還可以用不同的維度定義監控，比如版本號。
How? 如何靈活地制定屬於你的告警計劃？
我們先請您做個小測驗來判斷下您的監控告警類型（一共5道題，僅需1.5分鐘）
規則如下：A選項記5分，B選項記10分，C選項記15分，D選項記20分
Q1: 請問您的產品目前處於什麼階段？
A： 已經上線，處於比較穩定的狀態，對監控告警的需求較低
B： 還在開發階段，需要捕捉一些測試中的錯誤，對監控告警的需求一般
C： 剛剛上線，整體來說比較穩定，對監控告警的需求較高
D： 剛剛上線，效果未知，非常需要7*24小時實時關注，對監控告警的需求非常高
Q2: 請問您在您的公司/部門的職務是什麼？
A：領導者，關注應用的質量做得如何
B：運維人員，負責監控整體應用性能的線上問題監督官
C：測試人員，負責應用發版前的質量把控
D：安卓/iOS端的客戶端開發人員
Q3: 請問您所屬團隊有多少人在關注應用性能質量，並參與其中呢？
A: 1，光桿司令幹活靠自己
B：2～5人，小型開發團隊
C：6～25人，相互打配合，一起優化應用質量
D：25+，超大型的開發團隊，不謙虛的說算是行業龍頭
Q4: 您日常關注哪些應用性能監控指標：
A: 最基本的錯誤數就可以
B：考慮到客戶端影響的用戶使用範圍，在上述的基礎上需要監控影響的用戶數以及佔比
C：在上述的錯誤數以及影響用戶的基礎上，還要考慮各個版本的分佈
D：需要制定組合型的告警規則：比如：錯誤數>100且錯誤率>1%或者影響用戶數比1天前多1%時觸發告警，也要考慮版本分佈
Q5: 請問您對告警的通知方式有精細化設置的要求麼？
A：沒什麼要求，只要能收到就行
B：在時間上有一些要求，半夜不想被打擾
C：在通道上有一些要求，需要郵件或者特定的辦公聊天軟件
D：對時間和觸達通道都有要求
What？那麼如何設置告警計劃呢？
以上的分加總，請先判定下您的測驗總分（A選項記5分，B選項記10分，C選項記15分，D選項記20分），來看您的App在下面哪個監控告警需求等級範圍內：（數據在哪個範圍？還是監控告警在哪個層級？）
熱血青銅（25～50分）：您屬於監控告警的初級階段使用者，您在日常工作中無需非常精細地查看各種錯誤的發生狀態。可能是由於您的應用還在初始階段，或者您位高權重，無需親自修復告警信息，只需要整體監控就好。請查看下文中的方案1
英勇黃金（50～75分）：您屬於監控告警的中級階段使用者，您或者您的團隊已經有了監控告警的意識，並且在日常工作中會關注到實時的應用質量情況。您已經可以用一定精細化的規則設置告警了，請跳轉至方案2
榮耀王者（75～100分）：您已經屬於監控告警的高能玩家了，只需要一點點引導，就可以成爲監控告警界的“超級王牌”了
根據上述測驗的分值高低，您可以判別您所需要的告警設置的難易，整體分爲下面幾個方案，實現程度由易到難。如果您想學習最全面的告警設置功能，請直接跳轉到方案3哦
方案1：簡易型--整體應用質量監控
作爲最初級的告警設置，您只需要考慮兩個問題：
a. 我應該在什麼情況下收到告警？
b.我如何能收到應用告警消息呢？
解決第一個問題，您可以考慮最簡單的狀態，只要有錯誤我就要收到預警，那麼只要設置錯誤數>0的條件就可以解決。如果您覺得這樣被打擾的非常多，可以根據自身的應用情況，設置錯誤數>xx個這類的告警規則
解決第二個問題，您需要有一個可以接收消息的媒介，最簡單的就是郵箱：
一個簡單的監控告警計劃就這樣設置好了
方案2：進階型--精細化應用質量監控
您已經可以對單一應用設置不同的告警消息了，可以按照監控的指標類型或者版本進行區分。比如說，我們對新上線的版本要求是，影響用戶數>10則觸發告警，對老版本的要求是整體錯誤率相比於上週增幅不超過5%就可以，那麼我們就可以按照如下的方式設置：
a.新版本的告警規則：
b.老版本的告警規則：
在這個方案中，我們分別應用了閾值型和對比型的告警觸發條件，這兩種規則的定義如下；
閾值型規則
您可以選擇一種指標（錯誤數、錯誤率、影響用戶數、影響用戶佔比），並且選擇「大於」某值或者某百分比
對比型規則
您可以選擇一種指標（錯誤數、錯誤率、影響用戶數、影響用戶佔比），並且選擇「比」歷史的時間段，增加多少比例，計算方式爲：（過去1小時數值-歷史1小時數值）/ 歷史1小時數值，大於或等於所選值即發送告警
方案3: 王者型--組合式指標監控
您已經可以非常熟練的設置監控告警了，那麼通過下面的hints，相信您可以根據您的日常工作需求，靈活制定屬於您的告警計劃
a. 靈活設置告警生效時間：
您可以添加告警生效的時間段，比如每週一至週五的9點至19點，週末的一12點至20點，靈活設置您的工作時間，不被無效信息干擾
b.重點錯誤類型/單條錯誤告警
您可以選擇需要您重點關注的錯誤類型
或者直接針對某一條修復中的錯誤進行持續關注告警
c. 組合形式的告警觸發條件
您可以通過多種指標以及閾值型或者對比型的規則，以交集/並集的組合方式，靈活設置您想要的告警觸發條件
d.多種告警觸達渠道
如果您還對監控告警的觸達渠道有所要求，可以考慮使用公司的辦公軟件進行羣觸達，與您同組的其他同事一起關注並修復應用問題。
在此方案中提到的所有監控告警設置功能，可以通過U-APM體驗，2分鐘制定告警計劃。
本文爲阿里雲原創內容，未經允許不得轉載。