本文討論了物聯(lián)網(wǎng)中監(jiān)控和可觀察性的要點。主要介紹了如何利用日志、指標、跟蹤和結(jié)構化事件來增強物聯(lián)網(wǎng)系統(tǒng)的可觀察性。操作數(shù)以萬計的物聯(lián)網(wǎng)設備也不例外。擴展物聯(lián)網(wǎng)可觀察性解決方案可能很快導致可觀察性基礎設施的性能不足和難以承受的成本。因此，本文將側(cè)重于處理大規(guī)模。

將討論一些技術，這些技術可以幫助您平衡物聯(lián)網(wǎng)擴展帶來的權衡:

選擇高性能數(shù)據(jù)庫

知道要收集什么數(shù)據(jù)，現(xiàn)在將所有數(shù)據(jù)轉(zhuǎn)儲到MySQL中，就可以開始觀察。不要這么快，這可能不是最好的主意，有幾個原因。將查看對數(shù)據(jù)庫的需求，然后建議一種能夠更好地滿足對物聯(lián)網(wǎng)擴展需求的存儲。

首先，讓修改存儲物聯(lián)網(wǎng)可觀察性數(shù)據(jù)的幾個特征：

查詢速度很重要。在處理生產(chǎn)中斷時，最不希望的就是等待幾分鐘，直到調(diào)試查詢完成。

將處理多維度和高基數(shù)。大量的維度來自于捕獲操作的許多屬性以應對未知條件的想法。此外，還有一些重要的列具有高基數(shù)(列中唯一值的數(shù)量)，例如設備Id。

需要有效地跨所有維度進行查詢。在調(diào)試特定問題時，不知道哪些屬性是重要的。

通常會對來自有限時間范圍的數(shù)據(jù)感興趣。時間范圍通常對應于您觀察到系統(tǒng)服務降級的時間段。

通用SQL數(shù)據(jù)庫可能不夠

可能都熟悉SQL數(shù)據(jù)庫，因此很自然地將其視為存儲可觀察性數(shù)據(jù)的地方。然而，幾個技術方面使得SQL數(shù)據(jù)庫不適合存儲大規(guī)模的可觀察性數(shù)據(jù)。

傳統(tǒng)的面向行數(shù)據(jù)庫，如MySQL或PostgreSQL，在只需要列的子集時，很難有效地處理對多維表的查詢。

高維的另一個問題是難以實現(xiàn)有效的索引。不能事先為列子集創(chuàng)建數(shù)據(jù)庫索引，因為不知道在故障排除過程中哪些維度是重要的。因此，要么需要索引所有列(這將非常昂貴)，要么在基于未索引列進行過濾時查詢將很慢。

此外，如果沒有明確的基于時間的數(shù)據(jù)分區(qū)，通常就沒有有效的方法來丟棄舊數(shù)據(jù)。時間分區(qū)允許在數(shù)據(jù)過時時有效地刪除大塊數(shù)據(jù)。

如果出于合理的動機使用傳統(tǒng)的SQL數(shù)據(jù)庫來處理可觀察性數(shù)據(jù)，您可能需要考慮Timescale。它是一個PostgreSQL擴展，在使用基于行的SQL模型的同時，通過時間分區(qū)和更好的壓縮解決了上面提到的一些挑戰(zhàn)。

用于物聯(lián)網(wǎng)擴展的信號特定存儲

將可觀測信號分類為度量、日志和軌跡導致了針對每種信號類型定制的專用存儲的發(fā)展。例如，Mimir用于度量，Loki用于日志，Tempo/Jaeger用于跟蹤。這些存儲中的每一個都是用特定的信號類型創(chuàng)建的，這使得它們能夠有效地監(jiān)視特定信號中的用例。但是，跨這些存儲查詢數(shù)據(jù)可能比較麻煩。

此外，某些存儲有一些特定的限制。例如，傳統(tǒng)的時間序列數(shù)據(jù)庫(tsdb，如Mimir)不能處理高基數(shù)的數(shù)據(jù)。tsdb為每個唯一的屬性集存儲單獨的時間序列。這種方法在維數(shù)有限和基數(shù)較低的情況下非常有效，因為在單個時間序列中編寫和查詢非常高效。

但是，對于高基數(shù)，數(shù)據(jù)庫需要經(jīng)常創(chuàng)建新系列，因為它經(jīng)常遇到唯一的屬性組合。因此，在檢索聚合值時，數(shù)據(jù)庫需要遍歷每個時間序列，從而使操作效率低下。這個問題在物聯(lián)網(wǎng)領域尤為嚴重。

使用面向列的分時存儲以獲得最佳可擴展性

隨著對與類似的分析工作負載的需求不斷增加(如上所述)，新的數(shù)據(jù)庫浪潮出現(xiàn)了。它們采用列式存儲，這使得讀取操作更高效，因為它們只接觸特定查詢所需的列。由于采用了時間分區(qū)，數(shù)據(jù)庫可以將讀取操作限制在有限的數(shù)據(jù)范圍內(nèi)，從而使查詢更加高效。

這些設計選擇的組合也使壓縮工作更快，因為算法在受時間范圍限制的單列上操作。這類存儲的典型例子包括InfluxDB、QuestDB和ClickHouse。

數(shù)據(jù)采樣

在一定規(guī)模上，收集和存儲設備產(chǎn)生的每個可觀察信號變得難以忍受。值得慶幸的是，這通常是不必要的，因為您只需使用一小部分可觀察性數(shù)據(jù)就可以成功地調(diào)試問題。

例如，描述成功場景的事件通常不如描述失敗的事件重要。這就是為什么可以拋棄大多數(shù)這些事件，只存儲少數(shù)具有足夠代表性的例子來重建特定的歷史情況。

存在各種采樣策略，以確保只收集有限數(shù)量的事件，同時仍然保留足夠的細節(jié)。選擇符合你具體需求的抽樣方法是很重要的。工具庫，如OpenTelemetrysdk，通常提供這種采樣策略的實現(xiàn)。這使得取樣成為降低儲存和處理成本的一種相對簡單的方法。

在跟蹤的背景下，根據(jù)采樣決策的位置區(qū)分了物聯(lián)網(wǎng)擴展的兩種采樣：頭采樣和尾采樣。頭部采樣決定是否在設備上對跨度/軌跡進行采樣，而尾部采樣則在收集到特定軌跡的所有跨度后做出此決定。

頭部采樣的主要優(yōu)點是簡單和成本效益。它減少了在物聯(lián)網(wǎng)環(huán)境中可能受到限制的網(wǎng)絡流量，并避免在可觀察的后端存儲和處理未采樣數(shù)據(jù)。

但是，如果您希望基于整個跟蹤做出抽樣決策，則尾部抽樣是必要的。如果您希望對錯誤的跟蹤進行采樣，而不是對成功的跟蹤進行采樣，那么這種方法非常有用。

建立保留策略

可觀察性數(shù)據(jù)往往會隨著時間的推移而迅速失去價值。今天收到的遙測數(shù)據(jù)通常比去年的數(shù)據(jù)更有價值。這為提供了另一種顯著削減存儲成本的方法。

保留策略允許在指定時間范圍內(nèi)自動刪除數(shù)據(jù)?；跁r間的分區(qū)簡化了保留策略的實現(xiàn)，這就是許多現(xiàn)代數(shù)據(jù)庫開箱即用的原因。

另一種策略是利用分層存儲。也就是說，將舊數(shù)據(jù)存儲在低成本的對象存儲(如AmazonS3或AzureBlobStorage)中。盡管從這些存儲進行查詢可能比本地磁盤具有更高的延遲，但它允許您保留更長的數(shù)據(jù)，同時仍然降低存儲成本。

最后，可以進一步降低歷史數(shù)據(jù)的分辨率。一種方法是對舊數(shù)據(jù)進行二次降采樣。另一種方法是顯式創(chuàng)建歷史數(shù)據(jù)的聚合，同時丟棄原始的原始記錄。

總結(jié)：選擇有效的存儲，只保留重要的數(shù)據(jù)

在建立物聯(lián)網(wǎng)可觀察性堆棧時，必須決定在哪里存儲數(shù)據(jù)并選擇合適的可觀察性后端。在本文中，描述了在做出優(yōu)化成本效率和物聯(lián)網(wǎng)擴展決策時需要考慮的各個方面。要記住的要點如下:

優(yōu)化存儲選擇：評估可觀察性存儲的訪問模式，并根據(jù)需求定制數(shù)據(jù)庫。只有在確信通用數(shù)據(jù)庫足夠時才選擇通用數(shù)據(jù)庫。否則，請使用經(jīng)過實戰(zhàn)測試的可觀察性數(shù)據(jù)庫，以獲得更好的可擴展性。

設置數(shù)據(jù)采樣：采用數(shù)據(jù)采樣技術來節(jié)省存儲成本，而不會影響關鍵的見解。

微調(diào)保留策略：配置保留策略以丟棄過時的數(shù)據(jù)，確保存儲保持精益，從而節(jié)省更多的存儲成本。