使用Prometheus和Grafana進行系統監控和預測 - flightaware

banq發表於2020-08-12
PrometheusGrafana

Hyperfeed是FlightAware的核心航班跟蹤引擎。它的輸出為公司最突出的產品提供了動力：網站上的航班頁面，Firehose，FlightXML和航班警報。
Hyperfeed是一個分散式系統，由分佈於多臺機器上的十幾個元件和子系統組成，以提高效能和容錯能力。它的子系統包括許多其他知名服務：Postgres，Zookeeper，Kafka和RabbitMQ。
 
Zabbix一直是FlightAware的主要監視和警報框架。它在整個公司中都使用，並不特定於任何軟體。當應用於Hyperfeed時，Zabbix監視執行該應用程式的伺服器的一些關鍵特徵，例如CPU，記憶體，磁碟和網路使用情況。此外，上述自定義工具將其資料輸入到Zabbix中，以便在發生問題時可以將其用於警告工程師。
最重要的是，Zabbix為我們提供了一個基本的Web介面，用於檢視以圖形格式收集的資料。當Hyperfeed緊密地安裝在單個伺服器上時，這種監視對我們很有幫助：Zabbix是一站式商店，可進行所有監視。但是，隨著對Hyperfeed的需求增加，其操作複雜性也隨之增加。
最終，單機架構不足以處理Hyperfeed輸入量的增加，這是由於FlightAware獲取新資料來源並擴充套件其現有資料來源而導致的。為了適應這種規模的變化，有必要在多臺計算機之間分配Hyperfeed。發生這種情況時，我們繼續使用（並且仍然使用）自定義工具和Zabbix進行監視。但是，我們的自定義工具以及我們傳送到Zabbix的資料也必須擴充套件。儘管必須在多臺計算機之間分配Hyperfeed並改善系統的效能和可靠性，但它也帶來了新的挑戰和困難，尤其是在監視方面

使用Prometheus和Grafana升級監控
在航班跟蹤的情況下，一些示例性的時間序列指標可能是：

  • 每秒出發
  • 每天到達
  • 每分鐘取消
  • 每小時轉移
  • 每秒建立的飛行計劃
  • 每秒處理的輸入訊息
  • 每秒生成的輸出訊息
  • 最近6個月處理ADS-B職位所花費時間的99％

為了使捕獲的資料量易於管理，觸發這些事件中的每一個的輸入訊息的內容都被彙總。
 
Prometheus的主要賣點之一是，它提供了功能強大且概念上簡單明瞭的資料模型，用於從目標系統中提取指標並跟蹤其隨時間的變化率。Prometheus跟蹤的每個時間度量標準都包含以下資訊：
  • 指標名稱：一個字串，指示指標的用途，例如hyperfeed_departures_total。
  • 幫助文件：一個字串，描述指標的用途或來源。
  • 度量型別：提供了四種型別，但是其中兩種提供了其他型別的原子構造塊。基本型別是隻能上升或復位的計數器，以及可以設定為任何值的儀表。
  • 標籤：將附加維度附加到指標的鍵/值對。標籤提供了一種比單單透過名稱傳達更多細節的方式。典型的示例是用於度量Web伺服器響應時間的度量標準的URL路徑。使用路徑標籤，可以跟蹤特定URL的響應時間，也可以彙總所有標籤並檢視任何路徑的響應時間。標籤為指標提供了更多的粒度，並在查詢時提供了強大的功能。
  • 指標值：一個float64值。這是隨時間推移跟蹤的值。
  • 獲取度量的特定值的時間戳。


有了Prometheus資料模型，下一個主要賣點是相對容易地直接從其監視的應用程式或系統中公開白盒指標。通常，這是透過使用被監視系統的語言中的Prometheus客戶端庫來完成的。所有最流行的語言都已經有一個庫，但是FlightAware是Tcl的重度使用者，根據TIOBE索引，Tcl是一種較少使用的語言。不得不編寫一個庫，以利用Prometheus所提供的功能。
 
將資料從客戶端庫獲取到Prometheus要求一個程式透過HTTP公開其指標，並且Prometheus知道可以在其上請求指標的主機名和埠。一旦資料到達Prometheus，就可以使用Grafana對其進行視覺化，使用Prometheus專案維護的單獨元件進行警告，查詢和瀏覽。就計算和記憶體而言，使用Prometheus庫對應用程式進行檢測是相對便宜的操作。由於指標會隨著時間的推移聚合值，而不是建立要分批傳送的值序列，因此給定的一組指標存在不變的記憶體成本；儘管不是免費的，但計算成本卻很小
 

預測技術概述
預測技術團隊的主要目標是針對著陸時間（EON）和登機口到達時間（EIN）生成飛行ETA預測。對於任何給定的機場，我們訓練兩種模型，一種用於EON，另一種用於EIN，這些模型可以預測飛往該機場的航班。
由於該軟體中大量使用了機器學習，因此監控變得比平時更為重要。您不僅需要管理典型的軟體條件，例如系統是執行，掛起還是停止，還需要跟蹤機器學習模型本身的準確性。模型可能會出現短暫的不準確性，例如，如果它們無法預期巨大風暴的影響；隨著現實生活中行為的改變，它們也會隨著時間的推移緩慢漂移。意識到這兩種型別的變化對於對您的預測充滿信心至關重要。
當我們贏得了要求我們對600個機場進行預測的客戶時，這種情況突然變得不足。高可用性是服務的關鍵組成部分，為了幫助實現這一點，我們選擇了冗餘執行模型。總體而言，這將我們的生產基礎架構從幾臺主機擴充套件到了24臺主機，當我們需要在Hyperfeed中引入預測速率限制以確保客戶不會因僅幾秒鐘更新E他的訊息而感到不知所措時，就增加了軟體複雜性。
  

新監控解決方案的目標
我們希望確保包含新功能的幾個功能可以解決我們的痛點：

  • 根據每個機場的時間跟蹤錯誤
  • 跟蹤誤差在每次飛行過程中都會發生變化：例如，飛行著陸前兩個小時的預測誤差是多少？航班降落前一小時？
  • 自動發現指標：例如，當機場作為鍵key傳遞時，如果之前未曾看到過該機場，則會新增一系列
  • 查詢和顯示反映預測誤差的圖形
  • 對高（或高於正常）錯誤發出警報

 

用Grafana監控
Prometheus是一個純時間序列資料庫。它不支援關係查詢（SQL JOIN）。我們最終選擇了TimescaleDB作為資料庫後端。TimescaleDB是PostgreSQL的時間序列擴充套件：它在背後隱藏了時間序列表，與純Postgres相比，查詢效能得到了很好的提升。在所有其他方面，它都是“僅” Postgres，這是理想的，不僅是因為它支援關係查詢，而且還因為FlightAware已經在大多數資料庫中使用了Postgres。我們已經對如何設定，配置，調整等等有很多機構知識和熟悉度，這使得它很容易採用。
關係查詢使我們可以將到達時間儲存在一張表中，並將根據我們的機器學習模型和第三方估算值預測的ETA記錄在另一張表中。藉助Grafana，我們會在每個機場，每個航空公司和每個超時時間提醒高ETA錯誤；我們可以將我們的預計ETA直接與第三方估算值進行比較。它使我們對我們的預測充滿信心，併為改進提供了方向。

 

相關文章