前言
部落客本身并不是負責apm項目的，基本都是自發的行為，這是很好的一方面，打勞工一定要培養自己的行業裡面的獨有經驗，下面我聊兩句。
縱觀《資治通鑒》，它講中國古時代的精英，以及帝王他們的處事方式，是以它被稱為帝王之書，用于管理人員、事務處理，但是如果用于個人品行去學習可能有所偏差。比如說在這些人哪個不是權貴，是以他們的權利比普通人高的，其次處理的事情也不是我們日常的芝麻小事，當角色不同、地位不同處事方式也不能直接照搬～
另外，唐代憲宗裡面有段有意思談話，他跟宰相在聊，怎麼樣能做好一位君主，宰相參照以往的曆史，認為人的精力有限的，應該制定好選人機制、kpi考核，這些那些事情交由他們來處理。這裡面提到了選人機制、還有考核機制制定，對于一個治理國家的人來講，有一套合理的機制處理日常各種事務非常重要的，其次在位的這些頭頭應該是要稱職，就需要靠這套考核機制。
職場上真正能力
我聊聊職場上應該怎麼做才是比較好，我認為一個上司者最重要是在某個領域有自己的見解，也就是你知道某個領域未來的規劃，然後可能遇到問題的解決方案，比如說供應鍊，本質來講我認為它是提高這個流程的作業效率，對整個流程情況有一個資料支撐，比如說整條鍊路耗時出在哪裡，有哪些還是人工作業。然後你再參照其他公司，你會發現它是通過c端使用者消費資料來促進供應商裡面商品快速疊代，打法又不一樣。這跟你b端供應鍊自己玩不是一個檔次，比如說采購商買得多的料子就是爆款嗎，也不一定，說不定人家用來批發的。
至于管理能力，我按能力強弱、執行力的強弱去安排就完事了，是以我認為職場裡面的上司者不是說簡單的管理人，而是在特定領域有自己建樹，真知灼見才是王道，即使沒有能夠主動了解學習，不愧為智者。
apm 查詢優化
現狀
之前也有同學回報說apm查詢比較慢，就是那種跨很長的時間跨度那種，最近有空我就去看看，發現代碼比較久遠的，通過restclient 直接通過es語句去請求。
我們apm日志是按天來分片，如果說跨天就需要 get /xxx_20230907,xxx_20230906/_search 來執行查詢功能，我們每天日志量大概在5kw左右，這麼多個索引查出來肯定會慢，其次加上按時間排序。
思路
我們按響應結果來看，就是一個total+分頁查詢資料，total的話，我們可以通過count方法來查詢，其次分頁查詢資料大概10～500行一頁，這就意味着我目前的查詢會落在一個到兩個索引裡面，不需要把索引都塞進去查，是以關鍵在于找到我目前查詢頁所在的索引分片是哪個，直接查詢即可。
實作
1、如果是聚合語句，或者單個索引分片（查一天）直接查詢
因為聚合它需要做統計功能，無法直接通過單個分片來進行，一天查詢隻會命中一個索引，這我們直接執行查詢就可以了。
2、查總數
通過多個索引的count+查詢條件，我們可以查出目前條件下的所有數量有多少，一次性查詢出來
3、定位索引分片
因為我們是時間倒序，我們将時間索引也倒序的查，比如說9月7号先查總數，10個符合的，如果說我在第一頁，一頁有8個，那麼我直接命中第一頁查詢即可，第二頁的時候，會跨分片，我們統計9月6号符合的個數，如果說它大于等于2，也就是剛好滿足第二頁的内容，我們通過get 兩個索引來查詢。
這樣避免說我把所有索引都引進來暴力的分頁查詢。
4、資料組裝
我們需要将上面的分頁資料跟total組裝傳回給前端
apm接口請求緩慢歸因分析
之前在第二篇apm 請求 “異常”分析的時候出現這幅規劃圖，當我實際去實作的時候發現有一些細節問題。
細節
1、異常點算法問題
我之前看去哪兒網也有談到類似的，采用lof模型去統計，你就會發現幾個極端情況：第一一堆的請求很慢的接口，幾個請求很快的接口，這些很快的接口變成異類了，我滴媽；第二 一堆20ms接口，一兩個400ms接口，這也是異常點；
是以在我掂量下采用了方差法，就是你比平均數高3倍方差，你就是異常點，當然這也存在上面的第2種情況，需要進行降噪。
1.1、降噪
a、定時器接口處理
定時器如果作成同步接口，那麼會非常的慢，因為如果壓榨機器性能可能會垮掉，隻能慢慢跑。我們可以通過異步線程的方式進行處理，這樣就不影響我們統計慢請求了。
b、正常的“異常點”
比如說第2種情況，正常接口請求隻需要在200-500ms之間即可，但是如果我們内網點情況會非常快，導緻這些接口也變成異常點，是以我們通過判定接口的平均時間大于500ms，然後你目前的請求時間大于它3倍方差，那麼這個就是整個應用的異常點。
by the way，我們統計是有個時間視窗，比如說10s進行統計，是以我們上次才講平均時間去跟500ms比對。
2、歸因分析
2.1、按接口響應時間變慢次元統計
這個我認為是不行的，一個可能存在資料集小，比如說a接口，半小時才請求一次，你怎麼知道接口變慢了呢對吧，另外一個除非有新版本更新才能發現接口速度變化情況。
2.2、按照時間最長的top3統計，接口+mysql請求
比如說我應用很慢，這些請求時間很長的當然是罪魁禍首對吧，沒毛病。這裡也有一個細節，就是應該去除網關接口統計，因為網關是最外層了，你統計它的接口意義不大，而是應該鍊路裡面的服務最慢的哪些接口，還有資料庫請求sql統計起來。