一年前，我們推出了促銷項目的試點版本 .
最初，該專案被稱為Road-To-Barcelona，後來變成了Road-To-Berlin（因此截圖中的R2B），最後被稱為xRide。
這個專案的主要想法是：我們不想提供集中式汽車或踏板車租賃服務（我們談論的是踏板車，又稱為電動摩托車，而不是踢踏板車/踏板車），我們想要建立一個去中心化租賃平台。 關於我們所遇到的困難 .
最初，該計畫專注於汽車，但由於截止日期、與製造商的溝通時間極長以及大量的安全限制，最終選擇了電動滑板車作為試點。
用戶在手機上安裝iOS或Android應用程序，接近自己喜歡的滑板車，之後手機和滑板車建立點對點連接，交換ETH，用戶可以透過打開滑板車開始騎行電話。 旅行結束時，還可以使用用戶手機錢包中的以太坊支付旅行費用。
除了踏板車之外，用戶還在應用程式中看到了“智慧充電器”，透過存取充電器，用戶可以在當前電池電量低時自行更換。
這就是我們去年 XNUMX 月在兩個德國城市波昂和柏林推出的試點計畫的大致情況。
然後，有一天，在波恩，一大早，我們的支援團隊（在現場維護滑板車的工作狀態）接到警報：其中一輛滑板車消失得無影無蹤。
如何找到並歸還？
在本文中，我將討論這一點，但首先是討論我們如何建立自己的物聯網平台以及如何監控它。
監控什麼以及為何監控：踏板車、基礎設施、充電站？
那麼，我們想要在專案中監控什麼？
首先，這些是滑板車本身- 電動滑板車本身相當昂貴，在沒有充分準備的情況下不能啟動這樣的項目；如果可能的話，你想收集盡可能多的關於滑板車的信息：關於它們的位置、充電水平， ETC。
此外，我還想監控我們自己的 IT 基礎架構的狀態 - 資料庫、服務以及它們工作所需的一切。 還需要監控「智慧型充電器」的狀態，以防它們發生故障或電池電量耗盡。
滑板車
我們的滑板車是什麼？我們想了解它們什麼？
第一件也是最重要的事情是 GPS 座標，因為有了它們，我們可以了解它們在哪裡以及它們在哪裡移動。
接下來是電池充電，透過它我們可以確定滑板車的充電即將結束並發送果汁機或至少警告用戶。
當然，還需要檢查我們的硬體組件發生了什麼情況：
- 藍牙有用嗎？
- GPS模組本身可以運作嗎？
- 我們還遇到一個問題，即 GPS 可能會發送錯誤的座標並卡住，這只能透過對踏板車進行額外檢查來確定，
並儘快通知支援人員解決問題
- 我們還遇到一個問題，即 GPS 可能會發送錯誤的座標並卡住，這只能透過對踏板車進行額外檢查來確定，
最後：檢查軟體，從作業系統和處理器、網路和磁碟負載開始，最後檢查我們自己的更具體的模組（, ).
硬體規格
我們的「鐵」部分是什麼？
考慮到最短的時間框架和快速原型設計的需要，我們選擇了最簡單的實作和元件選擇選項 - Raspberry Pi。
除了 Rpi 本身之外，我們還有一塊定制板（我們自己開發並從中國訂購，以加快最終解決方案的組裝過程）和一組組件 - 繼電器（用於打開/關閉滑板車），電池充電讀取器、調變解調器、天線。 所有這些都緊湊地包裝在一個特殊的“xRide 盒子”中。
還應該指出的是，整個盒子由一個額外的行動電源供電，而該行動電源又由踏板車的主電池供電。
這使得即使在行程結束後也可以使用監控並打開踏板車，因為主電池在將點火鑰匙轉到「關閉」位置後立即關閉。
碼頭工人？ 普通Linux？ 和部署
讓我們回到監控，那麼 Raspberry - 我們有什麼？
我們首先想要使用 Docker 來加速部署、更新和交付元件到實體設備的過程。
不幸的是，我們很快就發現，RPi 上的 Docker 雖然可以工作，但會產生大量開銷，特別是在功耗方面。
使用「本機」作業系統的差異雖然沒那麼大，但仍然足以讓我們警惕過快失去電量的可能性。
第二個原因是我們在 Node.js 上的合作夥伴函式庫之一（原文如此！）－系統中唯一不是用 Go/C/C++ 寫的元件。
該庫的作者沒有時間提供任何“本地”語言的工作版本。
不僅節點本身不是低效能設備的最優雅的解決方案，而且庫本身非常消耗資源。
我們意識到，即使我們願意，使用 Docker 對我們來說也會產生太大的開銷。 我們做出了有利於本機作業系統並直接在其下工作的選擇。
OS
因此，我們再次選擇了最簡單的選項作為作業系統並使用 Raspbian（適用於 Pi 的 Debian 版本）。
我們所有的軟體都是用Go寫的，所以我們系統中主要的硬體代理模組也是用Go寫的。
他負責使用 GPS、藍牙、讀取電量、打開滑板車等。
部署
立即出現的問題是需要實現一種向設備提供更新（OTA）的機制 - 既更新我們的代理/應用程式本身，又更新作業系統/韌體本身（因為新版本的代理可能需要更新核心）或系統元件、庫等）。
經過長時間的市場分析，發現有許多為設備提供更新的解決方案。
從相對簡單、主要面向更新/雙啟動的實用程式（如 swupd/SWUpdate/OSTree）到成熟的平台（如 Mender 和 Balena）。
首先，我們認為我們對端到端解決方案感興趣，所以選擇立即落在了平台上。
非常 被排除是因為它實際上在其 balenaEngine 中使用了相同的 Docker。
但我注意到，儘管如此，我們最終還是不斷使用他們的產品 用於 SD 卡上的快閃記憶體韌體 - 一個簡單且極其方便的實用程式。
所以，最終的選擇落在了 。 Mender 是一個用於組裝、交付和安裝韌體的完整平台。
總體而言，該平台看起來很棒，但我們花了大約一周半的時間使用修復構建器構建了固件的正確版本。
我們越是沉浸在其複雜的使用過程中，就越清楚地意識到，要完全部署它，我們需要比我們更多的時間。
唉，緊迫的期限意味著我們被迫放棄使用 Mender 並選擇一個更簡單的。
Ansible
在我們的情況下，最簡單的解決方案是使用 Ansible。 幾本劇本就足以開始。
它們的本質是我們只需透過 ssh 從主機（CI 伺服器）連接到我們的 rasberry 並向它們分發更新。
一開始，一切都很簡單 - 你必須與設備位於同一網路上，傾倒是透過 Wi-Fi 完成的。
在辦公室裡，只有十幾個測試樹莓派連接到同一網絡，每個設備都有一個靜態 IP 位址，也在 Ansible Inventory 中指定。
Ansible 將我們的監控代理交付給終端設備
3G / LTE
不幸的是，在我們擁有實際的滑板車之前，Ansible 的這個用例只能在開發模式下運作。
因為如您所知，滑板車不會連接到一個 Wi-Fi 路由器，並不斷等待網路上的更新。
事實上，除了移動 3G/LTE 之外，踏板車根本無法進行任何連接（即使如此，也並非始終如此）。
這立即帶來了許多問題和限制，例如連接速度低和通訊不穩定。
但最重要的是，在 3G/LTE 網路中，我們不能簡單地依賴分配給網路的靜態 IP。
一些 SIM 卡提供者部分解決了這個問題；甚至有專門為具有靜態 IP 位址的物聯網設備設計的特殊 SIM 卡。 但我們無法使用這類 SIM 卡，也無法使用 IP 位址。
當然，有一些想法可以在像Consul 這樣的地方進行某種IP 位址註冊，即服務發現，但我們不得不放棄這種想法，因為在我們的測試中，IP 位址可能會經常更改，導致極大的不穩定。
因此，傳遞指標的最方便的用途不是使用拉模型（我們將在設備上獲取必要的指標），而是使用推模型，將指標從設備直接傳遞到伺服器
VPN
作為這個問題的解決方案，我們選擇了 VPN - 特別是 .
系統啟動時的客戶端（踏板車）連接到 VPN 伺服器並且能夠連接到它們。 此隧道用於傳送更新。
理論上，同一個隧道可以用於監控，但這樣的連接比簡單的推送更複雜，可靠性也更低。
雲端資源
最後，有必要監控我們的雲端服務和資料庫，因為我們使用 Kubernetes 來監控它們，理想情況下，在叢集中部署監控會盡可能簡單。 理想情況下，使用 ，因為對於部署，我們在大多數情況下都會使用它。 當然，要監控雲，您需要使用與踏板車本身相同的解決方案。
給定
呼，我們好像已經把描述整理好了，讓我們把最後需要的東西列出來：
- 快速解決方案，因為在開發過程中就需要進行監控
- 數量/數量－需要許多指標
- 需要日誌收集
- 可靠性 - 數據對於發射成功至關重要
- 你不能使用拉模型 - 你需要推
- 我們不僅需要硬體的統一監控，還需要雲端的統一監控
最終圖像看起來像這樣
堆疊選擇
因此，我們面臨著選擇監控堆疊的問題。
首先，我們正在尋找最完整的一體化解決方案，既能同時滿足我們的所有要求，又能足夠靈活，能夠根據我們的需求自訂其使用。 儘管如此，我們仍然受到硬體、架構和截止日期的許多限制。
有各種各樣的監控解決方案，從成熟的系統開始，例如 , 或 最後提供現成的車隊管理解決方案。
最初，後者對我們來說似乎是一個理想的解決方案，但有些沒有完全監控，有些免費版本的功能受到嚴重限制，有些根本無法滿足我們的“需求”，或者不夠靈活，無法適應我們的場景。 有些已經過時了。
在分析了許多類似的解決方案後，我們很快就得出結論：我們自己組裝一個類似的堆疊會更容易、更快捷。 是的，這比部署完全現成的車隊管理平台更複雜一些，但我們不必妥協。
幾乎可以肯定的是，在所有大量的解決方案中，已經有一個現成的解決方案完全適合我們，但就我們而言，自行組裝某個堆疊並「為我們自己」定制它要快得多，而不是更快。測試現成的產品。
有了這一切，我們並沒有努力自己組裝整個監控平台，而是尋找功能最強大的「現成」堆疊，只需能夠靈活配置它們。
(B)埃爾克？
第一個真正考慮的解決方案是著名的 ELK 堆疊。
其實它應該叫BELK，因為這一切都始於Beats -
當然，ELK是監控領域最著名、最強大的解決方案之一，在日誌收集和處理方面更是如此。
我們打算使用 ELK 來收集日誌並長期儲存從 Prometheus 獲得的指標。
對於視覺化，您可以使用 Grafan。
事實上，新的 ELK 堆疊可以獨立收集指標（metricbeat），Kibana 也可以顯示它們。
但是，ELK 最初是從日誌中發展而來的，到目前為止，指標的功能存在許多嚴重的缺陷：
- 比 Prometheus 慢很多
- 整合的地方比 Prometheus 少得多
- 為他們設定警報很困難
- 指標佔用大量空間
- 在 Kiban 中設定帶有指標的儀表板比在 Grafan 中複雜得多
總的來說，ELK 中的指標比較重，而且還沒有其他解決方案那麼方便，其中現在不僅僅是 Prometheus：TSDB、Victoria Metrics、Cortex 等。 當然，我真的很想立即擁有一個成熟的一體化解決方案，但對於 metricbeat 來說，有太多的妥協。
而 ELK 堆疊本身也有很多困難時刻：
- 它很重，如果您收集相當大量的數據，有時甚至會非常重
- 你需要「知道如何烹飪」它——你需要擴展它，但這並不是一件容易的事
- 精簡免費版本 - 免費版本沒有正常警報，並且在選擇時沒有身份驗證
我必須說，最近最後一點已經變得更好了，另外 （包括認證）定價模式本身開始改變。
但當我們準備部署這個解決方案時，根本沒有任何警報。
也許我們可以嘗試使用 ElastAlert 或其他社群解決方案來建立一些東西，但我們仍然決定考慮其他替代方案。
洛基 - 格拉法納 - 普羅米修斯
目前，一個好的解決方案可能是建立一個純粹基於 Prometheus 作為指標提供者的監控堆疊，Loki 用於日誌，而對於可視化，您可以使用相同的 Grafana。
不幸的是，在專案銷售試點開始時（19 年 0.3 月至 0.4 月），Loki 仍處於 beta 版本 XNUMX-XNUMX，並且在開發開始時不能將其視為生產解決方案根本不。
我還沒有在嚴肅的專案中實際使用 Loki 的經驗，但我可以說 Promtail（收集日誌的代理）對於 kubernetes 中的裸機和 pod 都非常有效。
蜱
也許 ELK 堆疊最有價值（唯一？）的全功能替代品現在只能稱為 TICK 堆疊 - Telegraf、InfluxDB、Chronograf、Kapacitor。
我將更詳細地描述下面的所有元件，但總體思路是這樣的：
- Telegraf - 收集指標的代理
- InfluxDB - 指標資料庫
- Kapacitor - 用於警報的即時指標處理器
- Chronograf - 用於可視化的網路面板
對於 InfluxDB、Kapacitor 和 Chronograf，我們使用官方 helm 圖表來部署它們。
需要注意的是，在最新版本的 Influx 2.0（beta）中，Kapacitor 和 Chronograf 成為了 InfluxDB 的一部分，不再單獨存在
電報
是一個非常輕量級的代理，用於收集狀態機上的指標。
他可以監控大量的一切，從 對
服務器 .
它有許多很酷的優點：
- 快速且輕量級（用 Go 編寫）
- 消耗最少的資源
- 預設推送指標
- 收集所有必要的指標
- 無需任何設定的系統指標
- 硬體指標，例如來自感測器的信息
- 增加您自己的指標非常容易
- 許多開箱即用的插件
- 收集日誌
由於推送指標對我們來說是必要的，因此所有其他優勢都不僅僅是令人愉快的補充。
代理本身收集日誌也非常方便，因為不需要連接額外的實用程式來記錄日誌。
如果您使用，Influx 將為您提供最方便的日誌處理體驗 .
Telegraf 通常是收集指標的絕佳代理，即使您不使用 ICK 堆疊的其餘部分也是如此。
為了方便起見，許多人將它與 ELK 和其他各種時間序列資料庫交叉使用，因為它幾乎可以在任何地方編寫指標。
數據庫
InfluxDB是TICK堆疊的主要核心，即指標的時間序列資料庫。
除了指標之外，Influx 還可以儲存日誌，儘管從本質上來說，它的日誌只是同樣的指標，只是取代了通常的數字指標，主要功能是透過一行日誌文字來完成的。
InfluxDB 也是用 Go 寫的，在我們（不是最強大的）叢集上，與 ELK 相比，它的運行速度似乎要快得多。
Influx 的一大優勢還包括非常方便且豐富的資料查詢 API，我們非常積極地使用它。
缺點 - $$$ 還是縮放？
我們發現 TICK 堆疊只有一個缺點 - 它 親愛。 更。
付費版本有哪些免費版本沒有的功能？
據我們所知，TICK 堆疊的付費版本和免費版本之間的唯一區別是擴展能力。
也就是說，您只能在以下情況下建立具有高可用性的叢集： .
如果你想要完整的HA，你要嘛需要付費，要嘛使用一些拐杖。 有一些社區解決方案 - 例如 看起來像是一個有效的解決方案，但據報道它不適合生產，以及
- 一個簡單的解決方案，透過 NATS 進行資料泵送（它還必須擴展，但這可以解決）。
很遺憾，但它們似乎都被放棄了 - 沒有新的提交，我認為問題是即將發布的新版本 Influx 2.0，其中很多事情都會有所不同（沒有關於尚未縮放）。
官方有免費版本 - 事實上，這是一個原始的HA，但只是透過平衡，
因為所有資料都將寫入負載平衡器後面的所有 InfluxDB 實例。
他有一些 例如覆蓋點的潛在問題以及提前建立指標基礎的需要
（這在 InfluxDB 正常工作期間會自動發生）。
此外， ，這意味著您可能不需要的重複指標（處理和儲存）的額外開銷，但無法將它們分開。
維多利亞指標？
因此，儘管事實上我們對 TICK 堆疊除了付費擴充之外的所有方面都完全滿意，但我們決定看看是否有任何免費解決方案可以取代 InfluxDB 資料庫，同時保留剩餘的 T_CK 元件。
時序資料庫有很多，但最有前途的是Victoria Metrics，它有很多優點：
- 快速而簡單，至少從結果來看是這樣
- 有一個集群版本，現在甚至有很好的評論
- 她可以分片
- 支援InfluxDB協議
我們並不打算基於 Victoria 建立一個完全自訂的堆棧，主要希望是我們可以使用它作為 InfluxDB 的直接替代品。
不幸的是，這是不可能的，儘管事實上支援 InfluxDB 協議，但它僅適用於記錄指標 - 只有 Prometheus API 在「外部」可用，這意味著無法在其上設定 Chronograf。
此外，指標僅支援數字值（我們對自訂指標使用字串值 - 更多內容請參閱參考資料部分） ).
顯然，基於同樣的原因，VM無法像Influx那樣儲存日誌。
另外，要注意的是，在尋找最優解時，Victoria Metrics 還沒有那麼流行，文件小得多，功能也較弱
（我不記得群集版本和分片的詳細描述）。
鹼基選擇
因此，我們決定在試點中仍然將自己限制在單一 InfluxDB 節點。
做出這樣的選擇有幾個主要原因：
- 我們真的很喜歡 TICK 堆疊的全部功能
- 我們已經成功部署它並且效果很好
- 最後期限已經過去，沒有太多時間測試其他選項。
- 我們沒想到負載這麼重
我們在第一階段的試點中沒有太多滑板車，開發過程中的測試也沒有發現任何性能問題。
因此，我們決定對於這個專案來說，一個 Influx 節點就足夠了，不需要擴展（請參閱最後的結論）。
我們已經決定了堆疊和基礎 - 現在關於 TICK 堆疊的其餘組件。
電容器
Kapacitor 是 TICK 堆疊的一部分，該服務可以即時監控進入資料庫的指標並根據規則執行各種操作。
總的來說，它被定位為潛在異常追蹤和機器學習的工具（我不確定這些功能是否有需求），但它最受歡迎的使用場景更為常見——警報。
這就是我們將其用於通知的方式。 當特定踏板車離線時，我們設定了 Slack 警報，智慧充電器和重要基礎設施元件也做了同樣的事情。
這使得快速回應問題以及接收一切恢復正常的通知成為可能。
一個簡單的例子：為我們的「盒子」供電的額外電池已損壞或由於某種原因耗盡了電量；只需安裝新電池，一段時間後我們應該會收到一條通知，告知滑板車的功能已恢復。
在 Influx 2.0 中 Kapacitor 成為 DB 的一部分
計時表
我看過許多不同的監控 UI 解決方案，但我可以說，就功能和使用者體驗而言，沒有什麼能與 Chronograf 相比。
奇怪的是，我們開始使用 TICK 堆疊，並使用 Grafan 作為 Web 介面。
我不會描述它的功能；每個人都知道它設定任何東西的廣泛可能性。
然而，Grafana 仍然是一款完全通用的儀器，而 Chronograf 主要是為與 Influx 配合使用而設計的。
當然，正因為如此，Chronograf 可以提供更聰明或更方便的功能。
也許使用 Chronograf 的主要便利性在於您可以透過 Explore 查看 InfluxDB 的內部。
看起來 Grafana 具有幾乎相同的功能，但實際上，只需點擊幾下滑鼠即可在 Chronograf 中設置儀表板（同時查看那裡的可視化效果），而在 Grafana 中您遲早還是會擁有編輯JSON 配置（當然，Chronograf 允許上傳您手動配置的dashas 並在必要時將它們編輯為JSON - 但在UI 上創建它們後我從來不需要碰它們）。
Kibana 具有更豐富的功能來建立儀表板和控件，但此類操作的使用者體驗非常複雜。
創建方便的儀表板需要一些良好的理解。 儘管 Chronograf 儀表板的功能較少，但製作和自訂它們卻要簡單得多。
儀表板本身除了令人愉悅的視覺風格之外，實際上與 Grafana 或 Kibana 中的儀表板沒有什麼不同：
查詢視窗如下所示：
值得注意的是，除此之外，請了解 InfluxDB 資料庫中的欄位類型，計時器本身有時可以自動幫助您編寫查詢或選擇正確的聚合函數（例如平均值）。
當然，Chronograf 可以盡可能方便地查看日誌。 它看起來像這樣：
預設情況下，Influx 日誌被自訂為使用 syslog，因此它們有一個重要的參數 - 嚴重性。
頂部的圖表特別有用；在上面您可以看到發生的錯誤，顏色會立即清楚地顯示嚴重性是否較高。
有幾次我們透過這種方式發現了重要的錯誤，查看上週的日誌並看到紅色尖峰。
當然，理想情況下應該為此類錯誤設定警報，因為我們已經擁有了這方面的一切。
我們甚至將其打開了一段時間，但在準備試點的過程中，我們發現出現了很多錯誤（包括 LTE 網路不可用等系統錯誤），這也給 Slack 通道帶來了「垃圾郵件」很多，不會造成任何問題。好處很大。
正確的解決方案是處理大多數此類錯誤，調整其嚴重性，然後才啟用警報。
這樣，只有新的或重要的錯誤才會發佈到 Slack。 由於期限緊迫，根本沒有足夠的時間進行這樣的設定。
認證
另外值得一提的是，Chronograf 支援 OAuth 和 OIDC 作為身份驗證。
這非常方便，因為它允許您輕鬆地將其連接到伺服器並建立成熟的 SSO。
在我們的例子中，伺服器是 — 它用於連接到監控，但同一台伺服器也用於驗證滑板車和向後端發出的請求。
“行政”
我要描述的最後一個元件是我們在 Vue 中自己編寫的「管理面板」。
基本上，它只是一個獨立的服務，可以同時顯示來自我們自己的資料庫、微服務的滑板車資訊以及來自 InfluxDB 的指標資料。
此外，許多管理功能也移至此處，例如緊急重新啟動或為支援團隊遠端開鎖。
還有地圖。 我已經提到過，我們從 Grafana 而不是 Chronograf 開始 - 因為 Grafana 地圖以插件的形式提供，我們可以在其中查看滑板車的座標。 不幸的是，Grafana 的地圖小部件的功能非常有限，因此，在幾天內用地圖編寫自己的 Web 應用程式要容易得多，以便不僅可以看到當前的坐標，還可以顯示滑板車所走的路線，能夠過濾地圖上的資料等（所有這些功能我們無法在簡單的儀表板中配置）。
Influx 已經提到的優點之一是能夠輕鬆建立自己的指標。
這使得它可以用於各種各樣的場景。
我們試圖在那裡記錄所有有用的信息：電池電量、鎖定狀態、感測器性能、藍牙、GPS 和許多其他健康檢查。
我們在管理面板上顯示了所有這些。
當然，對我們來說最重要的標準是滑板車的運行狀況 - 事實上，Influx 會自行檢查這一點，並在節點部分以「綠燈」顯示它。
這是透過函數完成的 — 我們用它來了解盒子的性能並向 Slack 發送相同的警報。
順便說一下，我們以《辛普森家庭》中角色的名字來命名滑板車 - 這樣可以很方便地將它們彼此區分開來
總的來說，這種方式更有趣。 經常聽到諸如“夥計們，史密瑟斯死了！”之類的話。
字串指標
重要的是，InfluxDB 不僅允許您儲存數值，就像 Victoria Metrics 的情況一樣。
看起來這並不是那麼重要——畢竟，除了日誌之外，任何指標都可以以數字的形式儲存（只需添加已知狀態的映射——一種枚舉）？
在我們的案例中，至少在一種情況下字串指標非常有用。
恰好我們的「智慧型充電器」的供應商是第三方，我們無法控制開發過程以及這些充電器可以提供的資訊。
結果，收費 API 遠非理想，但主要問題是我們無法始終了解它們的狀態。
這就是 Influx 來拯救的地方。 我們只是將收到的字串狀態寫入 InfluxDB 資料庫欄位中，無需進行任何變更。
有一段時間，只有「線上」和「離線」等值出現，根據這些資訊顯示在我們的管理面板中，並將通知傳送到 Slack。 然而，在某些時候，像「斷開連結」這樣的價值觀也開始出現在那裡。
後來發現，如果充電器在一定次數的嘗試後無法與伺服器建立連接，則在連接遺失後會發送該狀態一次。
因此，如果我們只使用一組固定的值，我們可能無法在正確的時間看到韌體中的這些變化。
一般來說，字串指標提供了更多的使用可能性；您幾乎可以在其中記錄任何資訊。 當然，您也需要小心使用這個工具。
除了通常的指標之外，我們還在 InfluxDB 中記錄了 GPS 位置資訊。 這對於在我們的管理面板中監控滑板車的位置非常有用。
事實上，我們總是知道我們需要的時候在哪裡以及哪一輛踏板車。
當我們尋找踏板車時，這對我們非常有用（請參閱最後的結論）。
基礎設施監控
除了滑板車本身之外，我們還需要監控整個（相當廣泛的）基礎設施。
一個非常通用的架構看起來像這樣：
如果我們突出顯示一個純粹的監控堆疊，它看起來像這樣：
我們想要在雲端檢查的是：
- 數據庫
- 鑰匙斗篷
- 微服務
由於我們所有的雲端服務都位於 Kubernetes 中，因此收集有關其狀態的資訊會很好。
幸運的是，Telegraf 開箱即用，可以收集大量有關 Kubernetes 叢集狀態的指標，而 Chronograf 立即為此提供了漂亮的儀表板。
我們主要監控 Pod 的效能和記憶體消耗。 如果發生跌倒，Slack 會發出警報。
Kubernetes 中有兩種追蹤 Pod 的方法：DaemonSet 和 Sidecar。
兩種方法都有詳細描述 .
我們使用 Telegraf Sidecar，除了指標之外，還收集了 Pod 日誌。
在我們的例子中，我們必須修改日誌。 儘管 Telegraf 可以從 Docker API 中提取日誌，但我們希望透過終端設備收集統一的日誌，並為此為容器配置 syslog。 也許這個解決方案並不美觀，但對其工作沒有任何抱怨，而且日誌在 Chronograf 中顯示得很好。
監控監控？？？
最終，監控系統的老問題出現了，但幸運的是，或者不幸的是，我們根本沒有足夠的時間來解決這個問題。
儘管 Telegraf 可以輕鬆發送自己的指標或從 InfluxDB 資料庫收集指標，以便發送到同一個 Influx 或其他地方。
發現
我們從試點結果中得出了什麼結論？
怎樣才能進行監控呢？
首先，TICK堆疊完全滿足了我們的期望，並給了我們比我們最初預期更多的機會。
我們需要的所有功能都已具備。 我們用它做的一切都沒有問題。
Производительность
免費版本中 TICK 堆疊的主要問題是缺乏擴展能力。 這對我們來說不是問題。
我們沒有收集準確的負載數據/數字，但我們一次收集了大約 30 輛踏板車的數據。
他們每個人都收集了三打以上的指標。 同時，收集設備的日誌。 資料收集和發送每 10 秒發生一次。
需要注意的是，經過一周半的試點，當大部分「童年瘡」被糾正，最重要的問題也已經解決時，我們不得不降低向伺服器發送資料的頻率30秒。 這是必要的，因為我們的 LTE SIM 卡上的流量開始迅速消失。
大部分流量被日誌消耗；指標本身，即使間隔 10 秒，實際上也不會浪費流量。
結果，一段時間後，我們完全禁用了設備上的日誌收集，因為即使沒有持續收集，具體問題已經很明顯了。
在某些情況下，如果仍然需要查看日誌，我們只需透過 VPN 透過 WireGuard 連線即可。
我還要補充一點，每個單獨的環境都是相互分離的，而上述負載僅與生產環境相關。
在開發環境中，我們提出了一個單獨的 InfluxDB 實例，該實例繼續每 10 秒收集一次數據，並且沒有遇到任何效能問題。
TICK - 中小型專案的理想選擇
根據這些信息，我得出的結論是，TICK 堆疊非常適合相對較小的專案或絕對不期望任何 HighLoad 的專案。
如果您沒有數千個 pod 或數百台機器，即使一個 InfluxDB 實例也能很好地處理負載。
在某些情況下，您可能對 Influx Relay 作為原始高可用性解決方案感到滿意。
當然，沒有人會阻止您設定「垂直」擴充功能並簡單地為不同類型的指標分配不同的伺服器。
如果您不確定監控服務的預期負載，或者您保證擁有/將擁有一個非常「重」的架構，我不建議使用免費版本的 TICK 堆疊。
當然，一個簡單的解決方案是購買 - 但在這裡我無法發表評論，因為我自己並不熟悉其中的微妙之處。 除此之外，它非常昂貴，絕對不適合小公司。
在這種情況下，今天我建議透過 Victoria Metrics 收集指標並使用 Loki 收集日誌。
確實，我會再次預約，Loki/Grafana 比現成的 TICK 方便得多（因為它們具有更大的多功能性），但它們是免費的。
這一點很重要：這裡描述的所有資訊都與 Influx 1.8 版本相關，目前 Influx 2.0 即將發布。
雖然我還沒有機會在戰鬥條件下嘗試它，並且很難得出關於改進的結論，但介面肯定變得更好，架構已經簡化（沒有 kapacitor 和 chronograf），
模板出現（“殺手級功能”- ）。 但不幸的是，目前，版本 2 沒有我們選擇第一個版本的關鍵點 - 沒有日誌收集。
該功能也將出現在 Influx 2.0 中，但我們找不到任何截止日期，甚至是大概的截止日期。
如何不打造物聯網平台（現在）
最後，在啟動試點後，在沒有適合我們標準的替代方案的情況下，我們自己組裝了自己成熟的物聯網堆疊。
不過，最近它推出了 Beta 版本 - 遺憾的是，當我們開始製作這個項目時，她不在場。
我們對最終結果以及我們自己組裝的基於 Ansible + TICK + WireGuard 的平台感到非常滿意。 但今天，我建議您在嘗試自己建立自己的物聯網平台之前仔細研究 Balena。
因為最終它可以完成我們所做的大部分事情，而且 OpenBalena 是免費且開源的。
它不僅知道如何發送更新，而且還內建了 VPN 並為在物聯網環境中使用而量身定制。
就在最近，他們甚至發布了他們的 ，很容易連接到他們的生態系統。
嘿，失蹤的踏板車怎麼辦？
於是，「拉爾夫」摩托車就消失得無影無蹤。
我們立即跑去查看「管理面板」中的地圖，其中包含來自 InfluxDB 的 GPS 指標資料。
透過監控數據，我們輕鬆確定該車於前一天21:00左右離開停車場，行駛了約半小時到達某個區域，並在某德國房屋旁停至凌晨5點。
凌晨 5 點之後，沒有收到任何監控數據——這意味著要么額外的電池完全耗盡，要么攻擊者終於找到瞭如何從滑板車上移除智慧硬體的方法。
儘管如此，警方仍然被傳喚到滑板車所在的地址。 滑板車不在那裡。
不過，屋主也對此感到驚訝，因為他昨晚竟然騎著這輛踏板車從辦公室回家。
事實證明，一名支援員工一早就到達並拿起了踏板車，發現其額外的電池已完全耗盡，並將其（步行）帶到了停車場。 並且附加電池因潮濕而失效。
我們偷了自己的踏板車。 順便說一句，我不知道後來如何以及由誰解決了警察案件的問題，但監控效果很好...
來源： www.habr.com