Instana 使用 Apache Cassandra 查詢數十億個指標
合作夥伴資訊
-
可觀察性與指標
-
150 位以上員工
-
每秒數百萬個指標
-
五個生產區域，每個區域有 15 個節點
-
同時在 AWS 和 GCP 上執行
好處
-
固定查詢的分散式模型
-
小型團隊可維護複雜的資料建模
-
Cassandra TTL 作為內建資料模型
-
保留政策易於實作
-
即時查詢數百萬個指標
-
Cassandra 3.0 時間視窗壓縮策略，可輕鬆查看時間視窗
Instana 是一家位於伊利諾州芝加哥的 IBM 公司，提供現代化應用程式的應用程式效能管理軟體，具備 CI/CD 管線可見性，可實現封閉迴路 DevOps 自動化。Instana 透過即時收集每天數十億個指標，提供豐富的脈絡情報和基於 AI 的問題解決方案，並使用 Apache Cassandra 大規模儲存和處理資料。其高效能、高擴充性的架構可在混合雲中跨大型分散式應用程式以一秒為間隔擷取 100% 的交易。
Instana 的監控工具（也稱為 Instana）收集主機層級資料，例如 CPU 和記憶體使用量，並對應主機上執行的程序。該工具監控到應用程式層級，追蹤請求在系統中執行的過程。
挑戰
Instana 的客戶群不斷成長，新使用者有更高的期望。使用者不想等待一分鐘才能看到結果；他們希望即時看到結果。
Instana 目前在五個區域營運，每個區域有四個叢集執行數千個感測器。每個感測器每秒可傳送 1,000 個或更多指標：「我們需要可以儲存這些資料量並查詢資料的工具。我們始終知道查詢時要從哪個感測器取得資料，而且會限制在某個時間範圍內。這就是我們選擇 Cassandra 的原因，因為它有時間序列資料模型。」Instana 的網站可靠度工程師 Marcel Birkner 表示。
對於 Instana 團隊來說，Apache Cassandra 非常出色地涵蓋了其特定使用案例。
見證引言
Cassandra 運作良好，執行順暢且穩定。我們從未遺失資料，而且問題很容易就能修復。坦白說，沒有 Cassandra，我們無法執行 Instana。
Instana 員工網站可靠性工程師
當我們開始使用 Instana 時，就像一般新創公司一樣，特別是在我們監控 100 種不同技術和 1,000 種不同函式庫的情況下，使用微服務架構搭配 Cassandra 表示當單一元件故障時，我們可以進行優雅降級。
Instana 員工軟體工程師
大量查詢的強大效能
監控複雜系統需要以一秒為單位報告指標。Instana 與感測器搭配使用，這些感測器會收集系統效能資料並報告不同的指標，例如 CPU 使用率或平凡 GC 時間。通常一個環境可能有數千個感測器，每個感測器每秒都可以傳送多達 1,000 個或更多指標。結果是單一使用者會有大量資料。
除了大量資料擷取之外，使用者還必須能夠查詢自己的資料，通常會針對單一感測器加上時間範圍限制。Cassandra 時序資料模型非常符合此需求。
優雅降級
Instana 面臨單體架構無法解決的資料建模挑戰。最重要的是，此應用程式監控數百種技術和數千個函式庫，使用者會將這些技術和函式庫組合成數百萬種組態。只有微服務架構，在 Apache Cassandra 的支援下，才能在資料接收系統的單一部份停止運作或已棄用時進行優雅降級。
時間視窗壓縮
早期，一個很大的挑戰是找到合適的視窗和其他壓縮設定。如果策略不正確，可能會很快失控。壓縮程序會合併金鑰、結合欄位、驅逐墓碑、合併 SSTable，並在合併的 SSTable 中建立新的索引。天真地使用此方法會導致在寫入新的彙總資料點時，每秒產生數百萬筆插入。在某個時間點，單一叢集有一個包含 30,000 個 SSTable 的單一表格，而且團隊必須執行手動壓縮才能將其縮小到可管理的大小。
單一秒資料解析的規模對於長期儲存或涵蓋顯著時間範圍的查詢（例如，查看過去三個月內的記憶體使用率）而言沒有意義。對於此使用案例，Instana 需要彙總資料，例如指出資料在五秒間隔中平均的結果。我們選擇為使用者修復時間視窗檢視，顯示一秒、一小時、一天和一週的檢視。彙總資料有不同的保留原則，而且 Cassandra TTL（生存時間）很自然地適用於資料模型。
Instana 的使用者會提出時間視窗要求來查看他們的 Instana 資料，這讓 Cassandra 成為完美的搭配。Cassandra 3.0 的時間視窗壓縮策略讓 Instana 能夠將磁碟上的資料分組，這些資料會以時間視窗分組方式檢視。
