作者：友盟+U-APM 應用性能監控團隊
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分鐘制定告警計劃。