Verwendung CloudWatch zur Überwachung und Protokollierung von GraphQL-Daten API - AWS AppSync
Einrichtung und KonfigurationCloudWatch MetrikenCloudWatch LogsReferenz zum ProtokolltypAnalysieren Sie Ihre Logs mit CloudWatch Logs InsightsAnalysieren Sie Ihre Logs mit Service OpenSearch Migration des Protokollformats

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.

Verwendung CloudWatch zur Überwachung und Protokollierung von GraphQL-Daten API

Sie können Ihr GraphQL API mithilfe von CloudWatch Metriken und Protokollen protokollieren und CloudWatch debuggen. Diese Tools ermöglichen es Entwicklern, die Leistung zu überwachen, Probleme zu beheben und ihre GraphQL-Operationen effektiv zu optimieren.

CloudWatch metrics ist ein Tool, das eine breite Palette von Metriken zur Überwachung von API Leistung und Nutzung bietet. Diese Metriken lassen sich in zwei Hauptkategorien einteilen:

  1. Allgemeine API Messwerte: Dazu gehören 4XXError und 5XXError für die Nachverfolgung von Client- und Serverfehlern, Latency für die Messung von Antwortzeiten, Requests für die Überwachung der Gesamtzahl der API Anrufe und TokensConsumed für die Verfolgung der Ressourcennutzung.

  2. Abonnement-Metriken in Echtzeit: Diese Metriken konzentrieren sich auf WebSocket Verbindungen und Abonnementaktivitäten. Sie umfassen Messwerte für Verbindungsanfragen, erfolgreiche Verbindungen, Abonnementregistrierungen, die Veröffentlichung von Nachrichten sowie aktive Verbindungen und Abonnements.

In dem Leitfaden werden auch Enhanced Metrics vorgestellt, die detailliertere Daten zur Resolverleistung, zu Datenquelleninteraktionen und zu einzelnen GraphQL-Vorgängen bieten. Diese Metriken bieten tiefere Einblicke, sind jedoch mit zusätzlichen Kosten verbunden.

CloudWatch Logs ist ein Tool, das Logging-Funktionen für Ihr GraphQL APIs ermöglicht. Protokolle können auf zwei Ebenen eingerichtet werden: API

  1. Protokolle auf Anforderungsebene: Diese erfassen allgemeine Anforderungsinformationen, einschließlich HTTP Header, GraphQL-Abfragen, Betriebsübersichten und Abonnementregistrierungen.

  2. Protokolle auf Feldebene: Diese enthalten detaillierte Informationen zu einzelnen Feldauflösungen, einschließlich der Zuordnungen von Anfragen und Antworten sowie Ablaufverfolgungsinformationen für jedes Feld.

Sie können die Protokollierung konfigurieren, Protokolleinträge interpretieren und Protokolldaten zur Fehlerbehebung und Optimierung verwenden. AWS AppSync bietet verschiedene Protokolltypen, die Aufschluss über die Ausführungs-, Analyse-, Validierungs- und Feldauflösungsdaten Ihrer Abfrage geben.

Einrichtung und Konfiguration

Verwenden Sie die AWS AppSync Konsole, um die automatische Protokollierung auf einem GraphQL API zu aktivieren.

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die AppSyncKonsole.

  2. Wählen Sie auf der APIsSeite den Namen eines GraphQL ausAPI.

  3. Wählen Sie auf Ihrer API Startseite im Navigationsbereich Einstellungen aus.

  4. Führen Sie unter Logging (Protokollierung) folgende Schritte aus:

    1. Aktivieren Sie die Option „Protokolle aktivieren“.

    2. Für eine detaillierte Protokollierung auf Anforderungsebene aktivieren Sie das Kontrollkästchen unter Ausführlichen Inhalt einbeziehen. (optional)

    3. Wählen Sie unter Field Resolver-Protokollebene Ihre bevorzugte Protokollierungsebene auf Feldebene aus (Keine, Fehler oder Alle). (optional)

    4. Wählen Sie unter Eine bestehende Rolle erstellen oder verwenden die Option Neue Rolle aus, um eine neue Rolle AWS Identity and Access Management (IAM) AWS AppSync zu erstellen, in die Logs geschrieben werden können CloudWatch. Oder wählen Sie Bestehende Rolle, um den Amazon-Ressourcennamen (ARN) einer vorhandenen IAM Rolle in Ihrem AWS Konto auszuwählen.

  5. Wählen Sie Speichern.

Manuelle IAM Rollenkonfiguration

Wenn Sie sich dafür entscheiden, eine bestehende IAM Rolle zu verwenden, muss die Rolle AWS AppSync die erforderlichen Berechtigungen zum Schreiben von Protokollen gewähren CloudWatch. Um dies manuell zu konfigurieren, müssen Sie eine Servicerolle angeben, ARN damit diese Rolle beim Schreiben der Protokolle übernommen werden AWS AppSync kann.

Erstellen Sie in der IAMKonsole eine neue Richtlinie mit dem NamenAWSAppSyncPushToCloudWatchLogsPolicy, der die folgende Definition hat:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Erstellen Sie als Nächstes eine neue Rolle mit dem Namen AWSAppSyncPushToCloudWatchLogsRoleund fügen Sie der Rolle die neu erstellte Richtlinie hinzu. Bearbeiten Sie die Vertrauensstellung für diese Rolle wie folgt:

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
            "Service": "appsync.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
        }
    ]
}

Kopieren Sie die Rolle ARN und verwenden Sie sie, wenn Sie die Protokollierung für ein AWS AppSync GraphQL API einrichten.

CloudWatch Metriken

Sie können CloudWatch Metriken verwenden, um bestimmte Ereignisse zu überwachen und Warnmeldungen zu geben, die zu HTTP Statuscodes oder Latenz führen können. Die folgenden Messwerte werden ausgegeben:

4XXError

Fehler aufgrund von Anfragen, die aufgrund einer falschen Client-Konfiguration nicht gültig sind. In der Regel treten diese Fehler überall außerhalb der GraphQL-Verarbeitung auf. Diese Fehler können beispielsweise auftreten, wenn die Anfrage eine falsche JSON Nutzlast oder eine falsche Abfrage enthält, wenn der Dienst gedrosselt ist oder wenn die Autorisierungseinstellungen falsch konfiguriert sind.

Einheit: Anzahl. Verwenden Sie die Summen-Statistik, um die Gesamtanzahl der aufgetretenen Fehler zu erhalten.

5XXError

Beim Ausführen einer GraphQL-Abfrage sind Fehler aufgetreten. Dies kann beispielsweise auftreten, wenn eine Abfrage für ein leeres oder falsches Schema aufgerufen wird. Es kann auch vorkommen, wenn die Amazon Cognito Cognito-Benutzerpool-ID oder AWS Region nicht gültig ist. Alternativ kann dies auch passieren, wenn AWS AppSync bei der Bearbeitung einer Anfrage ein Problem auftritt.

Einheit: Anzahl. Verwenden Sie die Summen-Statistik, um die Gesamtanzahl der aufgetretenen Fehler zu erhalten.

Latency

Die Zeit zwischen dem AWS AppSync Empfang einer Anfrage von einem Kunden und der Rückgabe einer Antwort an den Client. Dies beinhaltet nicht die Netzwerklatenz, die auftritt, bis eine Antwort die Endgeräte erreicht hat.

Einheit: Millisekunden Verwenden Sie die Durchschnittsstatistik, um erwartete Latenzen zu bewerten.

Requests

Die Anzahl der Anfragen (Abfragen + Mutationen), die alle APIs in Ihrem Konto bearbeitet haben, aufgeschlüsselt nach Region.

Einheit: Anzahl. Die Anzahl aller Anfragen, die in einer bestimmten Region bearbeitet wurden.

TokensConsumed

Tokens werden auf der Requests Grundlage der Menge an Ressourcen (Verarbeitungszeit und verwendeter Speicherplatz) zugewiesen, die a Request verbraucht. Normalerweise Request verbraucht jedes Exemplar ein Token. Einem Request Benutzer, der große Mengen an Ressourcen verbraucht, werden jedoch nach Bedarf zusätzliche Token zugewiesen.

Einheit: Anzahl. Die Anzahl der Token, die Anfragen zugewiesen wurden, die in einer bestimmten Region verarbeitet wurden.

NetworkBandwidthOutAllowanceExceeded
Anmerkung

In der AWS AppSync Konsole können Sie auf der Seite mit den Cache-Einstellungen mit der Option Cache Health Metrics diese Cache-bezogene Integritätsmetrik aktivieren.

Die Netzwerkpakete wurden verworfen, weil der Durchsatz das aggregierte Bandbreitenlimit überschritten hat. Dies ist nützlich für die Diagnose von Engpässen in einer Cache-Konfiguration. Daten werden für einen bestimmten Wert aufgezeichnet, API indem der API_Id in der Metrik angegeben wird. appsyncCacheNetworkBandwidthOutAllowanceExceeded

Einheit: Anzahl. Die Anzahl der Pakete, die nach Überschreitung des Bandbreitenlimits für eine API angegebene ID verworfen wurden.

EngineCPUUtilization
Anmerkung

In der AWS AppSync Konsole können Sie auf der Seite mit den Cache-Einstellungen mit der Option Cache Health Metrics diese Cache-bezogene Integritätsmetrik aktivieren.

Die CPU Auslastung (in Prozent), die dem OSS Redis-Prozess zugewiesen ist. Dies ist nützlich für die Diagnose von Engpässen in einer Cache-Konfiguration. Daten werden für einen bestimmten Wert aufgezeichnet, API indem der API_Id in der Metrik angegeben wird. appsyncCacheEngineCPUUtilization

Einheit: Prozent. Der CPU Prozentsatz, der derzeit vom OSS Redis-Prozess für eine API angegebene ID verwendet wird.

Abonnements in Echtzeit

Alle Metriken werden in einer Dimension ausgegeben: raphQLAPIIdG. Das bedeutet, dass alle Metriken mit GraphQL API IDs gekoppelt sind. Die folgenden Metriken beziehen sich auf GraphQL-Abonnements im Vergleich zu Pure WebSockets:

ConnectRequests

Die Anzahl der WebSocket Verbindungsanfragen an AWS AppSync, einschließlich erfolgreicher und erfolgloser Versuche.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der Verbindungsanfragen zu ermitteln.

ConnectSuccess

Die Anzahl der erfolgreichen WebSocket Verbindungen zu AWS AppSync. Verbindungen ohne Abonnement sind möglich.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der erfolgreichen Verbindungen zu erhalten.

ConnectClientError

Die Anzahl der WebSocket Verbindungen, die AWS AppSync aufgrund von clientseitigen Fehlern abgelehnt wurden. Dies könnte bedeuten, dass der Dienst gedrosselt ist oder dass die Autorisierungseinstellungen falsch konfiguriert sind.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der clientseitigen Verbindungsfehler zu erhalten.

ConnectServerError

Die Anzahl der Fehler, die auf die Verarbeitung von Verbindungen zurückzuführen sind AWS AppSync . Diese Fehler treten normalerweise bei einem unerwarteten serverseitigen Problem auf.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der serverseitigen Verbindungsfehler zu erhalten.

DisconnectSuccess

Die Anzahl der erfolgreichen WebSocket Verbindungsabbrüche von AWS AppSync.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der erfolgreichen Verbindungstrennungen zu erhalten.

DisconnectClientError

Die Anzahl der Client-Fehler, die auf das Trennen von AWS AppSync Verbindungen zurückzuführen sind WebSocket.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der Fehler bei Verbindungstrennungen zu erhalten.

DisconnectServerError

Die Anzahl der Serverfehler, die auf das Trennen von AWS AppSync Verbindungen zurückzuführen sind WebSocket.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der Fehler bei Verbindungstrennungen zu erhalten.

SubscribeSuccess

Die Anzahl der Abonnements, für die erfolgreich registriert wurden AWS AppSync . WebSocket Es ist möglich, Verbindungen ohne Abonnements zu haben, aber es ist nicht möglich, Abonnements ohne Verbindungen zu haben.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der erfolgreichen Abonnements zu erhalten.

SubscribeClientError

Die Anzahl der Abonnements, die von AWS AppSync aufgrund von clientseitigen Fehlern abgelehnt wurden. Dies kann der Fall sein, wenn eine JSON Payload falsch ist, der Dienst gedrosselt ist oder die Autorisierungseinstellungen falsch konfiguriert sind.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der clientseitigen Abonnementfehler zu erhalten.

SubscribeServerError

Die Anzahl der Fehler, die auf die Verarbeitung von AWS AppSync Abonnements zurückzuführen sind. Diese Fehler treten normalerweise bei einem unerwarteten serverseitigen Problem auf.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der serverseitigen Abonnementfehler zu erhalten.

UnsubscribeSuccess

Die Anzahl der Abmeldeanfragen, die erfolgreich verarbeitet wurden.

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der erfolgreichen Abmeldeanfragen zu ermitteln.

UnsubscribeClientError

Die Anzahl der Abmeldeanfragen, die von AWS AppSync aufgrund von clientseitigen Fehlern abgelehnt wurden.

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der Fehler bei der clientseitigen Abmeldeanfrage zu ermitteln.

UnsubscribeServerError

Die Anzahl der Fehler, die auf die Verarbeitung von Abmeldeanfragen zurückzuführen sind AWS AppSync . Diese Fehler treten normalerweise bei einem unerwarteten serverseitigen Problem auf.

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der Fehler bei serverseitigen Abmeldeanfragen zu ermitteln.

PublishDataMessageSuccess

Die Anzahl der Abonnementereignismeldungen, die erfolgreich veröffentlicht wurden.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der erfolgreich veröffentlichten Abonnementereignismeldungen zu erhalten.

PublishDataMessageClientError

Die Anzahl der Abonnementereignismeldungen, die aufgrund von clientseitigen Fehlern nicht veröffentlicht werden konnten.

Unit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der clientseitigen Fehler bei der Veröffentlichung von Abonnementereignissen zu erhalten.

PublishDataMessageServerError

Die Anzahl der Fehler, die AWS AppSync beim Veröffentlichen von Abonnement-Ereignismeldungen entstanden sind. Diese Fehler treten normalerweise bei einem unerwarteten serverseitigen Problem auf.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der serverseitigen Fehler bei der Veröffentlichung von Abonnementereignissen zu erhalten.

PublishDataMessageSize

Die Größe der veröffentlichten Abonnementereignismeldungen.

Einheit: Byte.

ActiveConnections

Die Anzahl der gleichzeitigen WebSocket Verbindungen von Clients zu AWS AppSync in 1 Minute.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der geöffneten Verbindungen zu erhalten.

ActiveSubscriptions

Die Anzahl der gleichzeitigen Abonnements von Clients in 1 Minute.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtanzahl der aktiven Abonnements zu erhalten.

ConnectionDuration

Die Zeitspanne, in der die Verbindung offen bleibt.

Einheit: Millisekunden. Verwenden Sie die Durchschnittsstatistik, um die Verbindungsdauer auszuwerten.

OutboundMessages

Die Anzahl der erfolgreich veröffentlichten Messnachrichten. Eine gemessene Nachricht entspricht 5 kB gelieferter Daten.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der erfolgreich veröffentlichten Messnachrichten zu ermitteln.

InboundMessageSuccess

Die Anzahl der erfolgreich verarbeiteten eingehenden Nachrichten. Jeder Abonnementtyp, der durch eine Mutation aufgerufen wird, generiert eine eingehende Nachricht.

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der erfolgreich verarbeiteten eingehenden Nachrichten abzurufen.

InboundMessageError

Die Anzahl der eingehenden Nachrichten, die aufgrund ungültiger API Anfragen nicht verarbeitet werden konnten, z. B. weil die maximale Größe der Abonnementnutzlast von 240 kB überschritten wurde.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der eingehenden Nachrichten mit API entsprechenden Verarbeitungsfehlern abzurufen.

InboundMessageFailure

Die Anzahl der eingehenden Nachrichten, deren Verarbeitung aufgrund von Fehlern von fehlgeschlagen ist. AWS AppSync

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der eingehenden Nachrichten mit entsprechenden Verarbeitungsfehlern abzurufen AWS AppSync.

InboundMessageDelayed

Die Anzahl verzögerter eingehender Nachrichten. Eingehende Nachrichten können verzögert werden, wenn entweder die Quote für eingehende Nachrichten oder die Quote für ausgehende Nachrichten überschritten wird.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der verspäteten eingehenden Nachrichten zu ermitteln.

InboundMessageDropped

Die Anzahl der verworfenen eingehenden Nachrichten. Eingehende Nachrichten können gelöscht werden, wenn entweder die Quote für eingehende Nachrichten oder die Quote für ausgehende Nachrichten überschritten wird.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der verworfenen eingehenden Nachrichten zu ermitteln.

InvalidationSuccess

Die Anzahl der Abonnements, die durch eine Mutation mit erfolgreich für ungültig erklärt (abgemeldet) wurden. $extensions.invalidateSubscriptions()

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der Abonnements abzurufen, die erfolgreich abgemeldet wurden.

InvalidationRequestSuccess

Die Anzahl der erfolgreich verarbeiteten Invalidierungsanfragen.

Einheit: Anzahl. Verwenden Sie die Sum-Statistik, um die Gesamtzahl der erfolgreich verarbeiteten Invalidierungsanforderungen zu ermitteln.

InvalidationRequestError

Die Anzahl der Invalidierungsanforderungen, die aufgrund ungültiger Anfragen nicht verarbeitet werden konnten. API

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der Invalidierungsanforderungen mit entsprechenden Verarbeitungsfehlern zu ermittelnAPI.

InvalidationRequestFailure

Die Anzahl der Invalidierungsanforderungen, die aufgrund von Fehlern von nicht verarbeitet werden konnten. AWS AppSync

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der Invalidierungsanforderungen mit entsprechenden Verarbeitungsfehlern abzurufen AWS AppSync.

InvalidationRequestDropped

Die Anzahl der verworfenen Ungültigungsanforderungen, als das Kontingent für Invalidierungsanfragen überschritten wurde.

Einheit: Anzahl. Verwenden Sie die Summenstatistik, um die Gesamtzahl der verworfenen Invalidierungsanfragen zu ermitteln.

Vergleich eingehender und ausgehender Nachrichten

Wenn eine Mutation ausgeführt wird, werden Abonnementfelder mit der @aws_subscribe -Direktive für diese Mutation aufgerufen. Jeder Abonnementaufruf generiert eine eingehende Nachricht. Wenn beispielsweise zwei Abonnementfelder dieselbe Mutation in @aws_subscribe angeben, werden zwei eingehende Nachrichten generiert, wenn diese Mutation aufgerufen wird.

Eine ausgehende Nachricht entspricht 5 kB an Daten, die an WebSocket Clients geliefert werden. Das Senden von 15 kB Daten an 10 Clients führt beispielsweise zu 30 ausgehenden Nachrichten (15 kB * 10 Clients/5 kB pro Nachricht = 30 Nachrichten).

Sie können eine Erhöhung des Kontingents für eingehende oder ausgehende Nachrichten beantragen. Weitere Informationen finden Sie unter AWS AppSync Endpunkte und Kontingente im AWS Allgemeinen Referenzhandbuch und in den Anweisungen zur Beantragung einer Kontingenterhöhung im Servicekontingents-Benutzerhandbuch.

Verbesserte Metriken

Verbesserte Metriken geben detaillierte Daten zur API Nutzung und Leistung aus, z. B. Anzahl von AWS AppSync Anfragen und Fehlern, Latenz und Cache-Treffern/Fehlschläge. Alle erweiterten Metrikdaten werden an Ihr CloudWatch Konto gesendet, und Sie können die zu sendenden Datentypen konfigurieren.

Anmerkung

Bei der Verwendung erweiterter Messwerte fallen zusätzliche Gebühren an. Weitere Informationen finden Sie in den detaillierten Preisstufen für die Überwachung in den CloudWatchAmazon-Preisen.

Diese Messwerte finden Sie auf verschiedenen Einstellungsseiten in der AWS AppSync Konsole. Auf der API Einstellungsseite können Sie im Bereich „Erweiterte Metriken“ die folgenden Elemente aktivieren oder deaktivieren:

Verhalten der Resolver-Metriken: Diese Optionen steuern, wie zusätzliche Metriken für Resolver erfasst werden. Sie können wählen, ob Sie vollständige Request Resolver-Metriken (Metriken, die für alle Resolver in Anfragen aktiviert sind) oder Metriken pro Resolver (Metriken, die nur für Resolver aktiviert sind, bei denen die Konfiguration aktiviert ist) aktivieren möchten. Verfügbar sind die nachfolgend aufgeführten Optionen:

GraphQL errors per resolver (GraphQLError)

Die Anzahl der pro Resolver aufgetretenen GraphQL-Fehler.

Metrische Dimension:, API_Id Resolver

Einheit: Anzahl.

Requests per resolver (Request)

Die Anzahl der Aufrufe, die während einer Anfrage erfolgten. Dies wird pro Resolver aufgezeichnet.

Metrische Abmessung:, API_Id Resolver

Einheit: Anzahl.

Latency per resolver (Latency)

Die Zeit, bis ein Resolver-Aufruf abgeschlossen ist. Die Latenz wird in Millisekunden gemessen und pro Resolver aufgezeichnet.

API_IdMetrische Dimension:, Resolver

Einheit: Millisekunden

Cache hits per resolver (CacheHit)

Die Anzahl der Cache-Treffer während einer Anfrage. Dies wird nur ausgegeben, wenn ein Cache verwendet wird. Cache-Treffer werden pro Resolver aufgezeichnet.

Metrische Dimension:, API_Id Resolver

Einheit: Anzahl.

Cache misses per resolver (CacheMiss)

Die Anzahl der Cache-Fehlschläge während einer Anfrage. Dies wird nur ausgegeben, wenn ein Cache verwendet wird. Cache-Fehlschläge werden pro Resolver aufgezeichnet.

Metrische Dimension:, API_Id Resolver

Einheit: Anzahl.

Verhalten von Datenquellenmetriken: Diese Optionen steuern, wie zusätzliche Metriken für Datenquellen erfasst werden. Sie können wählen, ob Sie Metriken für vollständige Anfragen (Metriken, die für alle Datenquellen in Anfragen aktiviert sind) oder Metriken pro Datenquelle (Metriken, die nur für Datenquellen aktiviert sind, für die die Konfiguration aktiviert ist) aktivieren möchten. Verfügbar sind die nachfolgend aufgeführten Optionen:

Requests per data source (Request)

Die Anzahl der Aufrufe, die während einer Anfrage erfolgt sind. Anfragen werden pro Datenquelle aufgezeichnet. Wenn vollständige Anfragen aktiviert sind, hat jede Datenquelle ihren eigenen Eintrag in CloudWatch.

Metrische Dimension:API_Id, Datasource

Einheit: Anzahl.

Latency per data source (Latency)

Die Zeit, bis ein Datenquellenaufruf abgeschlossen ist. Die Latenz wird pro Datenquelle aufgezeichnet.

Metrische Dimension:API_Id, Datasource

Einheit: Millisekunden

Errors per data source (GraphQLError)

Die Anzahl der Fehler, die während eines Datenquellenaufrufs aufgetreten sind.

Metrische Dimension:API_Id, Datasource

Einheit: Anzahl.

Betriebsmetriken: Aktiviert GraphQL-Metriken auf Betriebsebene.

Requests per operation (Request)

Die Häufigkeit, mit der eine angegebene GraphQL-Operation aufgerufen wurde.

Metrische Abmessung:API_Id, Operation

Einheit: Anzahl.

GraphQL errors per operation (GraphQLError)

Die Anzahl der GraphQL-Fehler, die während eines angegebenen GraphQL-Vorgangs aufgetreten sind.

Metrische Abmessung:, API_Id Operation

Einheit: Anzahl.

CloudWatch Logs

Sie können zwei Arten der Protokollierung für jedes neue oder bestehende GraphQL konfigurierenAPI: auf Anforderungsebene und auf Feldebene.

Protokolle auf Anforderungsebene

Wenn die Protokollierung auf Anforderungsebene (Ausführlichen Inhalt einbeziehen) konfiguriert ist, werden die folgenden Informationen protokolliert:

  • Die Anzahl der verbrauchten Token

  • Die Anforderungs- und HTTP Antwort-Header

  • Die GraphQL-Abfrage, die in der Anfrage ausgeführt wird

  • Die allgemeine Zusammenfassung des Vorgangs

  • Neue und bestehende GraphQL-Abonnements, die registriert sind

Protokolle auf Feldebene

Wenn die Protokollierung auf Feldebene konfiguriert ist, werden die folgenden Informationen protokolliert:

  • Generierte Anforderungszuordnung mit Quelle und Argumenten für jedes Feld

  • Die transformierte Antwortzuordnung für jedes Feld, die die Daten enthält, die sich aus der Auflösung dieses Felds ergeben

  • Verfolgen von Informationen für jedes Feld

AWS AppSync Verwaltet die Protokolle, wenn Sie die CloudWatch Protokollierung aktivieren. Der Prozess umfasst das Erstellen von Protokollgruppen und -Streams sowie die Meldung an Protokoll-Streams mit diesen Protokollen.

Wenn Sie die Protokollierung auf einem GraphQL aktivieren API und Anfragen stellen, AWS AppSync erstellt es eine Protokollgruppe und Protokollstreams unter der Protokollgruppe. Die Protokollgruppe wird nach dem /aws/appsync/apis/{graphql_api_id}-Format benannt. In jeder Protokollgruppe werden die Protokolle weiter in Protokoll-Streams unterteilt. Diese werden anhand der Last Event Time (Letzte Ereigniszeit) sortiert, das heißt anhand des Zeitpunkts, zu dem die protokollierten Daten gemeldet werden.

Jedes Protokollereignis ist mit dem X-amzn- RequestId der Anfrage gekennzeichnet. Auf diese Weise können Sie Protokollereignisse filtern CloudWatch , um alle protokollierten Informationen zu dieser Anfrage abzurufen. Sie können das RequestId aus den Antwortheadern jeder AWS AppSync GraphQL-Anfrage abrufen.

Die Feld-Level-Protokollierung wird mit den folgenden Protokollebenen konfiguriert:

  • Keine — Es werden keine Protokolle auf Feldebene erfasst.

  • Fehler — Protokolliert die folgenden Informationen nur für die Felder, die fehlerhaft sind:

    • Der Fehlerabschnitt in der Serverantwort

    • Feld-Level-Fehler

    • Die generierten Anforderungs-/Antwortfunktionen, die für fehlerhafte Felder behoben wurden

  • Alle — Protokolliert die folgenden Informationen für alle Felder in der Abfrage:

    • Feld-Level-Rückverfolgungsinformationen

    • Die generierten Anforderungs-/Antwortfunktionen, die für jedes Feld behoben wurden

Vorteile der Überwachung

Sie können die Protokollierung und Metriken verwenden, um Ihre GraphQL-Abfragen zu identifizieren, Fehler darin zu beheben und sie zu optimieren. Diese werden Ihnen beispielsweise dabei helfen, Latenzprobleme zu debuggen und zwar mithilfe der Rückverfolgungsinformationen, die für jedes Feld in der Abfrage protokolliert werden. Um dies zu demonstrieren, nehmen Sie einmal an, dass Sie einen oder mehrere Resolver in einer GraphQL-Abfrage verwenden. Ein Beispiel für einen Feldvorgang in CloudWatch Logs könnte wie folgt aussehen:

{
    "path": [
        "singlePost",
        "authors",
        0,
        "name"
    ],
    "parentType": "Post",
    "returnType": "String!",
    "fieldName": "name",
    "startOffset": 416563350,
    "duration": 11247
}

Dies kann einem GraphQL-Schema entsprechen, das wie folgt aussieht:

type Post {
  id: ID!
  name: String!
  authors: [Author]
}

type Author {
  id: ID!
  name: String!
}

type Query {
  singlePost(id:ID!): Post
}

In den vorherigen Protokollergebnissen zeigt path ein einzelnes Element in Ihren Daten, das beim Ausführen einer Abfrage zurückgegeben wurde, mit dem NamensinglePost(). In diesem Beispiel steht es für das Namensfeld am ersten Index (0). Das startOffsetgibt einen Offset vom Start des GraphQL-Abfragevorgangs an. Die Dauer ist die Gesamtzeit für die Auflösung des Felds. Diese Werte können nützlich sein, um herauszufinden, warum Daten aus einer bestimmten Datenquelle möglicherweise langsamer als erwartet ausgeführt werden oder ob ein bestimmtes Feld die gesamte Abfrage drosselt. Sie könnten sich beispielsweise dafür entscheiden, den bereitgestellten Durchsatz für eine Amazon DynamoDB-Tabelle zu erhöhen oder ein bestimmtes Feld aus einer Abfrage zu entfernen, wodurch der gesamte Vorgang schlecht ausgeführt wird.

AWS AppSync Generiert seit dem 8. Mai 2019 vollständig strukturierte Protokollereignisse. JSON Dies kann Ihnen helfen, Protokollanalysedienste wie CloudWatch Logs Insights und Amazon OpenSearch Service zu verwenden, um die Leistung Ihrer GraphQL-Anfragen und die Nutzungsmerkmale Ihrer Schemafelder zu verstehen. Auf diese Weise können Sie z. B. Resolver mit hohen Wartezeiten identifizieren, die möglicherweise die Ursache eines Leistungsproblems sind. Zudem können Sie die am häufigsten und am seltesten verwendeten Felder in Ihrem Schema identifizieren und die Auswirkungen von veralteten GraphQL-Feldern bewerten.

Konflikterkennung und Synchronisierungsprotokollierung

Wenn für AWS AppSync API ein die Protokollierung in CloudWatch Logs konfiguriert ist und die Protokollebene des Field Resolvers auf Alle gesetzt ist, werden Informationen zur Konflikterkennung und -lösung an die Protokollgruppe ausgegeben. AWS AppSync Auf diese Weise erhalten Sie detaillierte Informationen darüber, wie sie auf einen Konflikt AWS AppSync API reagiert haben. Um Ihnen bei der Interpretation der Antwort zu helfen, sind die folgenden Informationen in den Protokollen enthalten:

conflictType

Gibt an, ob ein Konflikt aufgrund einer fehlenden Versionsübereinstimmung oder der vom Kunden bereitgestellten Bedingung aufgetreten ist.

conflictHandlerConfigured

Gibt den Conflict Handler an, der zum Zeitpunkt der Anforderung auf dem Resolver konfiguriert war.

message

Enthält Informationen darüber, wie der Konflikt erkannt und gelöst wurde.

syncAttempt

Die Anzahl der Versuche, die der Server unternommen hat, um die Daten zu synchronisieren, bevor die Anforderung letztlich abgelehnt wurde.

data

Wenn der Konflikthandler konfiguriert istAutomerge, wird dieses Feld ausgefüllt, um anzuzeigen, welche Entscheidung Automerge für jedes Feld getroffen wurde. Die Aktionen können sein:

  • REJECTED- Automerge When lehnt den eingehenden Feldwert zugunsten des Werts auf dem Server ab.

  • ADDED- Wenn das eingehende Feld Automerge hinzugefügt wird, weil auf dem Server noch kein Wert vorhanden ist.

  • APPENDED- When Automerge fügt die eingehenden Werte an die Werte für die Liste an, die auf dem Server vorhanden ist.

  • MERGED- Wenn die eingehenden Werte mit den Werten für das Set Automerge zusammengeführt werden, das auf dem Server vorhanden ist.

Verwenden Sie Token-Zählungen, um Ihre Anfragen zu optimieren

Anfragen, die weniger als oder gleich 1.500 KB-Sekunden Speicher und CPU V-Zeit verbrauchen, wird ein Token zugewiesen. Anfragen mit einem Ressourcenverbrauch von mehr als 1.500 KB-Sekunden erhalten zusätzliche Token. Wenn eine Anfrage beispielsweise 3.350 KB-Sekunden verbraucht, AWS AppSync werden der Anfrage drei Tokens (aufgerundet auf die nächste Ganzzahl) zugewiesen. AWS AppSync Ordnet dem in Ihrem Konto standardmäßig maximal 5.000 oder 10.000 Anforderungstoken pro Sekunde zu, abhängig von der Region, APIs in der sie bereitgestellt wird. AWS Wenn Sie APIs jeweils durchschnittlich zwei Token pro Sekunde verwenden, sind Sie auf 2.500 bzw. 5.000 Anfragen pro Sekunde beschränkt. Wenn Sie mehr Token pro Sekunde als die zugewiesene Menge benötigen, können Sie eine Anfrage einreichen, um das Standardkontingent für die Rate der Anforderungstoken zu erhöhen. Weitere Informationen finden Sie unter AWS AppSync Endpunkte und Kontingente im Allgemeine AWS-Referenz Handbuch und Beantragung einer Kontingenterhöhung im Servicekontingents-Benutzerhandbuch.

Eine hohe Token-Anzahl pro Anfrage könnte darauf hindeuten, dass die Möglichkeit besteht, Ihre Anfragen zu optimieren und die Leistung Ihrer zu verbessern. API Zu den Faktoren, die Ihre Token-Anzahl pro Anfrage erhöhen können, gehören:

  • Die Größe und Komplexität Ihres GraphQL-Schemas.

  • Die Komplexität von Vorlagen für die Zuordnung von Anfragen und Antworten.

  • Die Anzahl der Resolver-Aufrufe pro Anfrage.

  • Die Menge der von Resolvern zurückgegebenen Daten.

  • Die Latenz von Downstream-Datenquellen.

  • Schema- und Abfrageentwürfe, die aufeinanderfolgende Datenquellenaufrufe erfordern (im Gegensatz zu parallel oder gebündelten Aufrufen).

  • Konfiguration der Protokollierung, insbesondere Protokollinhalte auf Feldebene und ausführliche Protokollinhalte.

Anmerkung

Zusätzlich zu den AWS AppSync Metriken und Protokollen können Clients über den Antwort-Header auf die Anzahl der in einer Anfrage verbrauchten Token zugreifen. x-amzn-appsync-TokensConsumed

Größenbeschränkungen für Protokolle

Wenn die Protokollierung aktiviert wurde, AWS AppSync werden standardmäßig bis zu 1 MB an Protokollen pro Anfrage gesendet. Protokolle, die diese Größe überschreiten, werden gekürzt. Um die Protokollgröße zu reduzieren, wählen Sie die ERROR Protokollierungsebene für Protokolle auf Feldebene und deaktivieren Sie die VERBOSE Protokollierung oder deaktivieren Sie die Protokolle auf Feldebene vollständig, falls sie nicht benötigt werden. Als Alternative zur ALL Protokollebene können Sie Enhanced Metrics verwenden, um Metriken zu bestimmten Resolvern, Datenquellen oder GraphQL-Vorgängen abzurufen, oder die von bereitgestellten Protokollierungsdienstprogramme verwenden, um nur die erforderlichen Informationen AppSync zu protokollieren.

Referenz zum Protokolltyp

RequestSummary

  • requestId: Eindeutiger Bezeichner für die Anfrage.

  • graphQLAPIId: ID des GraphQL, der die Anfrage API stellt.

  • statusCode: HTTP Statuscode-Antwort.

  • Latenz: nd-to-end E-Latenz der Anfrage in Nanosekunden als Ganzzahl.

{
     "logType": "RequestSummary",
     "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
     "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4",
     "statusCode": 200,
     "latency": 242000000
}

ExecutionSummary

  • requestId: Eindeutiger Bezeichner für die Anfrage.

  • graphQLAPIId: ID des GraphQL, der die Anfrage API stellt.

  • startTime: Der Startzeitstempel der GraphQL-Verarbeitung für die Anfrage im RFC 3339-Format.

  • endTime: Der Endzeitstempel der GraphQL-Verarbeitung für die Anfrage im RFC 3339-Format.

  • Dauer: Die gesamte verstrichene GraphQL-Verarbeitungszeit in Nanosekunden als Ganzzahl.

  • Version: Die Schemaversion von. ExecutionSummary

  • Parsing:

    • startOffset: Der Start-Offset für das Parsen, in Nanosekunden, relativ zum Aufruf, als Ganzzahl.

    • duration: Die für die Analyse aufgewendete Zeit in Nanosekunden als Ganzzahl.

  • Validierung:

    • startOffset: Der Start-Offset für die Validierung, in Nanosekunden, relativ zum Aufruf, als Ganzzahl.

    • duration: Die für die Validierung aufgewendete Zeit in Nanosekunden als Ganzzahl.

{
    "duration": 217406145,
    "logType": "ExecutionSummary",
    "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
    "startTime": "2019-01-01T06:06:18.956Z",
    "endTime": "2019-01-01T06:06:19.174Z",
    "parsing": {
        "startOffset": 49033,
        "duration": 34784
    },
    "version": 1,
    "validation": {
        "startOffset": 129048,
        "duration": 69126
    },
    "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4"
}

Nachverfolgung

  • requestId: Eindeutiger Bezeichner für die Anfrage.

  • graphQLAPIId: ID des GraphQL, der die Anfrage API stellt.

  • startOffset: Der Start-Offset für die Feldauflösung, in Nanosekunden, relativ zum Aufruf, als Ganzzahl.

  • duration: Die für die Auflösung des Felds aufgewendete Zeit in Nanosekunden als Ganzzahl.

  • fieldName: Der Name des Feldes, das aufgelöst wird.

  • parentType: Der übergeordnete Typ des aufgelösten Felds.

  • returnType: Der Rückgabetyp des aufgelösten Felds.

  • path: Eine Liste von Pfadsegmenten, die am Stamm der Antwort beginnt und mit dem aufzulösenden Feld endet.

  • resolverArn: Der Resolver, ARN der für die Feldauflösung verwendet wird. Möglicherweise nicht in verschachtelten Feldern vorhanden.

{
    "duration": 216820346,
    "logType": "Tracing",
    "path": [
        "putItem"
    ],
    "fieldName": "putItem",
    "startOffset": 178156,
    "resolverArn": "arn:aws:appsync:us-east-1:111111111111:apis/pmo28inf75eepg63qxq4ekoeg4/types/Mutation/fields/putItem",
    "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1",
    "parentType": "Mutation",
    "returnType": "Item",
    "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4"
}

Analysieren Sie Ihre Logs mit CloudWatch Logs Insights

Es folgen Beispiele für Abfragen, die Sie ausführen können, um umsetzbare Einblicke in die Leistung und den Zustand Ihrer GraphQL-Operationen zu erhalten. Diese Beispiele sind als Beispielabfragen in der CloudWatch Logs Insights-Konsole verfügbar. Wählen Sie in der CloudWatchKonsole Logs Insights, wählen Sie die AWS AppSync Protokollgruppe für Ihr GraphQL API aus und wählen Sie dann AWS AppSync Abfragen unter Beispielabfragen aus.

Die folgende Abfrage gibt die 10 häufigsten GraphQL-Anfragen mit der maximalen Anzahl verbrauchter Token zurück:

filter @message like "Tokens Consumed"
| parse @message "* Tokens Consumed: *" as requestId, tokens
| sort tokens desc
| display requestId, tokens
| limit 10

Die folgende Abfrage gibt die 10 wichtigsten Resolver mit maximaler Latenz zurück:

  fields resolverArn, duration
| filter logType = "Tracing"
| limit 10
| sort duration desc

Die folgende Abfrage gibt die am häufigsten aufgerufenen Resolver zurück:

  fields ispresent(resolverArn) as isRes
| stats count() as invocationCount by resolverArn
| filter isRes and logType = "Tracing"
| limit 10
| sort invocationCount desc

Die folgende Abfrage gibt Resolver mit den meisten Fehlern in Zuweisungsvorlagen zurück:

  fields ispresent(resolverArn) as isRes
| stats count() as errorCount by resolverArn, logType
| filter isRes and (logType = "RequestMapping" or logType = "ResponseMapping") and fieldInError
| limit 10
| sort errorCount desc

Die folgende Abfrage gibt Resolver-Latenzstatistiken zurück:

  fields ispresent(resolverArn) as isRes
| stats min(duration), max(duration), avg(duration) as avg_dur by resolverArn
| filter isRes and logType = "Tracing"
| limit 10
| sort avg_dur desc

Die folgende Abfrage gibt Feldlatenzstatistiken zurück:

  stats min(duration), max(duration), avg(duration) as avg_dur
  by concat(parentType, '/', fieldName) as fieldKey
| filter logType = "Tracing"
| limit 10
| sort avg_dur desc

Die Ergebnisse von CloudWatch Logs Insights-Abfragen können in CloudWatch Dashboards exportiert werden.

Analysieren Sie Ihre Logs mit Service OpenSearch

Sie können Ihre AWS AppSync Protokolle mit Amazon OpenSearch Service durchsuchen, analysieren und visualisieren, um Leistungsengpässe und Ursachen für Betriebsprobleme zu identifizieren. Sie können Resolver mit der maximalen Latenz und Fehlern identifizieren. Darüber hinaus können Sie OpenSearch Dashboards verwenden, um Dashboards mit aussagekräftigen Visualisierungen zu erstellen. OpenSearch Dashboards ist ein Open-Source-Tool zur Datenvisualisierung und -erkundung, das im Service verfügbar ist. OpenSearch Mithilfe von OpenSearch Dashboards können Sie die Leistung und den Zustand Ihrer GraphQL-Operationen kontinuierlich überwachen. Sie können beispielsweise Dashboards erstellen, um die P90-Latenz Ihrer GraphQL-Anfragen zu visualisieren und die P90-Latenzen jedes Resolvers detailliert zu untersuchen.

Wenn Sie OpenSearch Service verwenden, verwenden Sie „cwl*“ als Filtermuster für die Suche nach Indizes. OpenSearch OpenSearch Der Dienst indexiert die aus Logs gestreamten CloudWatch Protokolle mit dem Präfix „cwl-“. Um AWS AppSync API Protokolle von anderen an OpenSearch Service gesendeten CloudWatch Protokollen zu unterscheiden, empfehlen wir, Ihrer Suche einen zusätzlichen Filterausdruck von graphQLAPIID.keyword=YourGraphQLAPIID hinzuzufügen.

Migration des Protokollformats

Protokollereignisse, die am oder nach dem 8. Mai 2019 AWS AppSync generiert werden, sind vollständig strukturiert JSON formatiert. Um GraphQL-Anfragen vor dem 8. Mai 2019 zu analysieren, können Sie ältere Protokolle JSON mithilfe eines im GitHub Beispiel verfügbaren Skripts zu vollständig strukturierten Protokollen migrieren. Wenn Sie das Protokollformat vor dem 8. Mai 2019 verwenden müssen, erstellen Sie ein Support-Ticket mit den folgenden Einstellungen: Legen Sie Type (Typ) auf Account Management (Kontoverwaltung) und dann Category (Kategorie) auf General Account Question (Allgemeine Frage zum Konto) fest.

Sie können auch Metrikfilter verwenden CloudWatch , um Protokolldaten in numerische CloudWatch Metriken umzuwandeln, sodass Sie sie grafisch darstellen oder einen Alarm auslösen können.