什麼是可觀測性？
可觀測性（Observability）是一種軟體開發和系統構建的哲學，是對系統內部狀態及行為的度量和推斷能力，通常包括日誌、指標、鏈路追蹤等多個度量維度。也就是說，在軟體開發和運維領域中，可觀測性是指對於一個複雜的系統，能夠透過監控、日誌、指標、追蹤等手段，快速地發現、診斷、解決問題的能力。
Observability 最早是起源於控制論的一個概念：
In 1960, Kálmán introduced a characterization he called observability to describe mathematical control systems in his paper. In control theory, observability is defined as a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
傳統監控的侷限
從核心出發點來講，傳統的監控和可觀測性，背後解決的是同樣的問題，就是及時、準確的掌握系統的執行狀況，提升對系統執行的控制能力。因此常有人講可觀測性之於監控是“新瓶裝舊酒”，換湯不換藥。實則不然，隨著技術架構的演進，傳統監控的侷限愈發突出：
側重於依賴“經驗主義”，應對“已知問題”
傳統監控，要預先知曉採集哪些指標，新增什麼樣的告警策略，定製什麼樣的儀表盤，以便發現某種型別的故障後，採用什麼樣的 Runbook 來應對。比如技術團隊根據過往經驗，知道一臺伺服器上開啟的檔案控制代碼數量不能太多，超過某個上限就會影響到網路通訊以及檔案讀寫，因此我們會採集一個 node_filefd_allocated 的指標，然後配置一個告警策略：當 node_filefd_allocated > 1000k 則觸發告警，同時我們會提前製作一個 Linux 主機 Dashboard，其中包含有 node_filefd_allocated 的趨勢圖。準備好這些工作之後，接下來就是守株待兔，等待告警的觸發，值班的技術團隊就可以按照 Runbook 中載明的排查步驟，檢查是否有程序洩露檔案控制代碼，或者是否有大量的網路連結建立等等。
經驗主義，總是有限的，無法預知可能發生的各種未知的故障。因此在實際情況中，告警策略的完善往往靠“故障覆盤”來驅動，每次故障覆盤後，必定會有的一個改進項：繼續完善監控、加更多的告警。技術團隊總會處於一種對未知故障缺乏掌控的不安全的狀態中，產生焦慮感，反過來又會促使技術團隊新增更多的監控，久而久之，告警會越加越多，卻又永遠不夠，告警風暴就這樣產生了。
告警驅動的傳統監控，缺乏對故障的全域性感知
在傳統監控中，告警充當著舉足輕重的作用。當使用傳統監控方式，發出某個告警之後，值班的技術團隊看到的只是一個孤立的”技術問題“，這個技術問題的影響面有多大，重要程度如何，是否需要立即處理，是否需要上升和協同，很難快速的做出判斷。某個”技術問題“是否重要，是否緊急，不取決於該技術問題本身的難易程度，也不取決於所涉及的伺服器規模多寡，唯一的衡量標準是”對使用者體驗產生的影響有多大“。使用傳統監控無法快速的評估某個告警事件和使用者體驗之間的必然聯絡，導致無法投入準確的應急處置資源，無法確定合理的應急響應時效，也無法和其他資源產生有效的聯動協同，最終使得穩定性保障工作效率低下。
傳統監控認為，系統的開發者和系統的維護者，職責是相對分割的，導致監控以外掛形式為主
系統在設計之初，開發者的重心在於完成必備的業務邏輯，對於自身執行狀態的暴露，並沒有考慮的很完善甚至有時候都沒有考慮。大家可能會經常遇到，做的好的開發者可能還會列印較為詳細的日誌，做的不好的，連日誌也打的不全，更不必說提供主動暴露系統狀態的 Metrics 介面或者為實現 Tracing 進行埋點了。一旦系統到了上線執行階段，維護人員接手後，往往只能開啟“外掛”模式，透過寫各種各樣的指令碼，去探測程序是否存在、去分析匹配日誌中是否有關鍵的錯誤欄位。如果要進一步統計系統的訪問量、訪問延遲、資源消耗等等，就會更加被動。“外掛”往往是傳統監控資料採集的特徵。
傳統監控面向的通常是基礎設施，Metrics是傳統監控的基礎
傳統監控面向基礎設施，基礎設施的變化較慢，且變化帶來的結果相對可預測。Metrics 型別的監控指標，具有采集儲存成本低、簡單直觀、易於聚合計算的特點，因此在過去的二三十年裡，基於 Metrics 為基礎，出現了各種各樣的採集器、時序資料庫、視覺化工具、告警工具等，基於前面提到的”經驗主義“，尚能應付面向基礎設施的穩定性保障工作。
傳統監控工具發展的三個階段
階段1：Metrics監控之網際網路大流行前
網際網路大流行前，擅長於區域性場景，部分工具到現在仍然被廣泛使用
- Cacti：最悠久的監控系統之一，2001年9月，一個名叫Lan Berry的高中生，當時他還在為一家小的ISP廠商工作，為了更好地監控網路質量，開發了Cacti的第一個版本，基於RRDtool，提供更友好的使用體驗。
- Nagios：Nagios可謂是早期告警方向事實上的工業標準，可以用來監控主機和網路基礎設施，以及各種應用服務。在監控物件出現問題時，及時傳送郵件或者簡訊通知相關人員；當問題解決後，傳送恢復資訊。一段時間的主流，後來以難用聞名。
- Ganglia： UC Berkeley發起的一個開源叢集監視專案，設計用於測量數以千計的節點。主要是用來監控系統效能，如：cpu 、mem、硬碟利用率， I/O負載、網路流量情況等，至今仍然在Hadoop監控領域流行。
- RRDtool：在時間序列資料（time-series data）的儲存、展示方面，其獨創的round-robin database資料儲存格式，曾經是事實上的時序資料儲存工業標準。包括Cacti、MRTG、Collectd、Ganglia、Zenoss等系統，都是採用RRDtool的格式來儲存資料，以及使用RRDtool的Graph工具來繪圖。
- Collectd：定位是收集和傳輸資料。在告警方面不是Collectd的設計初衷，不過它也支援一些簡單的閾值判定，併傳送告警資訊。要支援更高階的一些告警需求，Collectd可以和Nagios配合使用。
- StatsD：最早是 2008 年 Flickr 公司用 Perl 寫的，StatsD 其實就是一個監聽UDP（預設）或者TCP的守護程式，根據簡單的協議收集statsd客戶端傳送來的資料，聚合之後，定時推送給後端，如graphite和influxdb等，再透過grafana等展示。
- Graphite：一個開源實時的、顯示時間序列度量資料的圖形系統。Graphite並不收集度量資料本身，而是像一個資料庫，透過其後端接收度量資料，然後以實時方式查詢、轉換、組合這些度量資料。Graphite支援內建的Web介面，它允許使用者瀏覽度量資料和圖。
階段2：Metrics監控之網際網路快速發展期
網際網路快速發展的時代，監控往一體化方向發展，注重體驗的提升
Zabbix
作為一款企業級分散式監控系統，功能齊全，使用者體驗良好，文件完善，API強大，儲存可以對接主要的SQL介面資料庫，適合於中小規模的公司或者團隊使用。Zabbix 由 Alexei Vladishev (阿列克謝.弗拉迪謝夫、拉脫維亞人）建立，目前由其成立的公司 —— Zabbix SIA（一家總部位於拉脫維亞里加的軟體公司） 積極的持續開發更新維護， 併為使用者提供技術支援服務。
Open-Falcon
小米技術團隊於2015年開源的一款網際網路企業級監控系統，重在解決日益增長的監控資料量和監控系統的容量限制之間的矛盾。Open-Falcon在架構設計上，一個最關鍵的考量點就是“如何做到水平擴充套件”，底層儲存採用的是RRDtool標準。
在Zabbix被廣泛使用的時期，Open-Falcon為何能夠在中國獲得重要影響力：
- Open-Falcon的初衷就是解決zabbix在大資料量情況下無法擴充套件伸縮的問題；
- Open-Falcon引入了標籤概念，該特性讓監控資料的分析變得非常靈活而強大，是下一代監控主要特點之一；
- Zabbix的使用者體驗在當時不太符合中國工程師的習慣；
- Open-Falcon藉助小米在網際網路公司的影響獲得快速推廣；
- Zabbix基於C語言開發，而Open-Falcon基於Go語言開發，在二開上更為友好；
- Open-Falcon的中文文件和支援能力；
階段3：Metrics監控之雲原生時代
Prometheus 成為時代的王者
Prometheus
由前 Google 工程師從 2012 年開始在 Soundcloud 以開源軟體的形式進行研發的系統監控和告警工具包，產品設計源於Google的Borgmon。Prometheus 的開發者和使用者社群非常活躍，Prometheus 於 2016 年 5 月加入 CNCF 基金會，成為繼 Kubernetes 之後的第二個 CNCF 託管專案。
Nightingale
夜鶯 (Nightingale) 是一款開源雲原生監控工具，是中國計算機學會接受捐贈並託管的第一個開源專案，在GitHub上有8000顆星，有數千家企業使用者使用。夜鶯集合了 Prometheus 和 Grafana 的優點，你可以在 UI 上管理和配置告警策略，也可以對分佈在多個 Region 的指標、日誌、鏈路追蹤資料進行統一的視覺化和分析。
高效能時序資料庫代表
- Prometheus：Prometheus自帶的高效能單機儲存資料庫；
- InfluxDB：支援按標籤儲存查詢，該領域最著名的時序資料庫之一；
- TDengine：國內最著名的開源時序資料儲存之一，面向IoT領域，表結構儲存，支援SQL查詢；
- TimescaleDB：表結構儲存的代表，支援SQL查詢；
- VictoriaMetrics：被廣泛應用的標籤儲存時序資料庫，和prometheus做了無縫相容；
- M3DB：Uber開發開源，高效能可擴充套件時序資料庫，支援按標籤儲存查詢，相容prometheus，擴充套件性比VictoriaMetrics好，但運維更復雜；
- Mimir：Grafana於2022年3月30日釋出的時序資料儲存，完全相容prometheus生態；
可觀測性的特點
可觀測性認為，你的應用是如何執行的以及是否在正確的執行，應該主動地、預設地透過 Metrics、Logging、Tracing、Events 等多種資料維度實時的暴露出來，然後透過工具進行視覺化、告警、分析和資料洞察。對應用內部狀態和行為的暴露，是系統設計之初就要考慮的重要組成，是系統功能不可分割的一部分。在可觀測體系下，“埋點”是一種文化，應用的開發者承擔著主體責任，系統的維護者反而作為資料的使用方存在。
以終端使用者發起對服務端的一次請求為例，在該請求的整個生命週期內，儘可能多的細節都應該被記錄下來，以便在未來的某個時刻用於 troubleshooting，這些細節資料可能包括：請求ID（request_id）、請求頭（headers）、請求引數（parameters）、請求執行的時間（duration_time）、對下游的rpc呼叫（rpc_calls)、執行rpc呼叫的耗時、rpc呼叫的結果、環境變數、元資訊（metadata）等等。在可觀測體系下，這些資料都應該被實時的記錄下來，並以結構化的形式儲存。
相較於傳統監控關注基礎設施，可觀測性強調面向”Application“。隨著雲原生架構和微服務模型的普及，現代化的應用出現了一些新的特點：
- 相比單體應用，技術團隊面臨著更多的服務需要管理；
- 很多服務之間都是松耦合，而且像雲資料庫、雲端儲存、第三方API等服務，都不處於你的掌控之下；
- 程式碼的釋出和變更，頻率越來越高，持續整合、持續釋出成為主流；
- 基礎設施動態化，容量也在動態的彈性伸縮；
- 現代化的系統架構下，可能出現故障的點位越來越多，”長尾問題“出現的頻率也越來越高，難以定位和分析；
- 研發工程師更多的參與到系統的執行維護工作中來；
OpenTelemetry
也被稱為 OTel。是一個供應商無關的開源可觀測性框架，用於測量、生產、收集、匯出可觀測資料。可觀測資料主要包含traces 鏈路、metrics 度量和 logs 日誌。使用OpenTelemetry後，可觀測的三要素日誌、鏈路追蹤、指標，將從過去的相互獨立，變的關聯性更強，方便我們進行更快速的問題定位：
Flashcat
Flashcat是一個相容OpenTelemetry的可觀測性平臺，構建了一個資料、平臺、場景打通的一體化可觀測方案，具有以下四個特點：
- 一體化：從業務到應用到基礎實施，打通Metrics、Logging、Tracing、Event，是一個立體的監控產品體系和解決方案。
- 統一管理：採集適配雲原生、公有云、物理機/虛擬機器、混合雲等環境。產品層實現多環境、多叢集的監控統一管理。
- 整合融合：可整合企業內部已有的可觀測配套系統，無需推倒重來，串聯打通資料，發揮協同定位的價值。
- 引導定位：結合服務穩定性保障的理論實踐，從上往下引導使用者按照最佳實踐，層層下鑽，加速故障處理。
你可以透過Flashcat平臺，有效改善以下問題：
- 希望整個公司統一用一個工具，就可以支援指標、日誌、鏈路追蹤資料的採集、視覺化、告警，免去搭建和維護多套 Prometheus、Zabbix、Grafana、ELK、Jaeger 的工作量。
- 如果有在用多雲，並且在多個公有云監控控制檯來回切換不方便，希望監控資料、監控檢視都是統一的，有更一致的使用者體驗，同時降低給所有的工程師開通公有云控制檯許可權帶來的安全隱患。
- 告警太多，工作老被打斷， 可以利用我們提供的 OnCall 值班平臺（類似於 PagerDuty），支援告警聚合、降噪、認領、升級、排班，可以在飛書、釘釘、企微中接收和處理告警。
最易被忽視的OnCall
在傳統監控領域，OnCall是最容易被技術團隊忽視的一個概念，運維和研發人員往往面臨以下典型的困擾：
- 技術團隊每天接收到大量的告警。
- 很多告警長時間無響應，長期無人問津。
- 告警與告警之間缺乏關聯性，處理效率低下。
- 告警處理缺乏協同，處理過程不透明，資訊難以共享，知識難以沉澱。
- 很多告警並未準確反應實際情況，無謂的消耗技術團隊精力。
- 客戶/使用者往往先於技術團隊發現故障，客戶滿意度持續走低。
- 無法量化的衡量應急響應的現狀和效率，無法制定出改進和最佳化路線。
一個好的 OnCall 工具，能夠大幅提升運維和研發人員的效率和幸福感：
- 告警聚合收斂：解決告警風暴問題，按照業界的實踐，壓縮率為70%~80%。
- 告警全生命週期管理：告警認領、轉派、升級，解決告警不能及時處理、告警漏處理、告警散落在各個監控系統的問題。
- 告警排班：引入值班表，以排班的形式高效的OnCall，減少疏忽和失誤，減少告警對非值班team的打擾，讓團隊可持續發展。
- 故障管理：相關的告警聚合為故障，基於故障的告警處理協作模式，解決跨團隊協同不暢的問題。
- ChatOps互動：在電話、簡訊之外，透過各種IM觸達通知技術團隊，在IM中互動式的響應和處理告警。
沒有度量就沒有改進，在實際工作中，運維負責人表面看到的是告警太多、團隊成員疲於奔命，但苦於看不清告警處理的工作量，沒法規劃協調補充人力，更嚴重的是看不清最佳化告警的方向，導致情況持續惡化，最終團隊散了，故障頻發。所以在告警處理的領域，尤其需要“可觀測”，推薦關注下面 5 個關鍵的OnCall度量指標：
- 降噪比：即告警的壓縮比，透過演算法、規則將眾多相關的告警聚合後，再通知到值班人員。告警聚合能有效降低告警風暴，減少值班人員的工作量，提高資訊處理的效率（
該指標越高越好）。- 響應比：被認領的告警佔所有告警的比例。在告警管理領域，需要響應或者認領的告警，才是有用的告警，因此透過統計和觀察“響應比“，能整體的評估告警是否足夠有效和有用，並持續的推動提升告警”響應比“（
該指標越高越好）。- 告警總量：一段時間視窗內產生的告警數量。過高的告警總量，意味著值班的壓力越大，對技術團隊注意力的干擾越多，潛在的意味著告警的噪音可能也過大，因此過多的告警，會讓整個系統處於不可運維的狀態，應該該盡力的降低告警總量，譬如採用基於SLO的告警，就可以答覆降低該指標（
該指標越低越好）。- MTTA（平均響應或認領用時）：從告警發生到值班人員響應或者認領的時間間隔。越快的 MTTA，標誌著越高的告警處理效率，潛在的代表著越高的服務穩定性。透過MTTA我們可以有效的度量團隊的工作壓力，以便決策合適的資源投入，確保團隊始終處於可持續發展的狀態（
該指標合適就好）。- MTTR（平均恢復或解決用時）：從告警發生到問題解決的時間間隔。越快的 MTTR，往往意味著團隊擁有更先進的觀測技術、更強大的基礎設施平臺、更熟練的工作技能、以及對業務系統有更深入的理解（
該指標越快越好）。
兵器推薦：
- 國外推薦採用PagerDuty，PagerDuty是全球範圍內OnCall產品的領導者。
- 國內推薦採用FlashDuty，FlashDuty是開源監控工具夜鶯背後的開發者團隊推出的OnCall產品，相比PagerDuty對國內的各種監控工具、IM工具適配性更好，產品體驗也更簡潔。
可觀測性的技術趨勢
在可觀測性三大支柱在外，Continuous Profiling作為一種持續效能分析技術，應用也越來越廣泛。Continuous Profiling 用於實時監測和分析應用程式的效能特徵。它透過不間斷地採集應用程式的效能資料，例如函式呼叫、記憶體使用情況、CPU利用率等，以實現對應用程式效能的全面瞭解。
eBPF（Extended Berkeley Packet Filter）是Linux核心的擴充套件功能，用於在核心層面執行安全、效能和觀測等任務。eBPF技術允許使用者在不修改核心程式碼的情況下，透過安全的、可程式設計的虛擬機器在核心中注入程式碼。它能夠捕獲和處理系統的事件，例如網路資料包、系統呼叫、檔案訪問等，並進行實時分析或轉發，從而實現更高階的網路分析、安全監控和效能最佳化等功能。
在可觀測性領域，Continuous Profiling和eBPF技術都為開發人員和運維團隊提供了更加全面、實時和深入的監控能力。