监控消息

本指南介绍了如何监控发送到 Manufacturing Data Engine (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 处理该 JSON 以发出一条或多条记录。
  2. configuration-manager：如果系统中尚不存在新标记，则创建该标记，并将记录中的所有已定义属性添加到相应类型（元数据桶、接收器和转换）。
  3. metadata-manager：解析相应记录的所有元数据引用；如果收到新的元数据引用，则更新系统元数据实例；如果配置为这样做，则将具体化元数据添加到记录中。
  4. bigquery-sink：将记录映射到相应的类型结构，并将其发送到相应的 PubSub 主题以写入 BigQuery。
  5. pubsub-sink：将记录映射到 Pub/Sub 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> 构建有效消息。消息时间戳超出支持的范围。

找到并修正导致消息失败的错误后，消息将开始到达各自的接收器。