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.

CloudWatch Zur Überwachung und Protokollierung von GraphQL API-Daten verwenden

Sie können Ihre 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 Vielzahl von Metriken zur Überwachung der API-Leistung und -Nutzung bereitstellt. Diese Metriken lassen sich in zwei Hauptkategorien einteilen:

Der Leitfaden stellt auch erweiterte Metriken vor, die detailliertere Daten zur Resolver-Leistung, zu Interaktionen mit Datenquellen 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 Protokollierungsfunktionen für Ihre GraphQL-APIs ermöglicht. Protokolle können auf zwei Ebenen der API festgelegt werden:

Sie können die Protokollierung konfigurieren, Protokolleinträge interpretieren und Protokolldaten zur Problembehandlung und Optimierung verwenden. AWS AppSync bietet verschiedene Protokolltypen, die Aufschluss über die Ausführung, Analyse, Validierung und Feldauflösung Ihrer Abfrage geben.

Einrichtung und Konfiguration

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

Manuelle IAM-Rollenkonfiguration

Wenn Sie eine vorhandene IAM-Rolle verwenden möchten, muss die Rolle die erforderlichen Berechtigungen zum Schreiben von Protokollen gewähren AWS AppSync . CloudWatch Um dies manuell zu konfigurieren, müssen Sie einen ARN für die Servicerolle angeben, damit dieser die Rolle beim Schreiben der Protokolle übernehmen AWS AppSync kann.

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

JSON

{
    "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 AWSAppSyncPushToCloudWatchLogsRole und hängen Sie die neu erstellte Richtlinie an die Rolle an. Bearbeiten Sie die Vertrauensstellung für diese Rolle wie folgt:

JSON

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

Kopieren Sie den Rollen-ARN und verwenden Sie ihn, wenn Sie die Protokollierung für eine AWS AppSync GraphQL-API einrichten.

CloudWatch Metriken

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

Real-time Abonnements

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

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 Kunden übermittelt werden. WebSocket Beispielsweise führt das Senden von 15 kB an Daten an 10 Clients zu 30 ausgehenden Nachrichten (15 kB * 10 Clients/5 kB pro Nachricht = 30 Nachrichten).

Sie können Kontingenterhöhungen 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 zum Anfordern einer Kontingenterhöhung im Service Contingents-Benutzerhandbuch.

Verbesserte Metriken

Verbesserte Metriken liefern detaillierte Daten zur API-Nutzung und -Leistung, wie z. B. Anzahl von AWS AppSync Anfragen und Fehlern, Latenz und Cache hits/misses. Alle erweiterten Metrikdaten werden an Ihr CloudWatch Konto gesendet, und Sie können die Datentypen konfigurieren, die gesendet werden.

Diese Metriken finden Sie auf verschiedenen Einstellungsseiten in der AWS AppSync Konsole. Auf der Seite mit den API-Einstellungen können Sie im Abschnitt „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 sind für alle Resolver in Anfragen aktiviert) oder Metriken pro Resolver (Metriken sind nur für Resolver aktiviert, bei denen die Konfiguration auf aktiviert gesetzt ist) aktivieren. Die folgenden Optionen sind verfügbar:

Verhalten von Datenquellen-Metriken: Diese Optionen steuern, wie zusätzliche Metriken für Datenquellen erfasst werden. Sie können wählen, ob Sie Metriken für vollständige Datenquellen für Anfragen (Metriken, die für alle Datenquellen in Anfragen aktiviert sind) oder Metriken pro Datenquelle (Metriken sind nur für Datenquellen aktiviert, bei denen die Konfiguration auf aktiviert gesetzt ist) aktivieren. Die folgenden Optionen sind verfügbar:

Betriebsmetriken: Aktiviert GraphQL-Metriken auf Betriebsebene.

CloudWatch Protokolle

Sie können zwei Arten von Protokollierung auf jeder neuen oder vorhandenen GraphQL-API konfigurieren: auf dem Anforderungslevel und auf dem Feldlevel.

Request-level Logs

Wenn die Protokollierung auf Anforderungsebene (einschließlich ausführlicher Inhalte) konfiguriert ist, werden die folgenden Informationen protokolliert:

Field-level Protokolle

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

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

Wenn Sie die Protokollierung auf einer GraphQL-API aktivieren und Anfragen stellen, AWS AppSync erstellt 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 dieser Anfrage gekennzeichnet. Auf diese Weise können Sie Protokollereignisse filtern CloudWatch , um alle protokollierten Informationen zu dieser Anfrage abzurufen. Sie können sie RequestId aus den Antwortheadern jeder AWS AppSync GraphQL-Anfrage abrufen.

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

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 eine Feldoperation in CloudWatch Logs könnte etwa 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 an, das beim Ausführen einer Abfrage mit dem Namen zurückgegeben wurdesinglePost(). In diesem Beispiel steht es für das Namensfeld am ersten Index (0). Der StartOffset gibt einen Offset ab dem Beginn der GraphQL-Abfrageoperation an. Die Dauer ist die Gesamtzeit zum Auflösen 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önnen 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, was zu einer schlechten Gesamtleistung des Vorgangs führt.

AWS AppSync Generiert seit dem 8. Mai 2019 Protokollereignisse als vollständig strukturiertes 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 eine AWS AppSync API die Protokollierung in CloudWatch Logs konfiguriert ist und die Protokollebene des Feldauflösers auf Alle gesetzt ist, werden Informationen zur Konflikterkennung und -lösung an die Protokollgruppe ausgegeben. AWS AppSync Dies bietet einen detaillierten Einblick in die Reaktion der AWS AppSync API auf einen Konflikt. Um Ihnen bei der Interpretation der Antwort zu helfen, sind die folgenden Informationen in den Protokollen enthalten:

Verwenden Sie die Anzahl der Tokens, um Ihre Anfragen zu optimieren

Anfragen, die weniger als oder gleich 1.500 KB-seconds Arbeitsspeicher und vCPU-Zeit verbrauchen, wird ein Token zugewiesen. Anfragen mit einem Ressourcenverbrauch von mehr als 1.500 KB-seconds erhalten zusätzliche Token. Wenn eine Anfrage beispielsweise 3.350 verbraucht KB-seconds, AWS AppSync werden der Anfrage drei Token (aufgerundet auf den nächsten Ganzzahlwert) zugewiesen. Weist den APIs AWS AppSync in Ihrem Konto standardmäßig maximal 5.000 oder 10.000 Anforderungstoken pro Sekunde zu, abhängig von der AWS Region, in der es bereitgestellt wird. Wenn Ihre 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 zugeteilte Menge benötigen, können Sie eine Anfrage stellen, 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 Anfordern einer Kontingenterhöhung im Service Quota-Benutzerhandbuch.

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

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 für bestimmte Resolver, Datenquellen oder GraphQL-Operationen abzurufen. Sie können auch die von bereitgestellten Protokollierungsdienstprogramme verwenden, um nur die erforderlichen Informationen AppSync zu protokollieren.

Referenz zum Protokolltyp

RequestSummary

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

ExecutionSummary

{
    "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

{
    "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 Logs Insights CloudWatch

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 CloudWatch Konsole Logs Insights aus, wählen Sie die AWS AppSync Protokollgruppe für Ihre GraphQL-API aus und wählen Sie dann AWS AppSync Abfragen unter Beispielabfragen aus.

Die folgende Abfrage gibt die 10 wichtigsten 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 die Hauptursachen von Betriebsproblemen 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 leistungsstarken Visualisierungen zu erstellen. OpenSearch Dashboards ist ein Open-Source-Tool zur Datenvisualisierung und -erkundung, das in 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 der einzelnen Resolver detailliert zu untersuchen.

Wenn Sie OpenSearch Service verwenden, verwenden Sie „cwl*“ als Filtermuster, um Indizes zu durchsuchen. OpenSearch OpenSearch Der Service indexiert die von 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

AWS AppSync Generierte Protokollereignisse werden hauptsächlich als vollständig strukturiertes JSON formatiert. Bestimmte Diagnose- und Zwischenverarbeitungsmeldungen können jedoch in einem unstrukturierten Format ausgegeben werden. Wenn Sie unstrukturierte Protokolle zu vollständig strukturiertem JSON migrieren müssen, können Sie ein im Beispiel verfügbares Skript verwenden. GitHub

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.