Supervisa mensajes

En esta guía, se describe cómo supervisar los mensajes que se envían a Manufacturing Data Engine (MDE), cómo fluyen a través de la canalización de procesamiento y cómo diagnosticar cualquier problema que pueda ocurrir debido a la configuración o a posibles problemas del sistema.

Para supervisar los mensajes que fluyen a través del MDE, debes usar la tabla de BigQuery operations-log. Cada vez que un paso de la canalización del MDE no puede procesar un mensaje, lo envía a la tabla operations-log, en la que se indica el paso y el motivo del error.

Todos los mensajes fallidos se escriben en esta tabla. Sin embargo, puedes configurar MDE para que también escriba los mensajes exitosos en la tabla operations-log. Esto es útil cuando se depuran problemas, pero no se debe dejar activado, ya que puede generar mucho tráfico adicional en el sistema y podría degradar el rendimiento en la producción.

REST

Ejecuta la siguiente solicitud a la API de REST para configurar la tabla operations-log:

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

Aquí:

  • ALL: Todos los mensajes se enviarán a la tabla operations-log para cada paso de la canalización de procesamiento.
  • ERROR: Solo se enviarán a la tabla operations-log los mensajes que no hayan superado ninguno de los pasos de procesamiento.

Pasos de procesamiento

Para diagnosticar por qué se rechaza un mensaje cuando pasa por la canalización de procesamiento, es útil conocer los diferentes pasos de procesamiento y comprender qué hacen. Para obtener más información, consulta Arquitectura de MDE.

  1. message-mapper: Lee el JSON original, lo compara con la clase de mensaje correspondiente y lo procesa con Whistle para emitir uno o más registros.
  2. configuration-manager: Crea una etiqueta nueva en el sistema si aún no existe y agrega al registro todas las propiedades definidas en el tipo apropiado (buckets de metadatos, receptores y transformaciones).
  3. metadata-manager: Resuelve todas las referencias de metadatos de este registro, actualiza las instancias de metadatos del sistema si se recibe una nueva y agrega metadatos materializados al registro si está configurado para hacerlo.
  4. bigquery-sink: Asigna el registro a la estructura de tipo adecuada y lo envía al tema de Pub/Sub correspondiente para que se escriba en BigQuery.
  5. pubsub-sink: Asigna el registro a la estructura Proto o JSON de Pub/Sub y lo envía al tema correspondiente.
  6. GCSWriter: Escribe los datos sin procesar a medida que se reciben del tema de input-messages, así como los datos procesados después de que pasan por el administrador de metadatos.
  7. BigtableWriter: Escribe datos en Bigtable.
  8. GCSReader: Lee archivos de Cloud Storage y envía los mensajes a input-messages.

Los mensajes de diagnóstico no se muestran en el receptor configurado

Si envías un mensaje al MDE y no está en el receptor configurado, primero verifica que el tipo haya configurado el receptor correctamente (como se explica en la sección Tipo) y que estés consultando la tabla correcta en BigQuery. Recuerda que la tabla lleva el nombre del tipo.

Si la configuración es correcta, debes usar la tabla operations-log para diagnosticar el problema. Puedes comenzar con una consulta general, ya sea ordenando por event_timestamp o filtrándola para cuando se envió el mensaje, como se muestra en el siguiente ejemplo:

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

También puedes usar source_message_id para filtrar un mensaje específico. Pub/Sub asigna este ID cuando se publica un mensaje. Si usas la CLI de gcloud para publicar un mensaje desde la línea de comandos, se devolverá el messageId del mensaje publicado.

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

Si no encuentras el mensaje o hay demasiados, puedes filtrarlos según un atributo del mensaje original. El mensaje siempre se registra en el campo payload con el estado en el que lo dejó el último paso y se guarda en un campo JSON, por lo que es más fácil usar TO_JSON_STRING y % para buscar cualquier mensaje que contenga el texto que deseas.

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;

Una vez que encuentres tu mensaje en la tabla operations-log, consulta la columna error-message para conocer el motivo por el que se rechazó. Los errores más comunes son los siguientes:

  • No se pudo hacer coincidir el mensaje entrante con ninguna de las clases de mensajes registradas en el administrador de configuración.
  • No se encontraron analizadores para la clase de mensaje <MESSAGE_CLASS_NAME>.
  • Se omite el procesamiento del mensaje porque no se pudo deserializar (el mensaje no es un JSON válido).
  • No se pudo construir un mensaje válido con el analizador <PARSER_NAME>. Falta el campo de marcas de tiempo en el mensaje.
  • No se pudo construir un mensaje válido con el analizador <PARSER_NAME>. Falta el campo tagName del mensaje o está en blanco.
  • No se pudo construir un mensaje válido con el analizador <PARSER_NAME>. La marca de tiempo del mensaje está fuera de los límites admitidos.

Después de encontrar y corregir el error que provoca la falla del mensaje, los mensajes comenzarán a llegar a sus respectivos receptores.