今天，我們繼續把剩下 Observability 官方教學文件讀完吧！
本篇的主題包含有：
那我們就開始吧！
日誌（Log）和指標（Metric）間有一些相似之處，例如都是時間序列的資料、包含關鍵字，但是這兩者卻有根本上的差異。
指標著重在資訊的週期性測量，讓我們可以了解系統的狀態如硬碟空間、CPU使用率等等。
而日誌是某件事情發生在特定時間的紀錄，並沒有排程的概念在裡面。
下圖是兩種資料的例子：
在上面的例子，我們可以看到其中已經有用到時間戳記的資料格式，在使用時間戳記的時候有幾點值得一提：
在上面的兩個時間戳記例子中，第一個時間戳記格式並沒有包含時區的資訊，它有可是在地球的任一地方產生的，這樣對於後續分析很有可能會造成困擾與問題；而第二個時間戳記後面，Z-0400，這部分告訴了你時區的資訊，在這個例子就是紐約。
在 Elasticsearch 中，建議時間戳記的格式需要包含有時區的資訊，才不會造成後續分析的麻煩。
指標的生命週期一般來說可分成六個階段：排程、傳送、處理與儲存、搜索與分析、封存與清除，如下圖示：
有注意到嗎？第一階段凸顯了指標和日誌的不同，日誌並沒有排程的概念，但是指標有，是週期性的測量資料。
Metricbeat 是一種便於處理指標資料的工具，只要會產生指標的地方都可以使用它，它可以幫助你將指標傳送到 Elasticsearch 分析，並搭配 Kibana 做視覺化。
APM 的全名是 Application Performance Monitoring（應用程式效能監控），是用來回答下面兩個主要的問題：
APM 幫助我們找到整個應用程式服務花時間的地方，其紀錄軌跡包含有資料庫查詢、外部 HTTP 請求和其他發生在請求期間服務緩慢的操作，這樣讓我們可以更容易除錯、找到系統中的問題。
APM 的運作模式如下：我們會先安裝 agent 在各個應用程式中，而這些 agent 會追蹤各個應用程式收到的請求。
接著 agent 會收集資料並送到資料處理器，資料處理器就會把這些資料作轉換，變成可以儲存的文件格式，送往資料儲存的地方，當資料儲存在一個地方後，就可以透過使用者介面，來視覺化資料並加以分析。
Elastic APM 是由下列 4 個組件所構成：
彼此連接的架構關係如下圖：
那麼什麼樣的資料 Elastic APM agents 會收集並送到 APM server 呢？可以分為下列四種：
跨度含有一特定程式路徑被執行的資訊，其測量一個活動從開始到結束，且跨度可能和其他跨度有 parent/child 的關係。
一個跨度包含了：
transaction.id 屬性可對應到 parent transactionparent.id 屬性可對應到 parent span 或 transaction交易是一種特殊的跨度，其有額外的屬性，它描述了由檢測應用程式的Elastic APM agent 所捕獲的事件。
你可以把交易想程式你在一個應用程式中測量工作的最高層級，更具體地來說，一個交易可能是一個：
一個交易包含了：
交易和跨度一起，構成了軌跡，軌跡並不是事件，但它將相同根源的事件分群，如下圖：
一個錯誤事件包含了關於原始例外的發生或者當一日誌產生時發生的例外資訊，為了簡單起見，錯誤通常會用一個獨有的 ID 代表。
一個錯誤包含了：
stack trace（除錯很有幫助）culprit 代表從哪邊來transaction.id
下面是一個捕獲例外的 stack trace 例子：
APM agent 自動挑選基本的主機層級指標，包含有系統和程序層級的 CPU 與 memory 指標。
呼～總算是結束 Observability 的篇章啦！明天可以繼續進入更深入的部分了～
今天我們詳細地了解 Metrics 和 APM 的概念，包含他們的資料格式長什麼樣，內容物會有什麼東西，明天我們就要再進入更詳細的介紹 Logs 的部分了！一起加油吧！！！
iThome鐵人賽
看影片追技術