Nachrichten beobachten

In diesem Leitfaden wird beschrieben, wie Sie Nachrichten überwachen, die an die Manufacturing Data Engine (MDE) gesendet werden, wie sie durch die Verarbeitungspipeline fließen und wie Sie Probleme diagnostizieren, die aufgrund von Konfigurations- oder potenziellen Systemproblemen auftreten können.

Wenn Sie Nachrichten überwachen möchten, die über MDE übertragen werden, sollten Sie die BigQuery-Tabelle operations-log verwenden. Wenn bei einem Schritt der MDE-Pipeline eine Nachricht nicht verarbeitet werden kann, wird sie an die Tabelle operations-log gesendet. Dort werden der Schritt und der Grund für den Fehler angegeben.

Alle fehlgeschlagenen Nachrichten werden in diese Tabelle geschrieben. Sie können MDE jedoch so konfigurieren, dass auch erfolgreiche Nachrichten in die Tabelle operations-log geschrieben werden. Dies ist bei der Fehlerbehebung hilfreich, sollte aber nicht aktiviert bleiben, da es viel zusätzlichen Traffic im System erzeugen und die Leistung in der Produktion beeinträchtigen kann.

REST

Führen Sie die folgende REST API-Anfrage aus, um die Tabelle operations-log zu konfigurieren:

POST /configuration/v1/environment

{
  "operationsLogLevel": "ALL"
}

Wobei:

  • ALL: Alle Nachrichten werden für jeden Schritt in der Verarbeitungspipeline an die Tabelle operations-log gesendet.
  • ERROR: Nur Nachrichten, bei denen einer der Verarbeitungsschritte fehlgeschlagen ist, werden an die operations-log-Tabelle gesendet.

Verarbeitungsschritte

Um herauszufinden, warum eine Nachricht bei der Verarbeitung abgelehnt wird, ist es hilfreich, die verschiedenen Verarbeitungsschritte zu kennen und zu wissen, was sie tun. Weitere Informationen finden Sie unter MDE-Architektur.

  1. message-mapper: Liest das ursprüngliche JSON, gleicht es mit der entsprechenden Nachrichtenklasse ab und verarbeitet es mit Whistle, um einen oder mehrere Datensätze auszugeben.
  2. configuration-manager: Erstellt ein neues Tag im System, falls es noch nicht vorhanden ist, und fügt dem Datensatz alle definierten Eigenschaften im entsprechenden Typ hinzu (Metadaten-Buckets, Senken und Transformationen).
  3. metadata-manager: Löst alle Metadatenreferenzen dieses Datensatzes auf, aktualisiert die Systemmetadateninstanzen, wenn eine neue empfangen wird, und fügt dem Datensatz materialisierte Metadaten hinzu, wenn dies so konfiguriert ist.
  4. bigquery-sink: Ordnet den Datensatz der entsprechenden Typstruktur zu und sendet ihn an das entsprechende Pub/Sub-Thema, damit er in BigQuery geschrieben wird.
  5. pubsub-sink: Ordnet den Datensatz der Pub/Sub-Proto- oder JSON-Struktur zu und sendet ihn an das entsprechende Thema.
  6. GCSWriter: Schreibt sowohl Rohdaten, wie sie vom input-messages-Thema empfangen werden, als auch verarbeitete Daten, nachdem sie den Metadatenmanager durchlaufen haben.
  7. BigtableWriter: Schreibt Daten in Bigtable.
  8. GCSReader: Liest Dateien aus Cloud Storage und sendet die Nachrichten an input-messages.

Diagnosemeldungen werden nicht in der konfigurierten Senke angezeigt

Wenn Sie eine Nachricht an MDE senden und sie nicht im konfigurierten Senkenziel angezeigt wird, prüfen Sie zuerst, ob das Senkenziel für den Typ richtig konfiguriert wurde (wie im Abschnitt „Typ“ beschrieben) und ob Sie die richtige Tabelle in BigQuery abfragen. Denken Sie daran, dass die Tabelle nach dem Typ benannt ist.

Wenn das richtig konfiguriert ist, müssen Sie die Tabelle operations-log verwenden, um das Problem zu diagnostizieren. Sie können mit einer allgemeinen Anfrage beginnen und entweder nach event_timestamp sortieren oder nach dem Zeitpunkt filtern, zu dem die Nachricht gesendet wurde, wie im folgenden Beispiel gezeigt:

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

Sie können auch das source_message_id verwenden, um nach einer bestimmten Nachricht zu filtern. Diese ID wird von Pub/Sub beim Veröffentlichen einer Nachricht zugewiesen. Wenn Sie die gcloud CLI verwenden, um eine Nachricht über die Befehlszeile zu veröffentlichen, wird die messageId der veröffentlichten Nachricht zurückgegeben.

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

Wenn Sie die Nachricht nicht finden oder es zu viele Nachrichten gibt, können Sie nach einem Attribut der ursprünglichen Nachricht filtern. Die Nachricht wird immer im Feld payload mit dem Status protokolliert, in dem sie sich nach dem letzten Schritt befindet. Sie wird in einem JSON-Feld gespeichert, sodass es einfacher ist, TO_JSON_STRING zu verwenden und mit % nach Nachrichten zu suchen, die den gewünschten Text enthalten.

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;

Wenn Sie Ihre Nachricht in der operations-log-Tabelle gefunden haben, sehen Sie in der Spalte error-message nach, warum die Nachricht abgelehnt wurde. Die häufigsten Fehler sind:

  • Die eingehende Nachricht konnte keiner der registrierten Nachrichtenklassen im Konfigurationsmanager zugeordnet werden.
  • Für die Nachrichtenklasse <MESSAGE_CLASS_NAME> wurden keine Parser gefunden.
  • Die Verarbeitung der Nachricht wird übersprungen, da sie nicht deserialisiert werden konnte (die Nachricht ist kein gültiges JSON).
  • Mit dem Parser <PARSER_NAME> konnte keine gültige Nachricht erstellt werden. In der Nachricht fehlt das Feld „Zeitstempel“.
  • Mit dem Parser <PARSER_NAME> konnte keine gültige Nachricht erstellt werden. In der Nachricht fehlt das Feld „tagName“ oder es ist leer.
  • Mit dem Parser <PARSER_NAME> konnte keine gültige Nachricht erstellt werden. Der Zeitstempel der Nachricht liegt außerhalb des unterstützten Bereichs.

Nachdem Sie den Fehler, der zum Fehlschlagen der Nachricht führt, behoben haben, werden die Nachrichten in den entsprechenden Senken empfangen.