## 引言：更加輕鬆地使用 EMQX

最新發布的大規模分散式物聯網 MQTT 訊息伺服器 [EMQX 5.0](https://www.emqx.com/zh/blog/emqx-v-5-0-released) 在[水平擴充套件性](https://www.emqx.com/zh/blog/how-emqx-5-0-achieves-100-million-mqtt-connections)、[訊息傳輸穩定性](https://www.emqx.com/zh/blog/mqtt-over-quic)、[安全性](https://www.emqx.com/zh/blog/how-to-ensure-the-security-of-the-iot-platform)等方面實現了突破性的提升，為使用者物聯閘道器鍵業務提供了保障。在此基礎上，EMQX 5.0 提供了更多便利的功能和設計以幫助使用者更加輕鬆地使用、管理、擴充套件 EMQX。

本文將從可操作性、可觀測性、擴充套件性三個方面，與大家分享 EMQX 5.0 在運維監測、問題排查以及功能擴充套件中的功能最佳化，共同探索如何更快的利用這些最佳化搭建運維監控體系，為物聯網業務帶來更多助力。

## 簡潔易讀的 HOCON 格式配置檔案

EMQX 4.x 配置檔案使用類似 properties 的鍵值格式，對類似陣列的配置項缺乏表達能力，為了讓配置項層級更加清晰，5.0 配置採用標準的 HOCON（ Human-Optimized Config Object Notation ）格式。

```abnf
node {
  name = "emqx@127.0.0.1"
  cookie = "emqxsecretcookie"
  data_dir = "data"
}
listeners.ssl.default {
  bind = "0.0.0.0:8883"
  max_connections = 512000
  ssl_options {
    keyfile = "etc/certs/key.pem"
    certfile = "etc/certs/cert.pem"
    cacertfile = "etc/certs/cacert.pem"
  }
}
```

另一方面，為靈活應對不同場景下使用者對功能引數的要求，EMQX 提供了非常豐富的配置項。儘管大部分配置使用預設值即可，但在 EMQX 4.x 中，單個配置檔案包含了所有配置項以及每個配置項的註釋，對於新手使用者來說想要從中快速找到並修改常用配置具有一定難度。

針對此問題，EMQX 5.0 精簡了預設配置檔案 `emqx.conf`：只保留最常修改的配置，使得預設配置檔案縮減到 100 行以內。如果使用者需要修改其它的預設配置，可以參照 `emqx-example.conf` 檔案，把對應的配置複製到 `emqx.conf` 中即可實現覆蓋。

## 配置熱更新

根據是否可在執行時修改，EMQX 5.0 的配置可以分成**可熱更新**/**不可熱更新**兩種配置。比如節點類相關的引數 `node {}` 包含 Erlang 虛擬機器的啟動引數屬於不可熱更新配置，必須重啟節點才能使修改生效。

可熱更新配置都可以透過 HTTP API 修改成功後立即生效，同時保證配置修改在叢集間同步更新。熱更新基本流程如下：
[![1](http://img.blog.itpub.net/blog/2022/10/10/a10111d193e286a2.png?x-oss-process=style/bb "1")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "1")

透過 HTTP API 更新的配置會持久化到配置檔案中，以確保 EMQX 重啟後配置不丟失。比如在 Dashboard **功能配置 → 監聽器** 頁面新增監聽器後，EMQX 會在 `data/configs/cluster-override.conf` 檔案中持久化如下內容：

```abnf
listeners {
   ...
   tcp {
    my_listener {
      acceptors = 16
      bind = "0.0.0.0:1884"
      limiter {}
      max_connections = 102400
      proxy_protocol = false
      proxy_protocol_timeout = "15s"
      tcp_options {
        active_n = 100
        buffer = "4KB"
        nodelay = false
        reuseaddr = true
        send_timeout = "15s"
        send_timeout_close = true
      }
      zone = "default"
    }
  }
}
```

`cluster-override.conf` 會由 EMQX 內部機制保證叢集內所有節點的一致性。

為了讓 EMQX 內部可以更新本節點獨立的配置，EMQX 還引入了 `local-override.conf`。我們可以透過以下配置結構來理解其工作原理：
[![2](http://img.blog.itpub.net/blog/2022/10/10/1201935ffe154adc.png?x-oss-process=style/bb "2")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "2")

優先順序從高到低，依次是`emqx.conf < ENV < cluster-override.conf < local-override.conf`，比如：當某個配置已經在 Dashboard 上被修改過（即寫入了`cluster-override.conf`）, 那麼使用者再次在`emqx.conf` 手動更新它，則手動更新並不會生效。因為在 `emqx.conf` 中的修改值會被更高優先順序的 `cluster-override.conf` 所覆蓋。

上圖為了說明原理，列出了配置存放的所有（4個）地方。由於 data 下的`xxx-override.conf`檔案都是給 EMQX 自身做持久化的，原則上是**禁止使用者手動修改的**。它們對使用者應該是透明的。因此，對於使用者而言，只有 ENV 和 `emqx.conf`可手動更新，總結最佳實踐為：

- 使用 rpm/deb 包安裝的推薦修改 `/etc/emqx/etc/emqx.conf`。
- 使用容器安裝的推薦使用 ENV 環境變數修改。
- 禁止手動修改 `data/configs/` 目錄。
- 透過 Dashboard 更新過的配置，再次修改 `emqx.conf` 會不生效。

> 推薦使用 Dashboard 上修改配置，因為這樣可以保證叢集內的配置都是一致的。且無需重啟節點。

## 可觀測性

### 強大的日誌功能

日誌為系統排錯、最佳化效能提供可靠資訊來源。EMQX 在日誌資料過載或日誌寫入過慢時，預設啟動過載保護機制，最大限度保證正常業務不被日誌影響。

EMQX 支援符合 [RFC 5424](https://www.ietf.org/rfc/rfc5424.txt) 標準的日誌分級機制，包括：`debug < info < notice < warning < error < critical < alert < emergency` 級別。預設的日誌等級為 `warning`。

進行問題排查時我們需要設定 `debug` 級別日誌，結合上節給出的配置的修改方法，可以有以下 3 種修改日誌等級的方法：

- 修改 `emqx.conf`。

```mel
  log {
    file_handlers.default {
      level = warning
      file = "log/emqx.log"
    }
  }
  ```

- 修改 ENV 環境變數：`EMQX_LOG__FILE__HANDLERS__DEFAULT__LEVEL=debug`。

- 在 Dashboard 上熱更新配置：功能配置 / 日誌 / File Handler / 日誌級別 下拉選單中選擇`debug`。

除了可以修改日誌等級，我們還可以用相同的方法定製日誌的其它功能，如：

- 日誌檔案路徑。
- 日誌輪換（rotation）功能。
- 日誌的過載限流策略。

### 更友好的日誌格式

EMQX 5.0 引入了結構化日誌記錄，現在 EMQX 發出的大多數日誌都有一個 `msg` 欄位，該欄位的文字是一個下劃線分隔的單詞，更加閱讀友好，同時也有助於日誌索引工具對日誌進行索引。

下面是一條典型的日誌：

```yaml
2022-09-15T10:00:02.780474+08:00 [debug] 
authenticator: <>, 
msg: authenticator_result, clientid: mqttx_6c89e818, 
line: 674, mfa: emqx_authentication:authenticate_with_provider/2, 
peername: 127.0.0.1:49206, result: ignore, tag: AUTHN
```

該日誌的含義如下：客戶端 `mqttx_6c89e818` 登入認證時透過內建資料庫的認證結果為`ignore`，導致認證失敗。日誌還包括了認證失敗時執行的函式/程式碼行數。客戶端 `IP:Port`。

同時 EMQX 5.0 還支援 JSON 格式日誌輸出，相比於 4.x 的字串（TEXT）日誌，JSON 結構化格式擁有更豐富的上下文及後設資料資訊，既讓人更容易理解，也更方便使用程式解析，可以輕鬆與各類日誌收集和分析系統如 Elastic Stack（ELK/EFK）整合。

鍵值對方便提取特定的值、過濾和搜尋整個資料集。如果增加新的鍵值對，解析日誌程式也可以直接忽略那些它不關心的鍵，而不是無法解析。

### Trace 排錯利器

透過開啟 `DEBUG` 級別日誌能夠有效地排查各類問題，但這會引起大量日誌落地進而影響 EMQX 整體效能，尤其是在有大量連線與訊息收發的生產環境中，該手段幾乎是不可實施的。

針對這種問題，EMQX 5.0 新增了線上 Trace 排錯功能，允許使用者指定客戶端 ID、主題或 IP 實時過濾輸出 DEBUG 級別日誌。Trace 基於 Erlang 內建強大的 Logger Filter 功能，對整體的訊息吞吐影響可以忽略不計：

- EMQX 使用獨立的 File Handlers 程式來持久化 Trace 的磁碟日誌。
- 每個客戶端連線會在 EMQX 內部生成一個獨立程式來處理它的訊息。
- 當收到客戶端訊息時，這個獨立程式會根據定製的 Trace Filter 判斷是否符合規則（比如：是否為指定的ClientID），如果不符合，則執行原來的傳輸邏輯。反之，則在本程式序列化訊息為二進位制資料，再非同步發訊息給 File Handler。
- File Handlers 負責把二進位制數持久化至 Trace 檔案中。

在此機制下，所有的過濾動作都前置在對接客戶端的獨立程式，過濾掉了大部分不符合規則的日誌，保證了 File Handler 不被大量訊息累積，因此能夠在生產環境中安全的使用。

Trace 幾乎適用於所有疑難雜症，如訊息或資料異常丟棄、客戶端異常斷線、訂閱不生效等。針對特定時間段發生的異常，Trace 允許使用者設定任務啟動/停止時間進行自動化收集，極大的方便使用者使用。

同時，Trace 與 Dashboard 深度適配，使用者可以在 Dashboard 中 **問題分析 → 日誌追蹤** 管理叢集中的 Trace 任務，並實時檢視每個節點上收集到的日誌內容。Trace 極大改善使用者自行排查、診斷客戶端異常行為時的體驗。

### 完善的度量指標以及 Prometheus 整合

日誌和追蹤只能反映 EMQX 執行過程中是否有異常，為了更方便監控執行時壓力指標，EMQX 提供了豐富的度量指標以及指標監控整合，方便使用者以及運維人員進行業務的監控和預警。

在 EMQX 5.0 版本中，使用者可以透過 Dashboard 檢視客戶端實時連線情況以及訊息流入流出速度，透過節點拓撲一目瞭然洞察叢集中所有節點狀態。Dashboard 上還提供多個緯度至多 7 天的歷史指標並透過線上圖表展示，使用者可以直觀的監控業務增長趨勢，避免錯過任何業務波動。

同時 EMQX 支援使用者將指標整合至自己熟悉的監控與告警技術棧，透過配置檔案或 Dashboard 上輕點滑鼠即可在整合 Prometheus、Datadog 等系統。
[![3](http://img.blog.itpub.net/blog/2022/10/10/91e318aa86466730.png?x-oss-process=style/bb "3")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "3")

EMQX 提供了 Grafana 的 Dashboard 的模板檔案。這些模板包含了所有 EMQX 監控資料的展示。使用者可直接匯入到 Grafana 中，即可展示 EMQX 的執行狀態。

模板檔案位於：[emqx_prometheus/grafana_template](https://github.com/emqx/emqx-prometheus/tree/master/grafana_template)。
[![4](http://img.blog.itpub.net/blog/2022/10/10/04829f1552fc1e2d.png?x-oss-process=style/bb "4")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "4")

### 慢訂閱

正常情況下 EMQX 內部訊息傳輸耗時都很低（毫秒級以下），大部分時間消耗都集中在網路傳輸上，針對客戶端偶爾出現訂閱 `QoS1/QoS2` 時延高。EMQX 提供慢訂閱統計功能，方便追蹤 QoS 1 和 QoS 2 訊息到達 EMQX 後，完成訊息傳輸全流程的時間消耗，然後根據配置中的選項，計算訊息的傳輸時延，之後按照時延高低對訂閱者、主題進行統計排名。
[![5](http://img.blog.itpub.net/blog/2022/10/10/e7af28242f969da8.png?x-oss-process=style/bb "5")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "5")

訊息完全傳輸的定義：

- QoS 1 EMQX 收到客戶端的 `PUBACK` 包。
- QoS 2 EMQX 收到客戶端的 `PUBCOMP` 包。

**影響慢訂閱的因素**

1. 釋出者到 EMQX 網路較慢（暫不能探測，功能規劃中）。
2. Hooks 執行慢，如 ACL 檢查、ExHook、規則引擎等阻塞訊息釋出流程。
3. 佇列中訊息堆積太多（PUBLISH 與 SUBSCRIBE 共用同一連線，大量 PUBLISH 訊息處理不及時/堆積也可能導致 SUBSCRIBE 變慢）導致發出時間超時過慢。
4. 訂閱者接收速度過慢。

訊息時效性是物聯網業務重要保障，大量慢訂閱的出現可能是某個功能出現問題的前兆。

啟用慢訂閱後可以及時發現生產環境中訊息堵塞等異常情況，提高使用者對此類情況的感知能力，方便使用者及時調整相關服務。
[![6](http://img.blog.itpub.net/blog/2022/10/10/bc217ec64b8f7f10.png?x-oss-process=style/bb "6")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "6")

### 主題監控

EMQX 支援統計指定主題（無萬用字元）下的訊息收發數量、速率等指標。
[![7](http://img.blog.itpub.net/blog/2022/10/10/9359927766793cb8.png?x-oss-process=style/bb "7")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "7")

以上圖為例，從監控指標中可以看到訊息流出速率遠小於訊息流入速率。多次重置指標還是同樣的結果，可以推測出訂閱端消費能力不足。

### Dashboard 告警

EMQX 對於作業系統（OS） 和 Erlang 虛擬機器（VM）的基本狀態及資源狀態內建了監控告警。EMQX 允許使用者對告警功能進行一定程度的調整以適應實際需要，目前開放了以下配置項：

```clean
sysmon {
   os {
    ## CPU 佔用率的檢查間隔    
    cpu_check_interval = 60s
    ## CPU 佔用率高水位，即 CPU 佔用率達到多少時啟用告警
    cpu_high_watermark = "80%"
    ## CPU 佔用率低水位，即 CPU 佔用率降低到多少時取消告警
    cpu_low_watermark = "60%"
    ## 記憶體佔用率的檢查間隔
    mem_check_interval = 60s
    ## 系統記憶體佔用率高水位，即申請的總記憶體佔比達到多少時啟用告警
    sysmem_high_watermark = "70%"
    ## 程式記憶體佔用率高水位，即單個程式申請的記憶體佔比達到多少時啟用告警
    procmem_high_watermark = "5%"
   }
   vm {
    ## 程式數量的檢查間隔
    process_check_interval = 30s
    ## 程式佔用率高水位，即建立的程式數量與最大數量限制的佔比達到多少時啟用告警
    process_high_watermark = "80%"
    ## 程式佔用率低水位，即建立的程式數量與最大數量限制的佔比降低到多少時取消告警
    process_low_watermark = "60%"
    ## 啟用慢垃圾回收監控
    long_gc = disabled
    ## 慢排程監控
    long_schedule = 240ms
    ## 大 heap 分配監控
    large_heap = 32MB
    ## 啟用分散式埠過忙監控
    busy_dist_port = true
    ## 啟用埠過忙監控
    busy_port = true
   }  
 }
```

可以 Dashboard 上檢視到當前/歷史告警：
[![8](http://img.blog.itpub.net/blog/2022/10/10/ac33d99cccddfc4b.png?x-oss-process=style/bb "8")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "8")

EMQX 計劃在未來版本中提供告警整合 Webhook 功能，允許使用者將告警事件傳送到對應的告警/通知服務，如 Slack、釘釘等，使用者亦可在 Web 服務中擴充套件實現簡訊或郵件告警。

## 擴充套件性

### 新的外掛機制

EMQX 提供了外掛擴充套件機制，4.x 版本中使用者使用外掛時需要將外掛與 EMQX 原始碼一同編譯以解決外掛與EMQX 的程式碼依賴問題，一定程度上限制了外掛的分發與使用。

EMQX 5.0 經過改進，允許透過外掛包的的形式編譯、分發、安裝外掛，當使用者需要擴充套件功能時，可以下載獨立的外掛安裝包，在 Web 介面完成上傳即可進行安裝，整個過程甚至不需要重啟 EMQX 叢集。

同時，一個規範的外掛將會隨身附帶使用說明、外掛主頁地址等資訊，普通使用者可以依照說明快速將外掛用起來，也為外掛開發者提供了與使用者溝通的渠道。

EMQX 5.0 外掛模板可見：[emqx-plugin-template](https://github.com/emqx/emqx-plugin-template)。

### ExHook/gRPC 用於微服務整合

ExHook（**多語言擴充套件鉤子**）基於 gRPC 框架， 允許使用者使用其他程式語言（如Python、Java、Node.js 等）直接向 EMQX 系統掛載鉤子，以接收並處理 EMQX 系統的鉤子事件，達到擴充套件和定製 EMQX 的目的。
[![9](http://img.blog.itpub.net/blog/2022/10/10/b33dc61282aa858e.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development)

ExHook 基於 gPRC 通訊，理論上支援任意語言平臺和微服務，透過 ExHook 可以實現客戶端認證、許可權檢查、資料儲存與改寫訊息流程等業務的整合。

在 EMQX 5.0 中我們允許建立多個 ExHook 例項，併為每個例項提供了詳細的使用情況統計資訊：
[![10](http://img.blog.itpub.net/blog/2022/10/10/efb1c7f7b6b68470.png?x-oss-process=style/bb "10")](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development "10")

同時還可以檢視每個 Exhook 例項註冊的鉤子以及鉤子引數，能夠更好地感知 Exhook 擴充套件負載情況。

EMQX 5.0 Exhooks 介面引數及資料結構詳情請參考：[exhook.proto](https://github.com/emqx/emqx/blob/master/apps/emqx_exhook/priv/protos/exhook.proto)。

## 結語

作為自發布以來最重要的里程碑版本之一，EMQX 5.0 為使用者帶來了足以保障各類資料需求的高效能，以及從實際應用出發、可快速上手的各類實用功能。如前文提到，可操作性與可觀測性的提升將使 EMQX 叢集的運維工作變得更加輕鬆與高效，擴充套件性的增強則為使用者定製更加符合自身需求的 EMQX 提供了便利。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development](https://www.emqx.com/zh/blog/how-emqx-simplifies-iot-development)

易操作、可觀測、可擴充套件，EMQX如何簡化物聯網應用開發

相關文章