CSI-Treiber: So erfassen Sie Protokolle

Erfassung von CSI-Treiberprotokollen
Dies umfasst das Aktivieren des Debuggens, das Reproduzieren des Problems, wenn möglich, das Sammeln von Protokollen für den CSI-Treiber-Controller und das Sammeln von Protokollen vom Node-Pod.

Aktivieren Sie Debug-Protokolle für den CSI-Treiber-Controller und die Node-Pods.
Weitere Informationen finden Sie unter "Konfiguration der dynamischen Protokollierung" in der Dokumentation: https://dell.github.io/csm-docs/docs/csidriver

Bestimmen Sie die Namen der Controller- und Node-Pods.
Verwenden Sie die Funktion kubectl get pods , um die Pods im Treiber-Namespace aufzulisten.

# kubectl get pods -n isilon
NAME                                READY   STATUS    RESTARTS        AGE
isilon-controller-66d7d9d7c-6j6f4   6/6     Running   0               11m
isilon-node-9wngk                   2/2     Running   0               27d

Erfassen Sie CSI-Treiber-Controller-Protokolle.
Protokolle sollten für die Controller-Pods gesammelt werden. Sammeln Sie Protokolle von allen Controllern mithilfe der kubectl logs . Stellen Sie sicher, dass Sie den relevanten Container wie den Treiber übergeben.

kubectl logs -n <namespace> <controller> <container> > <file name>

Beispiel:

kubectl logs -n isilon isilon-controller-66d7d9d7c-6j6f4 driver > isilon-controller-66d7d9d7c-6j6f4_driver.log

Wiederholen Sie dies für alle erforderlichen Container im Zusammenhang mit Ihrem Problem (Attacher, Snapshotter, Provisioner, Treiber, Resizer usw.). Stellen Sie sicher, dass Sie den Dateinamen der Ausgabedatei so ändern, dass er mit dem Controller-Namen und dem Container übereinstimmt.

Erfassen Sie CSI-Treiber-Node-Pod-Protokolle.
Die Protokolle sollten auch für die Worker-Nodes erfasst werden. Dies kann einen Node oder mehrere Nodes umfassen, wenn ein problematischer Pod von einem Node zu einem anderen verschoben wird. Dadurch werden die Protokolle für jeden der Container im CSI-Treiber-Node-Pod (Treiber, Registrierungsstelle usw.) gesammelt:

kubectl logs -n <namespace> <worker node> > <filename>.txt

Beispiel:

kubectl logs -n isilon isilon-node-9wngk driver > isilon-node-9wngk_driver.txt
kubectl logs -n isilon isilon-node-9wngk registrar > isilon-node-9wngk_registrar.txt

Alternativen
Skript:
Dadurch werden alle Controller-Protokolle einzeln erzeugt (ändern Sie den Namespace "isilon" bei Bedarf an 2 Stellen) und Container werden nach Bedarf hinzugefügt.

for x in $(kubectl get pods -n isilon | grep controller | awk '{print $1}'); do for i in attacher provisioner driver snapshotter;do kubectl logs -n isilon $x -c $i > $x-$i.txt;done;done

Dadurch werden Node-Protokolle erfasst (ändern Sie den Namespace "isilon" bei Bedarf an zwei Stellen) und Container werden nach Bedarf hinzugefügt.

for x in $(kubectl get pods -n isilon | grep node | awk '{print $1}'); do for i in driver registrar;do kubectl logs -n isilon $x -c $i > $x-$i.txt;done;done

Option "Seit"
Das Sammeln aller Protokolle könnte mehr Daten als erforderlich liefern. Die "--since" kann verwendet werden, um für einen bekannten Zeitraum zu sammeln. Auf diese Option folgen "5 s", "5 m" oder "5 h" für Sekunden, Minuten oder Stunden, je nachdem, wie weit die Protokollerfassung zurückreichen soll. Dies ist auch hilfreich, wenn das Problem reproduziert wurde. Sammeln Sie die Protokolle der letzten 5 Minuten (oder die Zeit, die für die Reproduktion benötigt wurde):

Beispiel:

kubectl logs -n isilon isilon-node-xxx driver --since 5m > isilon-node-xxx_driver.txt

Alle Container
Beim Troubleshooting ist es hilfreich, die Protokolle wie oben beschrieben separat zu erfassen. Manchmal kann es vorkommen, dass der Containername durch "--all-containers", um die Protokolle aller Container des Pods zu erfassen, kann nützlich sein.

Beispiel:

kubectl logs -n isilon isilon-node-xxx --all-containers> isilon-node_driver.txt

Weitere erforderliche Angaben:
Container Orchestrator (K8s, OpenShift usw.) und Version
Kubernetes-Version und -Variante
Treiberversion
Arrayversion oder Mikrocode
Betriebssystem und Version der K8-Nodes

 

Bei früheren Versionen wird das Debuggen durch Bearbeiten der Bereitstellung/des Daemonset aktiviert.

So listen Sie die Bereitstellungen auf: Bearbeiten Sie die Bereitstellung: Beispiel: Dadurch wird ein VI-Editor geöffnet. Ändern Sie den Parameter X_CSI_DEBUG in "true" (i für Einfügen) und speichern Sie (:wq):
        -Namen:
X_CSI_DEBUG Wert: "true"
Für Isilon sollte der Inhalt der OneFS REST API auch im Debug protokolliert werden, indem die Einstellung auf 0 (wahr) gesetzt wird:
        -Namen:
X_CSI_VERBOSE Wert: "0"

Aktivieren Sie die Debug-Protokolle des CSI-Treiber-Node, indem Sie das Daemonset bearbeiten.
Das Debuggen wird durch Bearbeiten des Daemonset aktiviert. 

So listen Sie die Daemonsets auf: Bearbeiten Sie das Daemonset: Dadurch wird ein VI-Editor geöffnet. Ändern Sie den Parameter X_CSI_DEBUG in "true" und speichern Sie.
        -Namen:
X_CSI_DEBUG Wert: "Wahr"
Für Isilon sollte der Inhalt der OneFS REST API auch im Debug protokolliert werden, indem die Einstellung auf 0 (true) gesetzt wird:
        -Namen:
X_CSI_VERBOSE Wert: "0"

Da Debug-Protokolle nicht rückwirkend erfolgen, reproduzieren Sie das Problem, wenn möglich, vor der Erfassung von Protokollen.