Surveiller les messages

Ce guide explique comment surveiller les messages envoyés à Manufacturing Data Engine (MDE), comment ils transitent par le pipeline de traitement et comment diagnostiquer les problèmes qui peuvent survenir en raison de la configuration ou de problèmes potentiels du système.

Pour surveiller les messages qui transitent par MDE, vous devez utiliser la table BigQuery operations-log. Chaque fois qu'une étape du pipeline MDE ne parvient pas à traiter un message, elle l'envoie à la table operations-log en indiquant l'étape et la raison de l'échec.

Tous les messages ayant échoué sont écrits dans cette table. Toutefois, vous pouvez configurer MDE pour qu'il écrive également les messages réussis dans la table operations-log. Cela peut être utile pour déboguer des problèmes, mais ne doit pas être laissé activé, car cela peut générer beaucoup de trafic supplémentaire dans le système et dégrader les performances en production.

REST

Exécutez la requête d'API REST suivante pour configurer la table operations-log :

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

Où :

  • ALL : tous les messages seront envoyés à la table operations-log pour chaque étape du pipeline de traitement.
  • ERROR : seuls les messages pour lesquels une étape de traitement a échoué seront envoyés à la table operations-log.

Étapes de traitement

Pour comprendre pourquoi un message est refusé lors de son passage dans le pipeline de traitement, il est utile de connaître les différentes étapes de traitement et leur fonctionnement. Pour en savoir plus, consultez Architecture MDE.

  1. message-mapper : lit le fichier JSON d'origine, le fait correspondre à la message-class correspondante et le traite à l'aide de Whistle pour émettre un ou plusieurs enregistrements.
  2. configuration-manager : crée un tag dans le système s'il n'existe pas déjà et ajoute à l'enregistrement toutes les propriétés définies dans le type approprié (buckets de métadonnées, récepteurs et transformations).
  3. metadata-manager : résout toutes les références de métadonnées de cet enregistrement, met à jour les instances de métadonnées système si une nouvelle est reçue, ajoute des métadonnées concrètes à l'enregistrement si elles sont configurées pour le faire.
  4. bigquery-sink : mappe l'enregistrement à la structure de type appropriée et l'envoie au sujet Pub/Sub correspondant pour qu'il soit écrit dans BigQuery.
  5. pubsub-sink : mappe l'enregistrement à la structure Proto ou JSON Pub/Sub et l'envoie au sujet correspondant.
  6. GCSWriter : écrit à la fois les données brutes telles qu'elles sont reçues du sujet input-messages et les données traitées après leur passage dans le gestionnaire de métadonnées.
  7. BigtableWriter : écrit des données dans Bigtable.
  8. GCSReader : lit les fichiers depuis Cloud Storage et envoie les messages à input-messages.

Diagnostiquer les messages qui ne s'affichent pas dans leur récepteur configuré

Si vous envoyez un message à MDE et qu'il ne se trouve pas dans le récepteur configuré, vérifiez d'abord que le type a correctement configuré le récepteur (comme expliqué dans la section "Type") et que vous interrogez la bonne table dans BigQuery. N'oubliez pas que la table porte le nom du type.

Si cette configuration est correcte, vous devez utiliser la table operations-log pour diagnostiquer le problème. Vous pouvez commencer par une requête générale, en la triant par event_timestamp ou en la filtrant sur la date d'envoi du message, comme le montre l'exemple suivant :

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

Vous pouvez également utiliser source_message_id pour filtrer un message spécifique. Cet ID est attribué par Pub/Sub lors de la publication d'un message. Si vous utilisez la gcloud CLI pour publier un message à partir de la ligne de commande, elle renvoie le messageId du message publié.

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

Si vous ne trouvez pas le message ou s'il y en a trop, vous pouvez le filtrer en fonction d'un attribut du message d'origine. Le message est toujours consigné dans le champ payload avec l'état dans lequel la dernière étape l'a laissé. Il est enregistré dans un champ JSON, ce qui facilite l'utilisation de TO_JSON_STRING et de % pour rechercher les messages contenant le texte souhaité.

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;

Une fois que vous avez trouvé votre message dans le tableau operations-log, consultez la colonne error-message pour connaître la raison du refus. Voici les erreurs les plus courantes :

  • Impossible de faire correspondre le message entrant à l'une des classes de messages enregistrées dans le gestionnaire de configuration.
  • Aucun analyseur trouvé pour la classe de message <MESSAGE_CLASS_NAME>.
  • Le traitement du message est ignoré, car il n'a pas pu être désérialisé (le message n'est pas un fichier JSON valide).
  • Impossible de créer un message valide avec l'analyseur <PARSER_NAME>. Le champ des codes temporels est manquant dans le message.
  • Impossible de créer un message valide avec l'analyseur <PARSER_NAME>. Le champ tagName du message est manquant ou vide.
  • Impossible de créer un message valide avec l'analyseur <PARSER_NAME>. Le code temporel du message est en dehors des limites acceptées.

Une fois que vous aurez identifié et corrigé l'erreur à l'origine de l'échec de l'envoi du message, les messages commenceront à arriver dans leurs récepteurs respectifs.