Basiswarnungen bei der Überwachung und dem Incident-Management für Amazon EKS in AMS Accelerate

Container OOM wurde getötet

Die Gesamtzahl der Container-Neustarts innerhalb der letzten 10 Minuten beträgt mindestens 1 und ein Kubernetes-Container in einem Pod wurde innerhalb der letzten 10 Minuten mit dem Grund „OOMKilled“ beendet.

AMS untersucht, ob der OOM-Kill auf das Erreichen des Container-Limits oder die Überbelegung des Speicherlimits zurückzuführen ist, und berät Sie anschließend über Abhilfemaßnahmen.

Pod-Job ist fehlgeschlagen

Ein Kubernetes-Job kann nicht abgeschlossen werden. Ein Fehler wird dadurch angezeigt, dass mindestens ein fehlgeschlagener Auftragsstatus vorhanden ist.

AMS untersucht, warum der Kubernetes-Job oder der entsprechende Cron-Job fehlschlägt, und berät Sie dann über Abhilfemaßnahmen.

StatefulSet Heruntergefahren

Die Anzahl der Replikate, die bereit sind, Datenverkehr bereitzustellen, entspricht mindestens 1 Minute StatefulSet lang nicht der aktuellen Anzahl vorhandener Replikate pro Tag.

AMS ermittelt anhand von Fehlermeldungen in Pod-Ereignissen und Fehlerprotokollfragmenten in Pod-Protokollen, warum Pods nicht bereit sind, und berät Sie dann über Abhilfemaßnahmen.

Fähigkeit zur HPA-Skalierung

Der Horizontal Pod Autoscaler (HPA) kann nicht skaliert werden, da die Statusbedingung „AbleToScale“ mindestens 2 Minuten lang falsch war.

AMS ermittelt, welcher Kubernetes Horizontal Pod Autoscaler (HPA) nicht in der Lage ist, Pods für seine nachfolgende Workload-Ressource zu skalieren, z. B. ein Deployment oder. StatefulSet

Verfügbarkeit von HPA-Metriken

Der Horizontal Pod Autoscaler (HPA) kann keine Messwerte erfassen, da die Statusbedingung „ScalingActive“ mindestens 2 Minuten lang falsch war.

AMS ermittelt, warum HPA keine Messwerte erfassen kann, z. B. Metriken im Zusammenhang mit Serverkonfigurationsproblemen oder RBAC-Autorisierungsproblemen.

Pod nicht bereit

Ein Kubernetes-Pod bleibt länger als 15 Minuten im Status „Nicht aktiv“ (z. B. „Ausstehend“, „Unbekannt“ oder „Fehlgeschlagen“).

AMS untersucht die betroffenen Pods auf Einzelheiten, überprüft die Pod-Logs auf entsprechende Fehler und Ereignisse und berät Sie anschließend über Abhilfemaßnahmen.

Pod-Crash-Looping

Ein Pod-Container wird mindestens einmal alle 15 Minuten über einen Zeitraum von 1 Stunde neu gestartet.

AMS untersucht die Gründe dafür, dass der Pod nicht startet, z. B. unzureichende Ressourcen, eine durch einen anderen Container gesperrte Datei, durch einen anderen Container gesperrte Datenbank, fehlgeschlagene Dienstabhängigkeiten, DNS-Probleme für externe Dienste und Fehlkonfigurationen.

Daemonset ist falsch geplant

Mindestens ein Kubernetes-Daemonset-Pod wurde über einen Zeitraum von 10 Minuten verschoben.

AMS ermittelt, warum ein Daemonset auf einem Knoten geplant ist, auf dem sie nicht ausgeführt werden sollen. Dies kann passieren, wenn der falsche Pod auf die Daemonset-Pods angewendet nodeSelector/taints/affinities wurde oder wenn Knoten (Knotenpools) beschädigt waren und die Entfernung vorhandener Pods nicht geplant war.

Kubernetes-API-Fehler

Die Fehlerrate des Kubernetes-API-Servers liegt über einen Zeitraum von 2 Minuten bei über 3%.

AMS analysiert die Protokolle der Kontrollebene, um das Volumen und die Art der Fehler zu ermitteln, die diese Warnung verursachen, und identifiziert alle Probleme mit Ressourcenkonflikten bei Masterknoten- oder etcd-Autoscaling-Gruppen. Wenn der API-Server nicht wiederhergestellt wird, beauftragt AMS das Amazon EKS-Serviceteam.

Kubernetes-API-Latenz

Die Latenz von Anfragen an den Kubernetes-API-Server beträgt über einen Zeitraum von 2 Minuten mehr als 1 Sekunde.

AMS analysiert die Protokolle der Kontrollebene, um das Volumen und die Art der Fehler zu ermitteln, die zu Latenz führen, und identifiziert alle Probleme mit Ressourcenkonflikten für Masterknoten- oder etcd-Autoscaling-Gruppen. Wenn der API-Server nicht wiederhergestellt wird, beauftragt AMS das Amazon EKS-Serviceteam.

Kubernetes-Client-Zertifikat läuft ab

Das zur Authentifizierung beim Kubernetes-API-Server verwendete Client-Zertifikat läuft in weniger als 24 Stunden ab.

AMS sendet diese Benachrichtigung, um Sie darüber zu informieren, dass Ihr Cluster-Zertifikat in 24 Stunden abläuft.

Der Knoten ist nicht bereit

Der Status „Bereit“ des Knotens ist mindestens 10 Minuten lang falsch.

AMS untersucht die Bedingungen und Ereignisse des Knotens, z. B. Netzwerkprobleme, die den Kubelet-Zugriff auf den API-Server verhindern.

CPU mit hohem Knotenwert

Die CPU-Last übersteigt über einen Zeitraum von 5 Minuten 80%.

AMS ermittelt, ob ein oder mehrere Pods ungewöhnlich viel CPU verbrauchen. Anschließend überprüft AMS gemeinsam mit Ihnen, ob Ihre Anfragen, Grenzwerte und Pod-Aktivitäten den Erwartungen entsprechen.

Node OOM Kill erkannt

In einem 4-Minuten-Fenster wurde vom Knoten mindestens ein Host-OOM-Kill gemeldet.

AMS ermittelt, ob der OOM-Kill durch das Erreichen des Container-Limits oder durch eine Überbelegung des Knotens verursacht wurde. Wenn die Anwendungsaktivität normal ist, informiert Sie AMS über Anfragen und Beschränkungen für Overcommits und die Änderung der Pod-Limits.

Contrack-Limit für Knoten

Das Verhältnis zwischen der aktuellen Anzahl von Verbindungsverfolgungseinträgen und dem Höchstlimit übersteigt über einen Zeitraum von 5 Minuten 80%.

AMS berät Sie über den empfohlenen Conntrack-Wert pro Kern. Kubernetes-Knoten legen den Conntrack-Maximalwert proportional zur Gesamtspeicherkapazität des Knotens fest. Anwendungen mit hoher Auslastung, insbesondere auf kleineren Knoten, können den Conntrack-Max-Wert leicht überschreiten, was zu Verbindungsresets und Timeouts führt.

Die Knotenuhr ist nicht synchron

Der minimale Synchronisierungsstatus über einen Zeitraum von 2 Minuten ist 0, und der maximale Fehler in Sekunden ist 16 oder höher.

AMS bestimmt, ob das Network Time Protocol (NTP) installiert ist und ordnungsgemäß funktioniert.

Hohe CPU-Leistung

Die CPU-Auslastung eines Containers liegt über einen Zeitraum von mindestens 2 Minuten bei einer Rate von über 3 Minuten bei über 80%.

AMS untersucht Pod-Logs, um die Pod-Aufgaben zu ermitteln, die viel CPU verbrauchen.

Pod mit hohem Arbeitsspeicher

Die Speicherauslastung eines Containers überschreitet über einen Zeitraum von 2 Minuten 80% des angegebenen Speicherlimits.

AMS untersucht Pod-Logs, um die Pod-Aufgaben zu ermitteln, die viel Speicher verbrauchen.

CoreDNS ausgefallen

CoreDNS ist seit mehr als 15 Minuten aus der Zielentdeckung von Prometheus verschwunden.

Dies ist eine kritische Warnung, die darauf hinweist, dass die Domainnamenauflösung für interne oder externe Clusterdienste gestoppt wurde. AMS überprüft den Status der CoreDNS-Pods, verifiziert die CoreDNS-Konfiguration, verifiziert DNS-Endpunkte, die auf CoreDNS-Pods verweisen, verifiziert die CoreDNS-Grenzwerte und aktiviert mit Ihrer Zustimmung die CoreDNS-Debug-Protokollierung.

CoreDNS-Fehler

CoreDNS gibt SERVFAIL-Fehler für mehr als 3% der DNS-Anfragen über einen Zeitraum von 10 Minuten zurück.

Diese Warnung kann auf ein Problem mit einer Anwendung oder eine Fehlkonfiguration hinweisen. AMS überprüft den Status der CoreDNS-Pods, verifiziert die CoreDNS-Konfiguration, verifiziert DNS-Endpunkte, die auf CoreDNS-Pods verweisen, verifiziert die CoreDNS-Grenzwerte und aktiviert mit Ihrer Zustimmung die CoreDNS-Debug-Protokollierung.

CoreDNS-Latenz

Das 99. Perzentil der Dauer von DNS-Anfragen überschreitet 4 Sekunden für 10 Minuten.

Diese Warnung signalisiert, dass CoreDNS möglicherweise überlastet ist. AMS überprüft den Status der CoreDNS-Pods, verifiziert die CoreDNS-Konfiguration, verifiziert DNS-Endpunkte, die auf die CoreDNS-Pods verweisen, verifiziert die CoreDNS-Grenzwerte und aktiviert mit Ihrer Zustimmung die CoreDNS-Debug-Protokollierung.

Das 99. Perzentil der Antwortzeit für CoreDNS-Weiterleitungsanfragen an kube-dns überschreitet 4 Sekunden über einen Zeitraum von 10 Minuten.

Wenn CoreDNS nicht der autoritative Server ist oder keinen Cache-Eintrag für einen Domainnamen hat, leitet CoreDNS die DNS-Anfrage an einen Upstream-DNS-Server weiter. Diese Warnung signalisiert, dass CoreDNS möglicherweise überlastet ist oder ein Problem mit einem Upstream-DNS-Server vorliegt. AMS überprüft den Status von CoreDNS-Pods, verifiziert die CoreDNS-Konfiguration, verifiziert DNS-Endpunkte, die auf CoreDNS-Pods verweisen, verifiziert CoreDNS-Grenzwerte und aktiviert mit Ihrer Zustimmung die CoreDNS-Debug-Protokollierung.

CoreDNS-Weiterleitungsfehler

Mehr als 3% der DNS-Abfragen schlagen innerhalb von 5 Minuten fehl.

Wenn CoreDNS nicht der autoritative Server ist oder keinen Cache-Eintrag für einen Domainnamen hat, leitet CoreDNS die DNS-Anfrage an einen Upstream-DNS-Server weiter. Diese Warnung weist auf eine mögliche Fehlkonfiguration oder ein Problem mit einem Upstream-DNS-Server hin. AMS überprüft den Status von CoreDNS-Pods, verifiziert die CoreDNS-Konfiguration, verifiziert DNS-Endpunkte, die auf CoreDNS-Pods verweisen, verifiziert CoreDNS-Grenzwerte und aktiviert mit Ihrer Zustimmung die CoreDNS-Debug-Protokollierung.