松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

ARTS-16-什么是應用性能監控APM

博客首頁文章列表 松花皮蛋me 2019-06-30 17:27

ARTS的初衷

Algorithm: 主要是為了編程訓練和學習。

Review:主要是為了學習英文

Tip:主要是為了總結和歸納在日常工作中所遇到的知識點。學習至少一個技術技巧。在工作中遇到的問題,踩過的坑,學習的點滴知識。

Share:主要是為了建立影響力,能夠輸出價值觀。分享一篇有觀點和思考的技術文章

https://www.zhihu.com/question/301150832

一、Algorithm

Top K Frequent Elements

Given a non-empty array of integers, return the k most frequent elements.

Example 1:

Input: nums = [1,1,1,2,2,3], k = 2
Output: [1,2]
Example 2:

Input: nums = [1], k = 1
Output: [1]
Note:

You may assume k is always valid, 1 ≤ k ≤ number of unique elements.
Your algorithm’s time complexity must be better than O(n log n), where n is the array’s size.

class Solution {
    public List<Integer> topKFrequent(int[] nums, int k) {
        //桶排序,注意:桶長要比原數組長度大一
        List[] buckets = new List[nums.length+1];
        Map<Integer, Integer> counts = new HashMap<>();
        for(int num:nums) {
            counts.put(num,counts.getOrDefault(num,0)+1);
        }
        for (int num:counts.keySet()) {
            int count = counts.get(num);
            if(buckets[count]==null) {
                buckets[count] = new ArrayList();
            }
            buckets[count].add(num);
        }
        List<Integer> ans = new ArrayList<>();
        //從后往前找top k,i>=1 &amp;&amp; ans.size<k
        for (int i=buckets.length-1;i>=1 &amp;&amp; ans.size()<k;i--) {
            if(buckets[i]!=null) {
               ans.addAll(buckets[i]);
            }
        }
        return ans;
    }
}

二、Review

以前的異常排查不管是通過發臨時包、在線調試、QA復現,受多因素的影響,復現排查都麻煩,所以催生了應用性能監控APM。APM是負責監控和管理用戶體驗的工具,它不像崩潰報告僅僅收集錯誤信息。主要有兩種收集和呈現數據的方式:代碼級數據、Metric監控數據。代碼級數據就是通過在軟件中使用探針和事務跟蹤獲取到生產信息,這種方式綜合性強

確保服務是啟動運行狀態還遠遠不夠,響應變得緩慢發生的頻率遠高于程序崩潰,所以需要快速了解清楚問題是如何發生的。APM工具可以幫助開發團隊快速了解一些常見問題,比如立即了解任何應用程序問題的根本原因,包括導致問題的確切代碼行、方法、數據庫或者具體的API調用,又或者了解并比較新版本部署對關鍵指標的影響,代碼變化所引入的新問題和對性能的影響,還有APM可以幫助我們跟蹤整體訪問和流量高峰情況

APM就是利用數據來理解問題發生的原因,并盡可能提供最佳的用戶體驗,整個公司團隊都從中受益,不管是在部署前、生產,還是部署后階段。開發團隊可以通過APM了解到軟件質量,并提供更好的用戶體驗,測試團隊可以通過APM進行壓力負載測試并確保整個產品的一致性,運維團隊可以通過APM進行性能監控,產品團隊可以通過APM獲得用戶對新功能的歡迎程度反饋,業務負責人可以通過APM跟蹤關鍵業務情況,如果有任何影響到業務增長的問題,他們會在第一時間得到,平均恢復時間MTTR因為性能問題得到更快修復而降低

APM服務收集了相當龐大的數據,但團隊需要的是可操作的見解而不僅僅是報告,下面是一些常見的功能

1、完整的堆棧信息

了解清楚到底發生了什么才能更直接有效地處理問題

2、服務監控

基礎性能監控CPU使用率、CPU平均負載、內存是必不可少的,依賴服務(如Mysql、Redis、Elasticsearch)調用時延(TP99)監控也很重要

3、事務跟蹤

事務跟蹤中如何翻譯資源ID、記錄點擊事件是關鍵,不管采用何種編譯插樁技術進行事務跟蹤,都要保證自身的低性能消耗,絕不能拖慢服務本身

4、部署跟蹤

通過部署跟蹤確保所做的更改不會對頁面性能產生負面影響,不要等到用戶來反饋這些錯誤

5、數據可視化

走勢、分布情況、火焰圖等等圖表,以更易于理解的格式呈現,也方便我們進行共性分析

6、靈活的告警

基于基線或者閥值的異常檢測,然后通過不同渠道反饋到干系人

7、真實用戶監控

真實用戶監控可以幫助我們了解下面類似問題:用戶加載響應差的具體頁面是哪個、是什么原因導致了用戶的問題、用戶遭遇問題前的關鍵訪問路徑是什么、整個活動會話訪問都是異常的還是個別頁面異常、用戶設備情況和網絡上傳下載速度(比如SSL建鏈\首包時間)和LBS定位

?-¤?????????alt?±???§??o??o??????????????oReal_User_Monitoring.png

8、崩潰報告

無日記信息的異常、只有系統日記的異常、被截斷的異常對我們毫無意義,APM需要提供錯誤前后上下文,完整的方法調用堆棧信息和環境變量

翻譯自:https://medium.com/@raygunio/what-is-application-performance-management-9610315fd63

三、Tip

Kafka無消息丟失配置

1、不要使用producer.send(msg),而要使用producer.send(msg,callback)
2、設置acks = all,表明所有副本Broker都要接收到消息才算已提交
3、設置重試參數retries一個較大的值
4、設置unclean.leader.election.enable=false,避免落后太多的Broker參考leader的競爭
5、設置replication.factor>=3,表明消費保存份數
6、設置min.insync.replicas>1,表明消息至少要被寫入到多少個副本才算是已提交
7、確保replication.factor>min.insync.replicas
8、設置enable.auth.commit=false,確保消息消費完成后再提交

四、Share

微服務架構之服務冶理Dubbo-Netty流程

黑龙江6+1开奖结果查询