在入正題之前我們再回顧下它的架構圖： 本文章主要分析AMP各索引的作用，與及結合1.7環境上已接入的服務數據對比後，對索引中的主要欄位進行解析。文章分為四個小章節。 1、索引類型 apm索引分為四種類型： 系統指標索引(System status metrics)，索引名稱格式：apm-versio ...
在入正題之前我們再回顧下它的架構圖：
本文章主要分析AMP各索引的作用，與及結合1.7環境上已接入的服務數據對比後，對索引中的主要欄位進行解析。文章分為四個小章節。
1、索引類型
apm索引分為四種類型：
系統指標索引(System status metrics)，索引名稱格式：apm-version-metric-yyyy.dd.mm,主要儲存進程資源指標，如：記憶體信息、cpu信息、gc信息等。
具體異常索引(Error-specific data)，索引名稱格式：apm-version-error-yyyy.dd.mm，主要存儲進程error級別的經過json格式化後的異常信息棧。
跨度(或鏈路)索引(Span-specific data)，索引名稱格式：apm-version-span-yyyy.dd.mm，主要存儲跨本進程調用鏈的信息，如：代碼執行鏈、跟蹤id,跨度id,跨度類型、跨度用時等。特別指出的是這個索引的數據是形成整個事務、鏈路的一部分。
事務索引(Transaction-specific)，索引名稱格式：apm-version-transaction-yyyy.dd.mm，主要存儲事務的持續時間，單位微妙(PS：這裡的事務跟TPS同一個概念：指一個客戶機向伺服器發送請求到伺服器做出相應的過程，這裡除了客戶機請求之外，還包括內部的執行任務，如:定時任務)，如：進程id，TPS值，事務類型，發生時間，請求介面。
ps:以下標紅欄位是個人認為比較有價值的欄位。
2、索引欄位說明
這些索引中，有很多欄位都是公共的，所以我在其中某個索引中提及到了，在其它索引就不再單獨做說明項了。
2.1、系統指標索引
jvm.memory.non_heap.committed
java進程非堆的記憶體空間可用大小，單位是bytes。針對jdk8以上就是元空間大小。
jvm.memory.non_heap.max
java進程非堆的記憶體空間最大值，單位是bytes。針對jdk8以上就是元空間最大值。由系統參數：MaxMetaspaceSize設置
jvm.memory.heap.max
java進程堆記憶體最大值，由系統參數-Xmx設置
jvm.memory.heap.used
java進程堆記憶體使用量，單位位元組
jvm.memory.heap.committed
java進程堆可用記憶體大小，它的值一般為大於或等於已使用大小，小於等於最大記憶體空間，小於是因為Xms與Xmx設置不一樣，為了系統記憶體不波動，建議設置初始值和最大值一樣。
jvm.memory.non_heap.used
java進程非堆已使用大小
jvm.thread.count
JVM中當前活動線程的數量
jvm.gc.alloc
代碼中是計算java進程所有線程使用的記憶體總量(包括已死去的線程)，但是字面理解是堆記憶體中分配的記憶體總量相當於heap.max，個人認為性能調優上沒什麼參考價值
process.pid
對應的終端進程id
代表事件類型：metric
processor.event
代表事件類型：metric
process.title
jdk安裝目錄
對應的終端服務名稱，就是elastic.apm.service_name參數指定的值
運行環境，如是java進程該值就是java
service.runtime.version
jdk版本
host.ip
終端進程所有伺服器ip
jvm.gc.count
jvm垃圾收集次數
jvm.gc.time
每次GC使用時間,單位是毫秒
GC方式：如G1 Young Generation或G1 Old Generation
@timestamp
收集時間
system.process.memory.size
進程占用的虛擬記憶體
system.process.cpu.total.norm.pct
自上次上報以來該進程占用CPU的百分比。需要乘以100%。
system.cpu.total.norm.pct
自上次上報以來終端所在的機器當前cpu的使用率，需要乘以100%
system.memory.actual.free
操作系統當前可用記憶體（位元組），由空閑記憶體加緩存和緩衝區組成
system.memory.total
操作系統總記憶體
欄位使用分析：
從以上索引欄位解析可以讓我們實時瞭解該進程所在機器的ip、當前cpu的使用率、記憶體使用率、被監控進程的堆、非堆記憶體分配情況、記憶體使用率、cpu使用率、GC次數、GC使用時間、GC類型。比如：生產上記憶體分配一般是4GB,如果分配低於1GB我們可以當成一項告警指標，知道了配置的總記憶體和使用記憶體，又可以算出記憶體使用率，那麼當記憶體使用率達到90%即可做出告警事件，GC使用時間、頻率。GC的用時和頻率沒有什麼標準來衡量，根據服務實際情況來優化，能滿足當前需求和體驗感能接受即可，但以我們目前服務部署的情況來分析，高發很少突破100以上的情況下，每個服務記憶體都不超過4GB的，比較合理的YGC一分鐘內不能超過10次，每次不能超過20毫秒，FGC應該0次出現。可以以這個目標來優化靠攏。(下次我會寫一篇關於G1里為什麼能讓我們指定時間內完成GC——啟髮式演算法)
2.2、異常索引
指向父節點的id,意思是上個服務請求的標識id，用於服務之間異常調用鏈路跟蹤
事務id，這裡的事務不是數據事務，代表一個完整的請求流程或一個內部任務。用於異常事件鏈路跟蹤，結合數據看與parent.id值相同，說明代表服務id並不是固定死
error
異常棧
error.exception.message
拋出的異常信息，如：xxx屬性為空、500 Server Error、The user specified as a definer ('test_seq'@'%') does not exist
error.exception.type
異常類型，如：java.lang.RuntimeException、com.segi.uhomecp.ifs.activiti.exception.WorkFlowException、java.sql.SQLException
error.culprit
異常發生的根源，就是哪個類里的哪個方法哪行代碼發生的異常。如：com.segi.uhomecp.redis.RedisUtil$18.execute(RedisUtil.java:444)
此次異常事件的標識id
error.grouping_key
異常分組id,按error.exception.type分組
processor.name、processor.event
事件類型和名稱是同個東西，就是代表span、error、還有metris
observer.hostname
apm服務的主機名
observer.type
預設都是apm-server
observer.version
apm服務版本號
observer.version_major
apm服務主版本號
跟蹤id
host.hostname
被監控的終端服務主機名
transaction.type
此事代碼被執行的方式，意思是被http請求還是內部執行的定時任務。如：request、scheduled
transaction.sampled
監控數據事件是否包含跨度、上下文等全部相關信息，預設是true
事件發生時間，微妙
url.path
介面uri,如：/lease-stat/admin/businessSummary/list
url.scheme
url類型，如果是http.其值就是：http，非http為空
url.port
介面對應的埠
url.domain
介面對應的ip或功能變數名稱
url.full
介面完整url
http.request.method
請求方式，get或post，非http為空
http.response.status_code
http相應狀態碼，如：500
還有些一些用戶http請求的信息欄位，如：瀏覽器，用戶終端類型，http版本等。
數據結構圖：
欄位使用分析：
好了，經過我們分析了這個索引的核心相關欄位後。就可以知道這個索引能給我們解決什麼問題了，首先最有價值的是error異常棧，我們碼農級別最喜歡看的東西都這error doc里，從異常棧我們可以分析出錯的原因，error.culpri觸發異常的地方，除了這些信息我們從中還可以知道：異常介面、異常的服務進程、異常服務ip、http異常狀態碼、關連的異常鏈路。
2.3、跨度索引
跨度標識
span.stacktrace
這個是跨度調用鏈，記錄了調用的文件名，調用行，調用方式等信息
跨度耗時，單位微妙，這個時間是記錄span.stacktrace內調用棧的用時。跨度是什麼意思呢？ 是指除了本進程內調用之外都算是跨度調用，比如：資料庫操作、調ice等
span.type
跨度類型，資料庫就是db，http就是external，相對subtye，它細粒度大些。
span.subtype
跨度調用子類型，有http、mysql、tcp(占不支持)等
給這個跨度調用取的簡單名稱。如：SELECT FROM ACT_RU_EXECUTION、SELECT、POST 192.168.1.7
span.action
跨度事件類型，像資料庫查詢，類型就是query
欄位使用分析：
這個索引最有價值的調用鏈了：span.stacktrace和執行過程中所花的時間。
2.4、事務索引
整個流程的處理時間，單位微妙，這個時間包含了跨度時間在內
整個事務的名稱，用介面名、方法入口名來命
span_count
記錄跨度數
欄位使用分析：
transaction.duration.us是整個請求過程所使用的時間，可以根據這個時間推斷出指定該介面所在的服務，所屬的進程的性能，還有schemes類型，根據這個可以判斷是不是http請求，這個索引的數據主要是結合跨度索引一起使用。
3、實踐應用
經過了一翻上報索引數據的分析後，我們來實踐一下。
- 首先為每個接入服務名稱定義規範
apm監控是以進程為目標。如果要接入多個服務的情況下，要分辯某個或哪些服務是做什麼的，比較難辨別出來了。所以需要為每個接入監控服務的名稱統一定義一個命名規範。
所以我們統一規定服務監控名稱格式為(服務名稱必須符合此正則表達式：^[a-zA-Z0-9 _-]+$. 用較少的regexy術語：您的服務名稱只能包含ASCII字母，數字，短劃線，下劃線和空格中的字元)：segi-環境-業務組名稱-服務名稱-服務所在的機器ip，如：segi-saas-lease-uhomecp-lease-220。
現成的界面指標分析
- 預設主界面(services)：
說明：第一列是被監控的服務名稱，就是對應上面我們給他命的名稱 ；第二列被代監控的環境；第三列是每個監控服務平均響應時間(對所有請求作出響應所需要的時間平均值，其接近於所有TPM總和的平均)；每三列是每分鐘事務處理數；第四列是每分鐘發生異常數。
在這順便科普下幾個衡量一個服務的性能指標：TPS、併發數、響應時間
TPS：每秒傳輸的事物處理個數，即伺服器每秒處理的事務數。包括一條消息入和一條消息出。
併發數： 系統同時處理的request(或事務)數
響應時間： 對請求作出響應所需要的時間,一般取平均響應時間（響應時間：網路傳輸時間：N1+N2，應用伺服器處理時間：A1+A3，資料庫伺服器處理時間：A2，響應時間=N1+N2+N4+A1+A3+A2）
這三者之間的關係：併發數 = TPS*平均響應時間有用指標：平均響應時間：從這個直接看出服務的性能等級：毫秒級別的響應屬於非常有吸引力的用戶體驗；2秒之內給用戶是不錯的體驗；3秒之內可以接受；5秒之內遭用戶嘆氣；10秒之內60%用戶不使用；大於10秒90%以上用戶選擇離開。
EPM:直接反映服務使用穩定性，出現error直接影響服務的使用。
- traces界面
說明：這個鏈路界面跟服務界面指標差不多。展示的是所有服務的所有http介面的響應時間、TPM、介面訪問頻率
有用指標：平均響應時間 - 服務界面
圖一：
圖二：
圖三：
說明：圖一，服務的事務監控，可以看出這個服務下的每個介面的事務處理平均時間、第95百分位，每分鐘處理事務數、訪問頻率、每分鐘的訪問量。有用指標：第95個百分位（是統計學的一個術語，可以理解為有5%的請求超過多少時間),通過這個值我們可以直接看出這個介面的性能，比如：95百分位數是1,560ms的，那麼意味著有5%的請求介面事務處理時間超過這個值，這個指標的意義是：反映服務(上面的波浪線圖就是整個服務的95th)或介面的穩定性，如果在不同的時間段內95百分位數的值波動不大說明介面沒有問題，如果不同時間段內波動越明顯，就越能夠放大問題，主要用於性能分析，而介面平均處理時間就可以直接反映該介面的性能，我們可以按上面的響應時間做為標準來優化
圖二，是反映異常信息，主要有異常簡單信息、在選定的時間段內發生的異常次數(如上面的5K,就是5千次)、最後一次發生的時間，異常的指標都是有用的了。
圖三，這個監控界面所展示的指標個人認為是最為主要的了，直接能反饋這個服務的使用性問題，服務所在機器的資源問題、服務本身的資源問題。由於上面的一些指標已經說明過，這時就只解釋CPU使用和記憶體使用，以及它的意義。
cpu使用圖分別有這些指標：服務所在的主機cpu的最大使用率、平均使用率、服務本身占主機的最大使用率、平均使用率，這些指標都是有用指標，比如我選在一天內，這個機器的cpu使用波動很大，那麼這個機器就有問題，同理服務本身的cpu使用也是一樣；記憶體使用圖指標：服務所在機器記憶體使用最大值，和平均值。這裡我們還可以自己加入服務進程本身的jvm記憶體最大值、使用率指標，還有GC圖展示：GC次數、用時、GC類型。 - 鏈路界面
說明：這個界面主要是反映我們監控的介面內部服務調用鏈(包含跨度)， 介面處理總時間、和每個調用的耗時，主要作用：為開發人員調性能介面提供幫助。
4、高級應用
製作我們的儀錶板：
通知告警：
