在入正題之前我們再回顧下它的架構圖：
本文章主要分析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
processor.name
代表事件型別：metric
processor.event
代表事件型別：metric
process.title
jdk安裝目錄
service.name
對應的終端服務名稱，就是elastic.apm.service_name引數指定的值
service.runtime.name
運行環境，如是java行程該值就是java
service.runtime.version
jdk版本
host.ip
終端行程所有服務器ip
jvm.gc.count
jvm垃圾收集次數
jvm.gc.time
每次GC使用時間,單位是毫秒
labels.name
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、例外索引
parent.id
指向父節點的id,意思是上個服務請求的標識id，用于服務之間例外呼叫鏈路跟蹤
transaction.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)
error.id
此次例外事件的標識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服務主版本號
trace.id
跟蹤id
host.hostname
被監控的終端服務主機名
transaction.type
此事代碼被執行的方式，意思是被http請求還是內部執行的定時任務，如：request、scheduled
transaction.sampled
監控資料事件是否包含跨度、背景關系等全部相關資訊，默認是true
timestamp.us
事件發生時間，微妙
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.id
跨度標識
span.stacktrace
這個是跨度呼叫鏈，記錄了呼叫的檔案名，呼叫行，呼叫方式等資訊
span.duration.us
跨度耗時，單位微妙，這個時間是記錄span.stacktrace內呼叫堆疊的用時，跨度是什么意思呢？ 是指除了本行程內呼叫之外都算是跨度呼叫，比如：資料庫操作、調ice等
span.type
跨度型別，資料庫就是db，http就是external，相對subtye，它細粒度大些，
span.subtype
跨度呼叫子型別，有http、mysql、tcp(占不支持)等
span.name
給這個跨度呼叫取的簡單名稱，如：SELECT FROM ACT_RU_EXECUTION、SELECT、POST 192.168.1.7
span.action
跨度事件型別，像資料庫查詢，型別就是query
欄位使用分析：
這個索引最有價值的呼叫鏈了：span.stacktrace和執行程序中所花的時間，
2.4、事務索引
transaction.duration.us
整個流程的處理時間，單位微妙，這個時間包含了跨度時間在內
transaction.name
整個事務的名稱，用介面名、方法入口名來命
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、高級應用
制作我們的儀表板：
通知告警：
【著作權宣告】
本文著作權歸作者(深圳伊人網網路有限公司)和博客園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文鏈接，否則保留追究法律責任的權利，如您有任何商業合作或者授權方面的協商，請給我留言：[email protected]
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/184108.html
標籤：Java