監控訊息

本指南說明如何監控傳送至製造業資料引擎 (MDE) 的訊息、這些訊息在處理管道中的流動方式，以及診斷因設定或潛在系統問題而發生的任何問題。

如要監控透過 MDE 傳送的訊息，請使用 operations-log BigQuery 表格。如果 MDE 管道的某個步驟無法處理訊息，系統會將訊息傳送至 operations-log 資料表，並指出該步驟和失敗原因。

所有失敗的訊息都會寫入這個資料表，但您可以設定 MDE，將成功訊息也寫入 operations-log 資料表。這項設定有助於排解問題，但不應保持開啟，因為這可能會在系統中產生大量額外流量，並降低實際工作環境的效能。

REST

執行下列 REST API 要求，設定 operations-log 表格：

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

其中：

  • ALL：所有訊息都會傳送至 operations-log 表格，以供處理管道中的每個步驟使用。
  • ERROR：只有在任何處理步驟中失敗的訊息，才會傳送到 operations-log 表格。

處理步驟

如要診斷訊息在通過處理管道時遭到拒絕的原因，瞭解不同的處理步驟及其用途會很有幫助。詳情請參閱「MDE 架構」。

  1. message-mapper：讀取原始 JSON，與對應的 message-class 比對，並使用 Whistle 處理，發出一個或多個記錄。
  2. configuration-manager：如果系統中沒有標記，就會建立新的標記，並將適當類型 (中繼資料 bucket、接收器和轉換) 中定義的所有屬性新增至記錄。
  3. metadata-manager：解析這項記錄的所有中繼資料參照、更新系統中繼資料例項 (如有收到新的例項)，並在設定允許的情況下，將具體化的中繼資料新增至記錄。
  4. bigquery-sink：將記錄對應至適當的型別結構，並傳送至對應的 PubSub 主題，以便寫入 BigQuery。
  5. pubsub-sink：將記錄對應至 pubsub Proto 或 JSON 結構，並傳送至對應的主題。
  6. GCSWriter：寫入從 input-messages 主題收到的原始資料，以及經過中繼資料管理員處理的資料。
  7. BigtableWriter：將資料寫入 Bigtable。
  8. GCSReader：從 Cloud Storage 讀取檔案，並將訊息傳送至 input-messages。

診斷訊息未顯示在設定的接收器中

如果傳送至 MDE 的訊息未出現在已設定的接收器中，請先確認類型已正確設定接收器 (如「類型」一節所述)，且您在 BigQuery 中查詢的資料表正確無誤。請注意，資料表是以類型命名。

如果設定正確無誤，您必須使用 operations-log 資料表診斷問題。您可以從一般查詢開始，依 event_timestamp 排序或篩選訊息傳送時間，如下列範例所示：

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
ORDER BY
  event_timestamp desc
LIMIT 100;

你也可以使用 source_message_id 篩選特定訊息。這個 ID 是 Pub/Sub 在發布訊息時指派的。如果您使用 gcloud CLI 從指令列發布訊息，系統會傳回已發布訊息的 messageId。

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) <= CURRENT_DATE()
  AND source_message_id = 'PubSubMessageId';

如果找不到訊息或訊息數量過多，可以根據原始訊息的屬性進行篩選。系統一律會將訊息記錄在 payload 欄位中，並儲存為 JSON 欄位，方便您使用 TO_JSON_STRING 和 % 尋找含有所需文字的訊息。

SELECT
  *
FROM
  `mde_system.operations-log`
WHERE
  DATE(event_timestamp) = CURRENT_DATE()
  AND TO_JSON_STRING(payload) LIKE "%TEXT-TO-FIND%"
ORDER BY
  event_timestamp DESC;

在 operations-log 表格中找到訊息後，查看 error-message 欄，瞭解訊息遭拒的原因。最常見的錯誤如下：

  • 無法將收到的郵件與設定管理員中的任何已註冊郵件類別相符。
  • 找不到訊息類別「<MESSAGE_CLASS_NAME>」的剖析器。
  • 跳過訊息處理程序，因為無法還原序列化 (訊息不是有效的 JSON)。
  • 剖析器 <PARSER_NAME> 無法建構有效訊息。訊息缺少時間戳記欄位。
  • 剖析器 <PARSER_NAME> 無法建構有效訊息。訊息缺少 tagName 欄位或該欄位為空白。
  • 剖析器 <PARSER_NAME> 無法建構有效訊息。訊息時間戳記超出支援範圍。

找出並修正導致訊息傳送失敗的錯誤後，訊息就會開始傳送到各自的接收器。