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.
OTLP-Endpunkte
OpenTelemetry Protocol (OTLP) ist ein Allzweck-Telemetrie-Datenlieferprotokoll, das für die entwickelt wurde. OpenTelemetry CloudWatch OpenTelemetry Endpunkte sind HTTP 1.1-Endpunkte. Sie müssen Ihren OpenTelemetry Collector so konfigurieren, dass er mit dem Senden offener Telemetriedaten beginnt. CloudWatch Weitere Informationen finden Sie unter Erste Schritte.
Logs-Endpunkt
Der Logs-Endpunkt folgt dem Muster https://logs.. Beispiel: Für die AWS-Region.amazonaws.com/v1/logsUS West (Oregon) (us-west-2) Region lautet der Endpunkt https://logs.us-west-2.amazonaws.com/v1/logs. Sie können den obigen Endpunkt verwenden, um Protokolle an eine vorhandene LogGroup und einen LogStream weiterzuleiten. Weitere Informationen LogGroup zur Einrichtung der Aufnahme von Protokolldaten finden Sie unter Konzepte von Amazon CloudWatch Logs.
Sie müssen den CloudWatch OpenTelemetry Logs-Endpunkt konfigurieren LogGroup und LogStream wann Sie ihn aufrufen, indem x-aws-log-group Sie den x-aws-log-stream HTTP-Header auf LogGroup bzw. LogStream den Namen setzen. Weitere Informationen finden Sie unter Erste Schritte.
Der Endpunkt unterstützt die folgenden Authentifizierungsmethoden:
-
AWS Signature Version 4 (SigV4) — Empfohlen für Workloads, die auf ausgeführt werden. AWS Verwendet kurzfristige Anmeldeinformationen mithilfe von IAM-Rollen. Weitere Informationen finden Sie unter AWS Signature Version 4 for API-Anforderungen.
-
Bearer-Token (API-Schlüssel) — Für Workloads, die außerhalb AWS oder in Umgebungen ausgeführt werden, die das SDK nicht unterstützen. AWS Erfordert, dass die Bearer-Token-Authentifizierung für die Ziel-Loggruppe aktiviert ist. Weitere Informationen finden Sie unter Einrichten der Inhaber-Token-Authentifizierung für Protokolle.
Wenn die Größe des Protokollereignisses 1 MB überschreitet, kürzt CloudWatch Logs automatisch bis zu 10 Felder, wobei mit den größten Feldern begonnen wird. Jedes Feld wird nach Bedarf gekürzt, damit die Gesamtgröße des Ereignisses so nah wie möglich an 1 MB bleibt. Die überschüssigen Teile werden als Large Log Objects (LLOs) gespeichert und Felder des LLO-Referenzsystems werden hinzugefügt. Optional können Sie angeben, welche Feldpfade gekürzt werden sollen. Legen Sie dazu den HTTP-Header x-aws-truncatable-fields fest. Die LLOs können mithilfe der GetLogObject-API abgerufen und zurückgestreamt werden. Weitere Informationen finden Sie unter GetLogObject. Unterstützung von Protokollereignissen mit mehr als 1 MB und LLO-Erfahrung ist in den folgenden Ländern verfügbar: USA Ost (Nord-Virginia), USA West (Oregon), Europa (Frankfurt), Asien-Pazifik (Sydney), Asien-Pazifik (Mumbai), USA Ost (Ohio), Europa (Irland), Asien-Pazifik (Tokio) und Asien-Pazifik (Singapur).
Endpunkt der Messwerte
Der Endpunkt der Metriken folgt dem Musterhttps://monitoring.. Für die Region USA West (Oregon) (us-west-2) lautet der Endpunkt beispielsweise AWS
Region.amazonaws.com/v1/metricshttps://monitoring.us-west-2.amazonaws.com/v1/metrics.
Sie müssen Ihren OpenTelemetry Collector so konfigurieren, dass er mit dem Senden von Metriken beginnt CloudWatch. Der Endpunkt unterstützt zwei Authentifizierungsmethoden:
-
AWS Signature Version 4 (SigV4) — Die empfohlene Authentifizierungsmethode mit kurzfristigen Anmeldeinformationen. Weitere Informationen finden Sie unter AWS Signature Version 4 for API-Anforderungen.
-
Bearer-Token (API-Schlüssel) — Für Workloads, die außerhalb ausgeführt werden, AWS oder für Umgebungen, die das SDK nicht unterstützen. AWS Verwendet einen langlebigen API-Schlüssel, der im Header übergeben wird.
AuthorizationWeitere Informationen finden Sie unter Inhaber-Token-Authentifizierung für Metriken einrichten.
Traces-Endpunkt
Der Traces-Endpunkt folgt dem Muster https://xray.. Für die Region USA West (Oregon) (us-west-2) lautet der Endpunkt beispielsweise AWS
Region.amazonaws.com/v1/traceshttps://xray.us-west-2.amazonaws.com/v1/traces.
Sie müssen Ihren OpenTelemetry Collector so konfigurieren, dass er mit dem Senden von Traces beginnen kann CloudWatch. Der Endpunkt authentifiziert Aufrufer mithilfe der Signature-4-Authentifizierung. Weitere Informationen finden Sie unter AWS Signature Version 4 for API-Anforderungen.
RUM-Endpunkt
Der RUM-Endpunkt folgt dem Musterhttps://dataplane.rum.{AWS
Region}.amazonaws.com/v1/rum. Für die Region USA West (Oregon) lautet der Endpunkt beispielsweisehttps://dataplane.rum.us-west-2.amazonaws.com/v1/rum. Dieser Endpunkt verarbeitet clientseitige Telemetriedaten (nur Traces und Protokolldatensätze miteventName) für CloudWatch RUM-Anwendungen.
Um diesen Endpunkt zu verwenden, müssen Sie einen RUM-App-Monitor mit der mobilen Plattform (Android/iOS) erstellen und den generierten Codeausschnitt zur Instrumentierung Ihrer Anwendungen verwenden. Das Snippet ruft die RUM Mobile-SDKs ab, die mit diesem Endpunkt konfiguriert sind. Sie können die SDKs weiter konfigurieren, damit RUM die Telemetrie entsprechend erfasst.
Der Endpunkt unterstützt sowohl authentifizierte als auch nicht authentifizierte Anfragen. Sie können AWS Signature Version 4 (Sigv4) für authentifizierte Anfragen oder ressourcenbasierte Richtlinien verwenden, um den nicht authentifizierten Zugriff von mobilen Anwendungen aus zu ermöglichen.
Weitere Informationen zu den in ihren SDKs definierten Authentifizierungsmodellen finden Sie im Folgenden:
-
iOS-Anwendungen — AWS Distro für OpenTelemetry (ADOT) iOS SDK.
-
Android-Anwendungen - AWS Distro für OpenTelemetry (ADOT) Android SDK.
Limits und Einschränkungen von Endpunkten
In der Tabelle sind die allgemeinen Endpunktgrenzwerte und -einschränkungen für Metriken, Traces und Logs aufgeführt.
| Limit | Endpoint | Zusätzliche Informationen |
|---|---|---|
|
Erforderliche Collector-Erweiterung |
Um Metriken, Protokolle oder Traces an die OTLP-Endpunkte zu senden, müssen Sie sigv4authextension verwenden. Für die Metriken- und Logs-Endpunkte können Sie sich alternativ mit einem Bearer-Token authentifizieren, indem Sie die Erweiterung bearertokenauth verwenden. https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/bearertokenauthextension |
|
|
Unterstützte Protokolle |
HTTP |
Der Endpunkt unterstützt nur HTTP und kein gRPC. |
|
Unterstützte OTLP-Versionen |
OTLP 1.x |
|
|
Nutzdatenformat |
Binär, JSON |
Der Endpunkt akzeptiert Anforderungen nur im Binär- und JSON-Format. |
|
Kompressionsmethoden |
gzip, keine |
Der Endpunkt unterstützt nur gzip. |
In der Tabelle werden die Endpunkt-Limits und -einschränkungen für Traces aufgeführt.
| Limit | Traces-Endpunkt | Zusätzliche Informationen |
|---|---|---|
|
Maximale Anzahl unkomprimierter Bytes/Anforderung |
5 MB |
Der OTLP-Endpunkt lehnt Anforderungen ab, die größer als 5 MB sind, wenn die Nutzdaten unkomprimiert sind. |
|
Maximale Ereignisse/Anforderung |
10 000 Spans |
Die maximale Anzahl von Spans in einem Stapel beträgt 10 000. Eine Überschreitung dieses Limits führt zur Ablehnung des API-Aufrufs. |
|
Größe einer einzelnen Ressource und eines Bereichs |
16 KB |
Jede Ressource und der zugehörige Bereich sollten eine Größe von 16 KB nicht überschreiten. Eine Überschreitung dieses Limits für eine beliebige Ressource führt zur Ablehnung des gesamten API-Aufrufs. |
|
Maximale Größe eines einzelnen Spans |
200 KB |
Spans mit mehr als 200 KB werden vom Endpunkt abgelehnt. |
|
Vom Span erstellte Zeitstempel |
2 Stunden in der Zukunft und 14 Tage in der Vergangenheit |
Keiner der Spans eines Stapels darf mehr als zwei Stunden in der Zukunft oder mehr als 14 Tage in der Vergangenheit liegen. |
|
Maximale Zeitspanne zwischen Ereignissen und Anforderung |
24 Stunden |
In der Tabelle sind die Endpunktgrenzwerte und Einschränkungen für Metriken aufgeführt.
| Limit | Endpunkt der Messwerte | Zusätzliche Informationen | Fehlercode |
|---|---|---|---|
Maximaler TPS |
500 |
Die maximal zulässige Anzahl von Anfragen pro Sekunde pro Konto. |
429 |
Maximale Rate bei der Erstellung neuer Serien |
1 000 000 |
Maximale Anzahl neuer Serien, die in einem 10-minütigen Fenster erstellt werden können. Dieses Limit gilt nur für die Erstellung neuer Metriknamen, nicht für das Erfassen von Datenpunkten für bestehende Metriken. |
429 — Alle Metriken in den Anforderungen werden gedrosselt; 200 — Metriken in den Anforderungen werden teilweise gedrosselt |
Maximale Anforderungsgröße |
1 MB |
Die maximale unkomprimierte Größe der Anfrage. |
400 |
Maximale Anzahl von Datenpunkten |
1.000 |
Die maximale Anzahl von Datenpunkten, die in einer einzelnen Anfrage gesendet werden. Diese Zahl ist eine Summe aus ResourceMetrics ScopeMetrics Metriken. |
400 |
Maximale Metadatengröße |
40 KB |
Die maximale kombinierte Größe aller Beschriftungen und Labelwerte, die für eine Reihe pro Datenpunkt akzeptiert werden. |
400 — alle Metriken in den Anfragen sind ungültig; 200 — Metriken in den Anfragen sind teilweise ungültig |
Maximale Anzahl von Labels |
150 |
Maximale Anzahl von Beschriftungen für alle Resource/Scope/Datapoint Attribute pro Datenpunkt. |
400 — alle Metriken in den Anfragen sind ungültig; 200 — Metriken in den Anfragen sind teilweise ungültig |
Durch Metriken wurden Zeitstempel erstellt |
10 Minuten in der Zukunft und 14 Tage in der Vergangenheit |
Metriken können mit einem Zeitstempel erstellt werden, der höchstens 10 Minuten in der Zukunft und höchstens 14 Tage in der Vergangenheit liegt. |
400 |
In der Tabelle werden die Endpunkt-Limits und -einschränkungen für Protokolle aufgeführt.
| Limit | Logs-Endpunkt | Zusätzliche Informationen |
|---|---|---|
|
Maximale Anzahl unkomprimierter Bytes/Anforderung |
1 MB |
Der OTLP-Endpunkt lehnt Anforderungen ab, die größer als 1 MB sind, wenn die Nutzdaten unkomprimiert sind. Die maximale Anforderungsgröße beträgt 1 048 576 Bytes nach der Dekomprimierung und Deserialisierung von Binärdaten, die durch Protokollpuffer serialisiert wurden. Diese Größe wird als Summe aller eingegangenen Ereignismeldungen plus 26 Byte für jeden Protokolldatensatz berechnet. UTF-8 |
|
20 MB Nur in den Regionen USA Ost (Nord-Virginia), USA West (Oregon), Europa (Frankfurt), Asien-Pazifik (Sydney), Asien-Pazifik (Mumbai), USA Ost (Ohio), Europa (Irland), Asien-Pazifik (Tokio) und Asien-Pazifik (Singapur) verfügbar. |
Die maximale Anforderungsgröße beträgt 20 MB (20 971 520 Bytes), nachdem die OTLP-Nutzdaten dekomprimiert und aus dem JSON-Format dekodiert wurden. Für Logs bis zu 1 MB — Diese Logs haben vollen Zugriff auf alle CloudWatch Logs-Funktionen, einschließlich Abfragen und Live-Tail. Bei Protokollen, die größer als 1 MB sind, wird der überschüssige Teil als Large Log Objects (LLOs) verarbeitet. |
|
Anforderungen pro Sekunde |
5000 |
5 000 Transaktionen pro Sekunde pro Konto und Region Sie können mithilfe des Service-Quotas-Service eine Erhöhung des Drosselungskontingents pro Sekunde beantragen. |
|
Größe einer einzelnen Ressource und eines Bereichs |
16 KB |
Jede Ressource und der zugehörige Bereich sollten eine Größe von 16 KB nicht überschreiten. Eine Überschreitung dieses Limits für eine beliebige Ressource führt zur Ablehnung des gesamten API-Aufrufs. |
|
Einheitsgröße LogEvent |
1 MB |
LogEvent Die Größe wird als Summe der Größen für jeden LogRecord Umfang und jede Ressource berechnet. Dieses Kontingent kann nicht geändert werden. |
Von Protokollen erstellte Zeitstempel |
2 Stunden in der Zukunft und 14 Tage in der Vergangenheit |
Die Protokolleinträge im Stapel müssen nicht in chronologischer Reihenfolge angeordnet sein. Sie dürfen aber nicht mehr als 2 Stunden in der Zukunft und nicht mehr als 14 Tage in der Vergangenheit liegen. Außerdem darf keiner der Protokolleinträge vor dem Aufbewahrungszeitraum der Protokollgruppe liegen. |
|
Maximale Zeitspanne zwischen Ereignissen und Anforderung |
24 Stunden |
|
|
Maximale Ereignisse/Anforderung |
10 000 Protokolle |
Die maximale Anzahl von Protokollereignissen in einem Stapel beträgt 10 000. Eine Überschreitung dieses Limits führt zur Ablehnung des API-Aufrufs. |
|
Maximale Anzahl von Large Log Objects / Anforderung |
1 Protokolleintrag Verfügbar in USA Ost (Nord-Virginia), USA West (Oregon), Europa (Frankfurt), Asien-Pazifik (Sydney), Asien-Pazifik (Mumbai), USA Ost (Ohio), Europa (Irland), Asien-Pazifik (Tokio) und Asien-Pazifik (Singapur). |
Bei Inhalten in einem Protokollereignis, die größer als 1 MB sind, wird der überschüssige Inhalt als LLOs gespeichert. Beschränkt auf einen Protokolleintrag pro Anforderung. |
|
Maximale Anzahl von Large Log Objects / Eintrag |
10 LLOs Verfügbar in USA Ost (Nord-Virginia), USA West (Oregon), Europa (Frankfurt), Asien-Pazifik (Sydney), Asien-Pazifik (Mumbai), USA Ost (Ohio), Europa (Irland), Asien-Pazifik (Tokio) und Asien-Pazifik (Singapur). |
Ein einzelner Protokolleintrag kann bis zu 10 LLOs enthalten. |
Anmerkung
Die Kontolimits für Protokolle gelten für das gesamte SDK und den neuen Logs-Endpunkt.
