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 Allzweckprotokoll zur Übertragung von Telemetriedaten, 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 beginnt, offene Telemetriedaten an zu senden. CloudWatch Weitere Informationen finden Sie unter Erste Schritte.
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 beginnt. CloudWatch Der Endpunkt authentifiziert Aufrufer mithilfe der Signature-4-Authentifizierung. Weitere Informationen finden Sie unter AWS Signature Version 4 for API-Anforderungen.
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 Erfassung 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 Sie x-aws-log-group jeweils x-aws-log-stream HTTP-Header LogGroup und LogStream Namen festlegen. Weitere Informationen finden Sie unter Erste Schritte. Der Endpunkt authentifiziert Aufrufer mithilfe der Signature-4-Authentifizierung. Weitere Informationen finden Sie unter AWS Signature Version 4 for API-Anforderungen.
Wenn die Größe des Protokollereignisses 1 MB überschreitet, kürzt CloudWatch Logs automatisch bis zu 10 Felder, beginnend mit den größten Feldern. 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 LLO-Referenzsystemfelder 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. LLOs Sie können mithilfe der GetLogObject API abgerufen und zurückgestreamt werden. Weitere Informationen finden Sie unter GetLogObject. Support von Protokollereignissen mit mehr als 1 MB und LLO-Erfahrung ist in den Ländern 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.
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ätzeeventName) für CloudWatch RUM-Anwendungen.
Um diesen Endpunkt zu verwenden, müssen Sie einen RUM-App-Monitor mit mobiler Plattform (Android/ iOS) erstellen und den generierten Codeausschnitt verwenden, um Ihre Anwendungen zu instrumentieren. Das Snippet ruft die RUM-Mobilgeräte ab, die mit diesem Endpunkt SDKs konfiguriert sind. Sie können das SDKs weitere Verfahren so konfigurieren, dass RUM Telemetriedaten 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 nicht authentifizierten Zugriff von mobilen Anwendungen aus zu ermöglichen.
Weitere Informationen zu den in ihnen definierten Authentifizierungsmodellen finden Sie im Folgenden: SDKs
-
iOS-Anwendungen — AWS Distribution 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 werden die allgemeinen Endpunkt-Limits und -einschränkungen für Traces und Protokolle aufgeführt.
| Limit | Endpoint | Zusätzliche Informationen |
|---|---|---|
|
Erforderliche Collector-Erweiterung |
Um Traces an den OTLP-Endpunkt zu senden, müssen Sie sigv4authextension verwenden. |
|
|
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 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 ist die Summe aller Ereignismeldungen in UTF-8 plus 26 Bytes pro Protokolleintrag. |
|
20 MB Nur 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). |
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 große Protokollobjekte () 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. |
|
Einzelgröße LogEvent |
1 MB |
LogEvent Die Größe wird als Summe der Größen für jeden LogRecord Bereich 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, die 1 MB in einem Protokollereignis überschreiten, 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 Protokolldatensatz kann bis zu 10 enthalten LLOs. |
Anmerkung
Die Kontolimits für Protokolle gelten für das gesamte SDK und den neuen Logs-Endpunkt.
