Wie rufe ich Amazon EKS-Steuerebenenprotokolle aus CloudWatch Logs ab?

Behebung

Voraussetzung: Um deine Protokollereignisse in Amazon CloudWatch Logs anzuzeigen, musst du die Amazon EKS-Steuerebenenprotokolle in deinem Cluster aktivieren.

Um auf deine Amazon EKS-Steuerebenenprotokolle zuzugreifen, verwende CloudWatch Logs Insights. Führe anschließend Abfragen für die Amazon EKS-Steuerebenenprotokolldaten aus.

Amazon EKS-Steuerebenenprotokolle anzeigen

Führe die folgenden Schritte aus:

1. Öffne die Amazon-CloudWatch-Konsole.
2. Wähle im Navigationsbereich Protokolle und dann Protokoll-Insights.
3. Wähle im Menü Protokollgruppe(n) auswählen die Cluster-Protokollgruppe aus, die du abfragen möchtest.
4. Wähle Ausführen aus, um die Ergebnisse anzuzeigen.

Hinweis: Um die Ergebnisse als CSV-Datei zu exportieren oder die Ergebnisse in die Zwischenablage zu kopieren, wähle Ergebnisse exportieren aus. Um Daten für einen bestimmten Anwendungsfall zu erhalten, passe die Beispielabfrage an.

Beispielabfragen für gängige Amazon EKS-Anwendungsfälle

Hinweis: Du kannst Abfragen in CloudWatch Logs Insights speichern und erneut ausführen.

Die folgenden Abfragen sind Beispiele für gängige Amazon EKS-Anwendungsfälle.

Mutierende Änderungen finden

Um mutierende Änderungen zu finden, die an der aws-auth ConfigMap vorgenommen wurden, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
| filter @logStream like /^kube-apiserver-audit/  
| filter requestURI like /\/api\/v1\/namespaces\/kube-system\/configmaps/  
| filter objectRef.name = "aws-auth"  
| filter verb like /(create|delete|patch|update)/  
| sort @timestamp desc  
| limit 50  

Nach abgelehnten Anfragen suchen

Um Nachrichten zu finden, die den Status denied enthalten, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
| filter @logStream like /authenticator/  
| filter @message like "denied"  
| sort @timestamp asc  
| limit 50

Knoten eines geplanten Pods finden

Führe die folgende Abfrage aus, um den Knoten zu finden, auf dem du einen Pod geplant hast:

fields  @timestamp, @message  
| filter @logStream like /kube-scheduler/  
| filter @message like "example-pod-name"  
| filter @message like "ip-"  
| sort @timestamp asc  
| limit 3

Hinweis: Ersetze example-pod-name durch den Namen deines Pods.

HTTP 5xx-Server-Fehler finden

Um HTTP-5xx-Serverfehler für Kubernetes-API-Serveranfragen zu finden, führe die folgende Abfrage aus:

fields @logStream, @timestamp, responseStatus.code, @message  
| filter @logStream like /^kube-apiserver-audit/  
| filter responseStatus.code >= 500  
| limit 50

Problembehandlung bei der Aktivierung eines CronJob-Objekts

Um API-Vorgänge zu finden, die der cronjob-controller ausgeführt hat, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
| filter @logStream like /kube-apiserver-audit/  
| filter user.username like "system:serviceaccount:kube-system:cronjob-controller"  
| display @logStream, @timestamp, @message, objectRef.namespace, objectRef.name  
| sort @timestamp desc  
| limit 50

API-Vorgänge des replicaset-controller finden

Um API-Vorgänge zu finden, die der replicaset-controller ausgeführt hat, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
| filter @logStream like /kube-apiserver-audit/  
| filter user.username like "system:serviceaccount:kube-system:replicaset-controller"  
| display @logStream, @timestamp, requestURI, verb, user.username  
| sort @timestamp desc  
| limit 50

HTTP-Antwort-Codes finden und zählen

Um die Anzahl der HTTP-Antwortcodes für Aufrufe an den Kubernetes-API-Server zu zählen, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
|filter @logStream like /^kube-apiserver-audit/  
| stats count(*) as count by responseStatus.code  
| sort count desc

Beispielausgabe:

responseStatus.code,count  
200,35066  
201,525  
403,125  
404,116  
101,2

Hinweis: Die Ausgabe zeigt 35.066 erfolgreiche Anfragen für HTTP 200, 525 erstellte Ressourcen für HTTP 201 und 125 verbotene Anfragen für HTTP 403. Sie zeigt auch 116 „Not Found“-Fehler für HTTP 404 und 2 „Switching Protocol“-Anfragen für HTTP 101.

Änderungen an DaemonSets oder Addons finden

Um Änderungen zu finden, die du an DaemonSets oder Addons im Namespace kube-system vorgenommen hast, führe die folgende Abfrage aus:

filter @logStream like /^kube-apiserver-audit/  
| fields @logStream, @timestamp, @message  
| filter verb like /(create|update|delete)/ and strcontains(requestURI,"/apis/apps/v1/namespaces/kube-system/daemonsets")  
| sort @timestamp desc  
| limit 50

Patch-, Aktualisierungs-, Erstellungs- und Löschungsaufrufe finden

Um alle Patch-, Update-, Create- und Delete-Aufrufe zu finden, die sich auf eine bestimmte Bereitstellung und deren Pods beziehen, führe die folgende Abfrage aus:

fields @timestamp, verb, objectRef.name, objectRef.resource, requestObject.message
| filter objectRef.name like /example-deployment-name/
| filter objectRef.resource not like /serviceaccounts/
| filter objectRef.resource not like /events/
| filter verb like /create|delete|patch|update/
| sort @timestamp asc

Hinweis: Ersetze example-deployment-name durch den Namen deiner Bereitstellung. Um Ereignisse auszuschließen, kannst du | filter objectRef.resource not like /events/ aus der Abfrage entfernen.

Benutzer identifizieren, der einen Knoten oder eine Ressource gelöscht hat

Um den Benutzer zu finden, der einen Knoten gelöscht hat, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message  
| filter @logStream like /^kube-apiserver-audit/  
| filter verb == "delete" and requestURI like "/api/v1/nodes"  
| sort @timestamp desc  
| limit 10

Um den Benutzer zu finden, der eine Ressource gelöscht hat, z. B. eine ConfigMap, einen Pod oder eine Bereitstellung, führe die folgende Abfrage aus:

fields @timestamp,verb, user.username, user.extra.arn.0, user.extra.canonicalArn.0   
| filter  objectRef.name like /aws-auth/  
| filter verb like /delete/  
| sort @timestamp asc

Hinweis: Um Delete-Aufrufe für deinen Pod zu finden, ersetze aws-auth durch deinen Pod-Namen.

Image-Version einer Bereitstellung finden

Um die Image-Version einer Bereitstellung zu finden, führe die folgende Abfrage aus:

fields @timestamp, verb, objectRef.name,  objectRef.resource  
| filter objectRef.name like /example-deployment-name/  
| filter @message like /image/  
| filter objectRef.resource  like /deployments/  
| parse requestObject.spec.template.spec 'image':*, as image  
| sort @timestamp asc  
| limit 10000

Hinweis: Ersetze example-deployment-name durch den Namen deiner Bereitstellung.

Ereignisse für einen bestimmten Knoten identifizieren

Um einen Knoten zu finden, der nicht aktualisiert ist, führe die folgende Abfrage aus:

fields @timestamp, @message, @logStream  
| sort @timestamp asc  
| filter @message like "node example-node-name hasn't been updated for"

Hinweis: Ersetze example-node-name durch den Namen deines Knotens.

Um die letzte Übergangszeit für die Parameter eines bestimmten Knotens zu überprüfen, führe die folgende Abfrage aus:

fields @timestamp  
| parse responseObject.status.conditions.0 "lastTransitionTime*" as MemoryPressure  
| parse responseObject.status.conditions.1 "lastTransitionTime*" as DiskPressure  
| parse responseObject.status.conditions.2 "lastTransitionTime*" as PIDPressure  
| parse responseObject.status.conditions.3 "lastTransitionTime*" as ReadyStatus  
| parse responseObject.status.conditions.3 "lastTransitionTime*" as Timepass  
| filter objectRef.name like /example-node-name/  
| filter verb like /patch/  
| filter @message like /lastTransitionTime/  
| sort @timestamp asc

Hinweis: Ersetze example-node-name durch den Namen deines Knotens.

Benutzer identifizieren, der einen Knoten gesperrt hat

Führe die folgende Abfrage aus, um den Benutzer zu finden, der bestimmte Knoten gesperrt oder die Knoten unplanbar gemacht hat:

fields @timestamp, objectRef.name as node_name, verb,user.username, user.extra.sessionName.0 as name, requestObject.spec.unschedulable as unschedulable_flag| filter @logStream like /kube-apiserver-audit/  
| filter @message like /example-node-IP/  
| filter verb like /patch/  
| filter requestObject.spec.unschedulable like /1/

Hinweis: Ersetze example-node-IP durch die IP-Adresse deines Knotens.

PodIP eines gelöschten Pods identifizieren

Um eine gelöschte Pod-IP podIP zu finden, führe die folgende Abfrage aus:

fields @timestamp,objectRef.name as pod, requestObject.status.podIP as podIP  
| filter @logStream like /kube-apiserver-audit/  
| filter objectRef.name = "example-pod-name"  
| filter verb like /patch/  
| filter ispresent(requestObject.status.podIP)  
| sort @timestamp asc

Hinweis: Ersetze example-pod-name durch den Namen deines Pods.

Objektausgabe eines unbekannten Pods finden

Um die Describe-Ausgabe für einen gelöschten Pod ohne den Pod-Namen anzuzeigen, führe die folgende Abfrage aus:

fields @timestamp, requestURI, requestObject.message  
| filter requestURI like '/api/v1/namespaces/example-namespace/events'   
| filter  responseObject.involvedObject.name like /example-deployment-name/  
| sort @timestamp asc

Hinweis: Ersetze example-deployment-name durch den Namen deiner Bereitstellung und example-namespace durch deinen Namespace. Wenn es nicht mehrere Objekte mit demselben Namen in mehreren Namespaces gibt, entferne die Zeile, die filter requestURI like enthält.

Knoten eines geplanten Pods finden

Führe die folgende Abfrage aus, um den Knoten zu finden, auf dem du einen Pod geplant hast:

fields  @timestamp, @message  
| filter @logStream like /kube-scheduler/  
| filter @message like "example-pod-name"  
| filter @message like "ip-"  
| sort @timestamp asc  
| limit 3

Hinweis: Ersetze example-pod-name durch den Namen deines Pods.

Auf eine Bereinigungs-API überprüfen

Hinweis: Wenn durch das Patchen des Betriebssystems (OS) von AWS Fargate deine Pods oder Knoten gelöscht wurden, erscheint die Bereinigungs-API in den Audit-Protokollen.

Um zu überprüfen, ob eine Eviction-API in deinen Audit-Protokollen erscheint, führe die folgende Abfrage aus:

filter @logStream like /kube-apiserver-audit/  
| fields @timestamp, user.username,user.extra.canonicalArn.0, responseStatus.code, responseObject.status, responseStatus.message  
| sort @timestamp asc  
| filter verb == "create" and objectRef.subresource == 'eviction'

Um das Ereignis eines Eviction-API-Vorgangs zu finden, führe die folgende Abfrage aus:

fields @logStream, @timestamp, @message   
| sort @timestamp asc   
| filter user.username == "eks:node-manager" and requestURI like "eviction" and requestURI like "pod"

Aufgaben-ID eines Fargate-Pods finden

Um die Aufgaben-ID eines Fargate-Pods zu finden, führe die folgende Abfrage aus:

fields @timestamp, verb, responseObject.spec.providerID as InstanceID  
| filter @message like /example-fargate-node-IP/  
| filter ispresent(responseObject.spec.providerID)

Hinweis: Ersetze example-fargate-node-IP durch die IP-Adresse deines Fargate-Knotens.

URL identifizieren, die Fehler empfängt

Um eine URL zu finden, die mehr als eine bestimmte Anzahl von 4##- oder 5##-Fehlern erhält, führe die folgende Abfrage aus:

fields requestURI   
| filter @logStream like "kube-apiserver-audit-i"   
| filter count > example-filter-count   
| stats count(*) as count by requestURI, responseStatus.code   
| filter responseStatus.code >= 400  
| sort count desc

Hinweis: Ersetze example-filter-count durch die Mindestanzahl von Fehlern, die die Abfrageausgabe anzeigen muss.

Webhook-Fehler beheben

Um Fehler mit webhooks zu finden, führe die folgende Abfrage aus:

fields @timestamp, @message  
| filter @logStream like /kube-apiserver/ and @logStream not like /kube-apiserver-audit/  
| filter @message like /failed calling webhook/  
| sort @timestamp desc  
| stats count(*) by bin(1m)

Fehlgeschlagene API-Server-Zustandsprüfungen auflisten

Um fehlgeschlagene Zustandsprüfungen des API-Servers aufzulisten, führe die folgende Abfrage aus:

fields @message  
| sort @timestamp asc  
| filter @logStream like "kube-apiserver"  
| filter @logStream not like "kube-apiserver-audit"  
| filter @message like "healthz check failed"

Kubernetes-Objekte und CloudWatch Logs userAgent-Index zählen

Um Anfragen nach Kubernetes-Objekten und dem CloudWatch Logs userAgent-Index zu zählen, führe die folgende Abfrage aus:

fields @timestamp, @message, @logStream  
| filter @logStream like "kube-apiserver-audit"   
| display @logStream, requestURI, verb   
| stats count(*) as count by objectRef.resource, userAgent  
| sort count desc  
| display objectRef.resource, userAgent, count

Häufigste Protokolle anzeigen

Um deine am häufigsten auftretenden Protokolle anzuzeigen, führe die folgende Abfrage aus:

fields @timestamp, @message, @logStream  
| filter @logStream not like /kube-apiserver-audit/  
| parse @message "*] *" as loggingTimeStamp, loggingMessage  
| stats count(*) as count by loggingMessage   
| sort count desc