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
<a name="CWL_QuerySyntax-Join"></a>

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 zu korrelieren. Verwenden Sie dabei Schlüssel, die allen gemeinsam sind, z. B. übereinstimmende Anforderungskennungen oder Transaktionen. IDs

**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, um Felder von den linken (primären) und rechten (sekundären) Datenquellen zu unterscheiden.
+ `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**  


**Example Beispiel 1: API-Gateway-Anfragen mit Lambda-Ausführungsprotokollen korrelieren**  
Dieses Beispiel zeigt, wie API Gateway Gateway-Zugriffsprotokolle mit Lambda-Funktionsprotokollen verknüpft werden, um eingehende Anfragen mit ihrer Backend-Verarbeitung zu korrelieren. Dies ist nützlich, um Probleme mit end-to-end Anforderungsabläufen zu beheben und festzustellen, 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 sie nach Serverfehlern (Status >= 500)

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

1. Verwendet Aliase (`api`und`lambda`), um Felder aus den einzelnen Quellen zu unterscheiden

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

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

**Example Beispiel 2: Verfolgen Sie verteilte Transaktionen über Microservices hinweg**  
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 vom Bestellservice

1. Benutzt a`left join`, um alle Bestellungen einzubeziehen, auch solche ohne übereinstimmende Zahlungsbelege

1. Verbindet sich mithilfe des gemeinsam genutzten `transactionId` Felds mit Ereignissen zur Zahlungsabwicklung

1. Filtert die Endergebnisse so, dass nur Bestellungen mit fehlgeschlagenen Zahlungen oder fehlenden Zahlungsdatensätzen angezeigt werden
Die linke Verknüpfung ist hier wichtig, da sie sicherstellt, dass Sie Bestellungen sehen, die zwar erstellt wurden, aber nie ein entsprechendes Zahlungsereignis hatten, 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 für das Join-Feld.
+ Bei linken Verknüpfungen werden Datensätze ohne Übereinstimmung aus der primären Datenquelle mit Nullwerten für sekundäre Felder beibehalten.

**Hinweise und Einschränkungen**  

+ Es werden nur Gleichheitsbedingungen (=) unterstützt.
+ Pro Abfrage wird nur ein Join-Befehl unterstützt.
+ Verbindungsschlü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 des Joins werden nicht unterstützt.

**Zugehörige Befehle**  

+ [Felder](CWL_QuerySyntax-Fields.md)
+ [Filter](CWL_QuerySyntax-Filter.md)
+ [analysieren](CWL_QuerySyntax-Parse.md)
+ [Statistiken](CWL_QuerySyntax-Stats.md)
+ [sortieren](CWL_QuerySyntax-Sort.md)
+ [limit](CWL_QuerySyntax-Limit.md)