View a markdown version of this page

join - CloudWatch Amazon-Protokolle

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

join

Kombiniert Protokollereignisse aus einer Quellprotokollgruppe mit Ereignissen aus einer anderen Protokollgruppe oder einem Abfrageergebnis, das auf einem passenden Feld basiert.

Verwenden Sie den join Befehl, um verwandte Protokollereignisse aus verschiedenen Quellen wie Protokollgruppen mithilfe gemeinsamer Schlüssel wie übereinstimmende Anforderungskennungen oder Transaktions-IDs zu korrelieren.

Syntax

join type=<join_type> left=<left_alias> right=<right_alias> 
    where <left_alias>.<field>=<right_alias>.<field> 
    (SOURCE <right_log_group>)
Parameters

  • <right_log_group>— Die sekundäre Datenquelle, mit der eine Verbindung hergestellt werden soll.

  • <left_alias>und <right_alias> — Aliase zur Unterscheidung von Feldern aus den linken (primären) und rechten (sekundären) Datenquellen.

  • where <field>— Gibt das Feld an, das als Join-Schlüssel verwendet wird. Das Feld muss in beiden Datenquellen vorhanden sein.

  • type=<join_type>(optional) — Gibt den Join-Typ an. Folgende sind gültige Werte:

    • inner(Standard) — Gibt nur übereinstimmende Datensätze zurück

    • left— Gibt alle Datensätze aus der primären Datenquelle und übereinstimmende Datensätze aus der sekundären Datenquelle zurück

Beispiele

Beispiel Beispiel 1: Korrelieren Sie API Gateway-Anfragen mit Lambda-Ausführungsprotokollen

Dieses Beispiel zeigt, wie Sie API Gateway-Zugriffsprotokolle mit Lambda-Funktionsprotokollen verknüpfen, um eingehende Anfragen mit ihrer Backend-Verarbeitung zu korrelieren. Dies ist nützlich, um Probleme bei durchgängigen Anforderungsabläufen zu beheben und zu ermitteln, welche Lambda-Aufrufe bestimmten API-Anfragen entsprechen.

filter status >= 500
| join type=inner left=api right=lambda 
    where api.requestId=lambda.requestId 
    (SOURCE '/aws/lambda/my-function')
| fields api.requestId, api.status, api.latency, lambda.duration, lambda.memoryUsed
| sort api.latency desc

Diese Abfrage:

  1. Fragt API Gateway-Zugriffsprotokolle ab und filtert nach Serverfehlern (Status >= 500)

  2. Verbindet sich mit Lambda-Funktionsprotokollen unter Verwendung des requestId Felds, das in beiden Protokollquellen erscheint

  3. Verwendet Aliase (apiundlambda), um Felder aus jeder Quelle zu unterscheiden

  4. Gibt kombinierte Informationen zurück, die die API-Latenz zusammen mit der Lambda-Ausführungsdauer und der Speichernutzung zeigen

  5. Sortiert die Ergebnisse nach API-Latenz, um die langsamsten Anfragen zu identifizieren

Beispiel Beispiel 2: Verfolgen Sie verteilte Transaktionen über Microservices

Beim Debuggen von Problemen in einer Microservices-Architektur müssen Sie häufig eine Transaktion über mehrere Dienste hinweg verfolgen. Dieses Beispiel zeigt, wie Logs von zwei verschiedenen Diensten mithilfe einer gemeinsamen Transaktions-ID verknüpft werden.

filter eventType = "ORDER_CREATED"
| join type=left left=order right=payment 
    where order.transactionId=payment.transactionId 
    (SOURCE '/aws/lambda/payment-service')
| filter payment.eventType = "PAYMENT_PROCESSED" or !ispresent(payment.eventType)
| fields order.transactionId, order.orderId, order.customerId, 
    payment.paymentStatus, payment.amount
| filter payment.paymentStatus != "SUCCESS" or !ispresent(payment.paymentStatus)

Diese Abfrage:

  1. Beginnt mit Ereignissen zur Auftragserstellung aus dem Bestellservice

  2. Verwendet aleft join, um alle Bestellungen einzuschließen, auch solche ohne übereinstimmende Zahlungsdaten

  3. Verbindet sich mithilfe des gemeinsamen transactionId Felds mit Ereignissen der Zahlungsabwicklung

  4. Filtert die Endergebnisse, sodass nur Bestellungen mit fehlgeschlagenen Zahlungen oder fehlenden Zahlungsaufzeichnungen angezeigt werden

Die Verknüpfung nach links ist hier wichtig, da sie sicherstellt, dass Bestellungen angezeigt werden, die zwar erstellt wurden, für die jedoch nie ein entsprechendes Zahlungsereignis aufgetreten ist, was auf einen Systemausfall hindeuten könnte.

Behavior

  • Die primäre Datenquelle (linke Seite) wird zuerst verarbeitet.

  • Die sekundäre Datenquelle wird anhand des angegebenen Join-Schlüssels ausgewertet und abgeglichen.

  • Der Abgleich erfolgt mithilfe eines Gleichheitsvergleichs im Join-Feld.

  • Bei Linksverknüpfungen werden Datensätze aus der primären Datenquelle beibehalten, für sekundäre Felder werden Nullwerte verwendet.

Hinweise und Einschränkungen

  • Nur Gleichheitsbedingungen (=) werden unterstützt.

  • Pro Abfrage wird nur ein Join-Befehl unterstützt.

  • Join-Schlüssel müssen in beiden Datenquellen vorhanden sein und einen kompatiblen Typ haben.

  • Abfragen, die Join verwenden, können mehr Daten scannen und höhere Kosten verursachen.

  • Die Anzahl der eindeutigen Schlüsselwerte in der sekundären Datenquelle ist auf 50.000 begrenzt, um die Abfrageleistung sicherzustellen.

  • Unterabfragen auf der rechten Seite der Verknüpfung werden nicht unterstützt.

Zugehörige Befehle