core dump handler
v9.0.0
Dieses Helmdiagramm ist für die Bereitstellung von Funktionen konzipiert, die Core-Dumps von den meisten öffentlichen Cloud-Kubernetes-Dienstanbietern und privaten Kubernetes-Instanzen automatisch in einem S3-kompatiblen Speicherdienst speichern.
Bitte lesen Sie die Datei CONTRIBUTING.md, sie enthält einige wichtige Hinweise. Achten Sie besonders auf die Richtlinien zum Codierungsstil und das Entwickler-Ursprungszertifikat
Wir als Mitglieder, Mitwirkende und Führungskräfte verpflichten uns, die Teilnahme an unserer Gemeinschaft für alle zu einem belästigungsfreien Erlebnis zu machen, unabhängig von Alter, Körpergröße, sichtbarer oder unsichtbarer Behinderung, ethnischer Zugehörigkeit, Geschlechtsmerkmalen, Geschlechtsidentität und -ausdruck, Erfahrungsniveau und Bildung , sozioökonomischer Status, Nationalität, persönliches Aussehen, Rasse, Religion oder sexuelle Identität und Orientierung.
Wir verpflichten uns, auf eine Weise zu handeln und zu interagieren, die zu einer offenen, einladenden, vielfältigen, integrativen und gesunden Gemeinschaft beiträgt.
Den vollständigen Verhaltenskodex finden Sie hier
Ausführliche Informationen finden Sie in der Tabelle README.md.
Dies ist eine Matrix bestätigter Testziele. Bitte PR-Umgebungen, von denen bekannt ist, dass sie funktionieren
| Anbieter | Produkt | Version | Validiert? | Arbeiten? |
| AWS | EKS | 1.21 | Ja | Ja |
| AWS | ROSA | 4.8 | Ja | Ja |
| Benutzerdefinierter Build | K8S | N / A | Ja | Ja |
| Digitaler Ozean | K8S | 1.21.5-do.0 | Ja | Ja |
| GKE-cos_containerd | 1.20.10-gke.1600 | Ja | Ja | |
| GKE-Ubuntu | 1.20.10-gke.1600 | Ja | Ja | |
| IBM | IKS | 1,19-1,21 | Ja | Ja |
| IBM | ROKS | 4,6-4,8 | Ja | Ja |
| Microsoft | AKS | 1.19 | Ja | Ja |
| Microsoft | ARO | 4.8 | Ja | Ja |
| RedHat | Vor Ort | 4.8 | Ja | Ja |
Core Dumps sind ein entscheidender Teil der Beobachtbarkeit.
Da Systeme zunehmend verteilter werden, bieten Core-Dumps den Teams einen nicht-invasiven Ansatz, um zu verstehen, warum Programme in jeder Umgebung, in der sie bereitgestellt werden, nicht richtig funktionieren.
Core Dumps sind in einer Vielzahl von Szenarien nützlich, aber in den folgenden Fällen sind sie sehr relevant:
Der Prozess wird ohne einen nützlichen Stack-Trace beendet
Der Prozess verfügt nicht mehr über genügend Speicher
Eine Anwendung verhält sich nicht wie erwartet
Die traditionellen Probleme bei Core-Dumps sind:
Aufwand für die Verwaltung der Dumps
Für die Dump-Analyse waren spezielle Tools erforderlich, die auf dem Computer des Entwicklers nicht ohne weiteres verfügbar waren.
Verwalten des Zugriffs auf die Dumps, da diese vertrauliche Informationen enthalten können.
Dieses Diagramm zielt darauf ab, die Probleme im Zusammenhang mit Core-Dumps zu lösen, indem gängige Plattformen (K8s, ROKS und Object Storage) in einer Cloud-Umgebung genutzt werden, um die schwere Arbeit zu übernehmen.
Das Diagramm stellt zwei Prozesse bereit:
Der Agent verwaltet die Aktualisierung der /proc/sys/kernel/* Konfiguration, stellt den Composer-Dienst bereit und lädt die vom Composer erstellte Core-Dumps-ZIP-Datei in eine Objektspeicherinstanz hoch.
Der Composer übernimmt die Verarbeitung eines Core-Dumps sowie die Erstellung von Laufzeit-, Container-Coredump- und Image-JSON-Dokumenten aus CRICTL und deren Einfügen in eine einzelne ZIP-Datei. Die ZIP-Datei wird im lokalen Dateisystem des Knotens gespeichert, damit der Agent sie hochladen kann.
Wenn Sie das IBM Cloud Core Dump Handler Helm-Diagramm installieren, werden die folgenden Kubernetes-Ressourcen in Ihrem Kubernetes-Cluster bereitgestellt:
Namespace : Es wird ein bestimmter Namespace erstellt, in dem die Komponenten installiert werden. Der Standardwert ist ibm-observe
Handler-Daemonset : Das Daemonset stellt einen Pod auf jedem Worker-Knoten in Ihrem Cluster bereit. Das Daemonset enthält eine Konfiguration, die es dem erhöhten Prozess ermöglicht, das Kernmuster zu definieren, um den Kernspeicherauszug im Objektspeicher zu platzieren und Pod-Informationen zu sammeln, falls verfügbar.
Privilegierte Richtlinie : Das Daemonset konfiguriert den Hostknoten, sodass Berechtigungen erforderlich sind.
Dienstkonto : Standarddienstkonto zum Ausführen des Daemonsets
Volume Claims : Zum Kopieren des Composers auf den Host und zum Ermöglichen des Zugriffs auf die generierten Core-Dumps
Clusterrolle : Erstellt mit einer Ereignisressource und einem Erstellungsverb und verknüpft mit dem Dienstkonto.
Um das Helm-Diagramm in Ihrem Cluster zu installieren, müssen Sie über die Plattformrolle „Administrator“ verfügen.
Dieses Diagramm stellt privilegierte Kubernetes-Daemonsets mit den folgenden Auswirkungen bereit:
Die automatische Erstellung eines privilegierten Containers pro Kubernetes-Knoten, der in der Lage ist, Kerndateien zu lesen und das Crictl nach Pod-Informationen abzufragen.
Das Daemonset nutzt die Hostpath-Funktion zur Interaktion mit dem zugrunde liegenden Linux-Betriebssystem.
Die Composer-Binärdatei wird auf dem Hostserver bereitgestellt und ausgeführt
Core-Dumps können vertrauliche Laufzeitdaten enthalten und der Zugriff auf den Storage-Bucket muss entsprechend verwaltet werden.
Objektspeicherschlüssel werden als Geheimnisse gespeichert und als Umgebungsvariablen im Daemonset verwendet
Der IBM Cloud Core Dump Handler erfordert die folgenden Ressourcen auf jedem Worker-Knoten, um erfolgreich ausgeführt zu werden:
$ helm delete core-dump-handler --namespace observe
host-name gelöscht ist, bevor Sie fortfahren $ kubectl get pvc -n observe
$ helm install core-dump-handler . --namespace observe
helm delete core-dump-handler -n observe
Erstellen Sie das Image docker build -t YOUR_TAG_NAME .
Übertragen Sie das Image per Push in Ihre Container-Registrierung
Aktualisieren Sie den Container in der Datei values.yaml , um ihn zu verwenden.
image :
registry : YOUR_REGISTRY
repository : YOUR_REPOSITORY
tag : YOUR_TAGoder führen Sie den Helm-Installationsbefehl mit den Einstellungen aus
--set image.registry=YOUR_REGISTRY
--set image.repository=YOUR_REPOSITORY
--set image.tag=YOUR_TAG
Die Dienste werden in Rust mit rustup geschrieben.
Lokale Unit-Tests können mit cargo test im Basisordner ausgeführt werden
Derzeit werden nur IBM Cloud ROKS und IKS unterstützt. Wir führen jedoch gerne Integrationstests für andere Dienste durch, können diese jedoch nicht vor der Veröffentlichung ausführen.
Um den Integrationstest-Build auszuführen, befolgen Sie die Anweisungen für einen benutzerdefinierten Build
Erstellen Sie im Stammverzeichnis des Projektordners eine Datei namens .env mit der folgenden Konfiguration
S3_ACCESS_KEY=XXXX
S3_SECRET=XXXX
S3_BUCKET_NAME=XXXX
S3_REGION=XXXX
Wechseln Sie in das Verzeichnis „Integration“ und führen Sie den Test aus
cd integration
./run-ibm.sh
Releases basieren auf einem Pre-Release-Zweig, z. B. werden Integrationstests pre-8.5.0 manuell ausgeführt und ein Release wird generiert, wenn es mit dem Hauptzweig zusammengeführt wird.
Eine Automatisierung ist derzeit nicht möglich, da die Kubernetes-Integration in Github-Aktionen nicht zuverlässig genug ist.
Wenn Sie eine Vorabversion mit Ihren eigenen Integrationstests testen möchten, melden Sie bitte ein Problem und wir können bei Ihrem Testlauf zusammenarbeiten.
Der erste Ort, an dem nach Problemen gesucht werden kann, ist die Agentenkonsole. Eine erfolgreiche Installation sollte so aussehen
[2021-09-08T22:28:43Z INFO core_dump_agent] Setting host location to: /var/mnt/core-dump-handler
[2021-09-08T22:28:43Z INFO core_dump_agent] Current Directory for setup is /app
[2021-09-08T22:28:43Z INFO core_dump_agent] Copying the composer from ./vendor/default/cdc to /var/mnt/core-dump-handler/cdc
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for kernel.core_pattern /var/mnt/core-dump-handler/core_pattern.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/core_pattern.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for kernel.core_pipe_limit /var/mnt/core-dump-handler/core_pipe_limit.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/core_pipe_limit.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Starting sysctl for fs.suid_dumpable /var/mnt/core-dump-handler/suid_dumpable.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created Backup of /var/mnt/core-dump-handler/suid_dumpable.bak
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of kernel.core_pattern=|/var/mnt/core-dump-handler/cdc -c=%c -e=%e -p=%p -s=%s -t=%t -d=/var/mnt/core-dump-handler/core -h=%h -E=%E
kernel.core_pattern = |/var/mnt/core-dump-handler/cdc -c=%c -e=%e -p=%p -s=%s -t=%t -d=/var/mnt/core-dump-handler/core -h=%h -E=%E
kernel.core_pipe_limit = 128
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of kernel.core_pipe_limit=128
fs.suid_dumpable = 2
[2021-09-08T22:28:43Z INFO core_dump_agent] Created sysctl of fs.suid_dumpable=2
[2021-09-08T22:28:43Z INFO core_dump_agent] Creating /var/mnt/core-dump-handler/.env file with LOG_LEVEL=info
[2021-09-08T22:28:43Z INFO core_dump_agent] Executing Agent with location : /var/mnt/core-dump-handler/core
[2021-09-08T22:28:43Z INFO core_dump_agent] Dir Content []
Wenn der Agent erfolgreich ausgeführt wird, liegt möglicherweise ein Problem mit der Composer-Konfiguration vor. Um die Protokolle für den Composer zu überprüfen, öffnen Sie eine Shell im Agenten und durchsuchen Sie die Datei „composer.log“, um zu sehen, ob Fehlermeldungen vorliegen.
cat /var/mnt/core-dump-handler/composer.log
Wenn keine Fehler vorliegen, sollten Sie das Standardprotokoll in der Datei „values.yaml“ von error auf debug ändern und das Diagramm erneut bereitstellen. Erstellen Sie erneut einen Core-Dump und /var/mnt/core-dump-handler/composer.log sollte spezifische Details zu jedem Upload enthalten.
