Prinzip der Docker-Containerüberwachung und Anweisungen zur Installation und Verwendung von cAdvisor

Es ist sehr wichtig, den Betriebsstatus von Containern in der Produktionsumgebung zu überwachen. Durch die Überwachung können wir den Betriebsstatus des Containers jederzeit erfassen, um Online-Risiken und -Probleme frühzeitig zu erkennen und zu lösen.

Deshalb werde ich heute mein Wissen über die Containerüberwachung (Prinzipien und Tools cAdvisor) mit Ihnen teilen.

Obwohl es für die herkömmliche Überwachung physischer und virtueller Maschinen bereits relativ ausgereifte Überwachungslösungen gibt, steht die Containerüberwachung vor größeren Herausforderungen, da sich das Verhalten und die Art von Containern von herkömmlichen virtuellen Maschinen unterscheiden. Im Allgemeinen weisen Container die folgenden Merkmale auf:

Container sind kurzlebig und können dynamisch geplant werden

Die Essenz eines Containers ist ein Prozess, kein vollständiges Betriebssystem

Da Container sehr leichtgewichtig sind, werden sie häufiger erstellt und gelöscht als herkömmliche virtuelle Maschinen.

Es gibt viele Überwachungslösungen für Docker-Container. Neben dem mit Docker gelieferten Befehl „Docker Stats“ gibt es viele Open-Source-Lösungen wie sysdig, cAdvisor, Prometheus usw., die alle hervorragende Überwachungstools sind.

Sehen wir uns zunächst an, wie man mit Dockers eigenem Befehl „Docker Stats“ Container ohne die Hilfe externer Tools überwachen kann.

Verwenden des Docker-Stats-Befehls

Mit dem mit Docker gelieferten Befehl „Docker Stats“ können Sie problemlos die Nutzung von CPU, Speicher, Netzwerk-E/A, Festplatten-E/A, PID und anderen Ressourcen aller Container auf dem Host anzeigen. Sehen wir uns unten die spezifischen Vorgänge an.

Verwenden Sie zunächst den folgenden Befehl auf dem Host, um einen Nginx-Container mit einem Ressourcenlimit von 1 Kern und 2 G zu starten:

$ docker run --cpus=1 -m=2g --name=nginx -d nginx

Nachdem der Container gestartet wurde, können Sie den Status der Ressourcennutzung des Containers mit dem Befehl „Docker Stats“ anzeigen:

$ Docker-Statistiken nginx

Über den Befehl „Docker Stats“ können Sie den Betriebsstatus des Containers wie folgt anzeigen:

CONTAINER CPU % SPEICHERNUTZUNG / LIMIT SPEICHER % NET I/O BLOCK I/O PIDS

f742a467b6d8 0,00 % 1,387 MiB / 2 GiB 0,07 % 656 B / 656 B 0 B / 9,22 kB 2

Aus dem Laufstatus des Containers ist ersichtlich, dass der Befehl „Docker Stats“ tatsächlich den Laufstatus des Docker-Containers abrufen und anzeigen kann. Allerdings liegen auch seine Mängel auf der Hand, denn es kann nur lokale Daten abrufen, historische Überwachungsdaten nicht anzeigen und verfügt über kein visuelles Anzeigefeld.

Daher verwenden wir in Produktionsumgebungen normalerweise eine andere Containerüberwachungslösung, cAdvisor.

cBerater

cAdvisor ist eine allgemeine Containerüberwachungslösung als Open Source von Google. cAdvisor kann nicht nur Informationen zu allen auf dem Computer ausgeführten Containern sammeln, sondern auch eine grundlegende Abfrageschnittstelle und eine HTTP-Schnittstelle bereitstellen, was die Integration in externe Systeme erleichtert. Daher wurde cAdvisor schnell zur am häufigsten verwendeten Komponente für die Überwachung von Containermetriken, und Kubernetes integrierte cAdvisor auch als Standardtool für die Überwachung von Containermetriken.

Installation und Nutzung von cAdvisor

Nachfolgend demonstrieren wir anhand der Version 0.37.0 von cAdvisor die Installation und Verwendung von cAdvisor am Beispiel.

cAdvisor stellt offiziell ein Docker-Image zur Verfügung. Wir müssen das Image nur abrufen und starten.

Da das cAdvisor-Image im Image-Repository gcr.io von Google gespeichert ist, ist es in China nicht zugänglich. Hier habe ich das erstellte Image auf Docker Hub abgelegt. Sie können es mit dem Befehl „docker pull lagoudocker/cadvisor:v0.37.0“ aus dem Docker Hub abrufen.

Starten Sie zunächst cAdvisor mit folgendem Befehl:

$ Docker-Ausführung \
 --volume=/:/rootfs:ro \
 --volume=/var/run:/var/run:ro \
 --volume=/sys:/sys:ro \
 --volume=/var/lib/docker/:/var/lib/docker:ro \
 --volume=/dev/disk/:/dev/disk:ro \
 --publish=8080:8080 \
 --detach=true \
 --name=cadvisor \
 --privilegiert \
 --device=/dev/kmsg \
 lagoudocker/cadvisor:v0.37.0

An diesem Punkt wurde cAdvisor erfolgreich gestartet und wir können auf die cAdvisor-Weboberfläche zugreifen, indem wir http://localhost:8080 besuchen.

cAdvisor kann nicht nur die Containerressourcennutzung, sondern auch die Hostressourcennutzung überwachen. Als Nächstes schauen wir uns an, wie die Nutzung der Hostressourcen überprüft wird.

Verwenden Sie cAdvisor, um die Hostüberwachung anzuzeigen

Besuchen Sie http://localhost:8080/containers/. Auf der Homepage können Sie die Ressourcennutzung des Hosts sehen, einschließlich CPU, Speicher, Dateisystem, Netzwerk und anderer Ressourcen, wie in der folgenden Abbildung dargestellt.

Containerüberwachung mit cAdvisor anzeigen

Wenn Sie die Ressourcennutzung der auf dem Host laufenden Container anzeigen möchten, können Sie http://localhost:8080/docker/ besuchen. Auf dieser Seite werden die grundlegenden Informationen zu Docker und den laufenden Containern aufgelistet, wie in der folgenden Abbildung dargestellt.

In der obigen Abbildung werden unter „Subcontainer“ alle Container aufgelistet, die auf dem aktuellen Host ausgeführt werden. Klicken Sie auf einen der Container, um den detaillierten Ausführungsstatus des Containers anzuzeigen, wie in der folgenden Abbildung dargestellt.

Im Allgemeinen bietet die Verwendung von cAdvisor zur Überwachung von Containern die folgenden Funktionen:

Kann den Status physischer Maschinen und Container gleichzeitig erfassen

Kann historische Überwachungsdaten anzeigen

Nachdem Sie nun die Überwachungstools von Docker kennen, fragen Sie sich, woher diese Überwachungsdaten stammen? Als nächstes zeige ich Ihnen die Prinzipien der Containerüberwachung.

Überwachungsprinzip

Wir wissen, dass Docker basierend auf Namespace, Cgroups und Union File System implementiert ist. Cgroups können nicht nur zum Begrenzen von Containerressourcen verwendet werden, sondern ermöglichen auch die Auslastung von Containerressourcen. Unabhängig von der Implementierung der Überwachungslösung stammen die zugrunde liegenden Daten von Cgroups.

Das Arbeitsverzeichnis von Cgroups ist /sys/fs/cgroup, und das Verzeichnis /sys/fs/cgroup enthält den gesamten Inhalt von Cgroups. Cgroups enthalten viele Subsysteme, die zum Begrenzen verschiedener Ressourcen verwendet werden können. Begrenzen und überwachen Sie beispielsweise Ressourcen wie CPU, Speicher, PID und Festplatten-E/A.

Um das Cgroups-Subsystem genauer zu verstehen, verwenden wir den Befehl ls -l, um den Ordner /sys/fs/cgroup anzuzeigen und viele Verzeichnisse anzuzeigen:

$ sudo ls -l /sys/fs/cgroup/
gesamt 0
 
dr-xr-xr-x 5 root root 0 Jul 9 19:32 blkio
lrwxrwxrwx 1 root root 11 Jul 9 19:32 cpu -> cpu,cpuacct
dr-xr-xr-x 5 root root 0 9. Juli 19:32 cpu,cpuacct
lrwxrwxrwx 1 root root 11 Jul 9 19:32 cpuacct -> cpu,cpuacct
dr-xr-xr-x 3 root root 0 9. Juli 19:32 cpuset
dr-xr-xr-x 5 root root 0 Jul 9 19:32 Geräte
dr-xr-xr-x 3 root root 0 Jul 9 19:32 Gefrierschrank
dr-xr-xr-x 3 root root 0 Jul 9 19:32 hugetlb
dr-xr-xr-x 5 root root 0 Jul 9 19:32 Speicher
lrwxrwxrwx 1 root root 16. Juli 9 19:32 net_cls -> net_cls,net_prio
dr-xr-xr-x 3 root root 0 9. Juli 19:32 net_cls,net_prio
lrwxrwxrwx 1 root root 16. Juli 9 19:32 net_prio -> net_cls,net_prio
dr-xr-xr-x 3 root root 0 Jul 9 19:32 perf_event
dr-xr-xr-x 5 root root 0 Jul 9 19:32 pids
dr-xr-xr-x 5 root root 0 9. Juli 19:32 systemd

Diese Verzeichnisse stellen Cgroups-Subsysteme dar, und Docker erstellt unter jedem Cgroups-Subsystem einen Docker-Ordner. Wenn Sie nicht viel über das Cgroups-Subsystem wissen, machen Sie sich keine Sorgen. Sie müssen nur verstehen, dass die Containerüberwachungsdaten von Cgroups stammen.

Wie ermittelt das Überwachungssystem das Speicherlimit des Containers?

Als Nächstes nehmen wir das Speichersubsystem (das Speichersubsystem ist eines der vielen Subsysteme von Cgroups und wird hauptsächlich zur Begrenzung der Speichernutzung verwendet) als Beispiel, um zu erklären, wie die Überwachungskomponente die Ressourcengrenzen und den Nutzungsstatus des Containers (dh die Speichergrenze des Containers) erhält.

Wir starten zunächst einen Nginx-Container mit einem Ressourcenlimit von 1 Kern und 2 G auf dem Host mit dem folgenden Befehl:

$ docker run --name=nginx --cpus=1 -m=2g --name=nginx -d nginx

## Die Ausgabe hier ist die Container-ID

51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1

Hinweis: Wenn Sie bereits einen Container mit dem Namen nginx erstellt haben, löschen Sie bitte zuerst den vorhandenen nginx-Container mit dem Befehl docker rm -f nginx.

Nachdem der Container gestartet wurde, können wir die Container-ID über die Ausgabe der Befehlszeile abrufen. Gleichzeitig erstellt Docker einen entsprechenden Ordner im Verzeichnis /sys/fs/cgroup/memory/docker mit der Container-ID als Namen.

Werfen wir einen Blick auf die Dateien im Verzeichnis /sys/fs/cgroup/memory/docker:

$ sudo ls -l /sys/fs/cgroup/memory/docker
gesamt 0
 
drwxr-xr-x 2 Wurzel Wurzel 0 Sep 2 15:12 51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
-rw-r--r-- 1 root root 0 2. September 14:57 cgroup.clone_children
--w--w--w- 1 root root 0 2. September 14:57 cgroup.event_control
-rw-r--r-- 1 root root 0 2. September 14:57 cgroup.procs
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.failcnt
--w------ 1 root root 0 2. September 14:57 memory.force_empty
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.kmem.failcnt
-rw-r--r-- 1 root root 0 2. September 14:57 memory.kmem.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 memory.kmem.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. Sep 14:57 memory.kmem.slabinfo
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.kmem.tcp.failcnt
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.kmem.tcp.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 memory.kmem.tcp.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. September 14:57 memory.kmem.tcp.usage_in_bytes
-r--r--r-- 1 root root 0 2. September 14:57 memory.kmem.usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 Speicher.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 Speicher.max_usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.memsw.failcnt
-rw-r--r-- 1 root root 0 2. September 14:57 memory.memsw.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. September 14:57 memory.memsw.usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 14:57 Uhr memory.move_charge_at_immigrate
-r--r--r-- 1 root root 0 2. September 14:57 memory.numa_stat
-rw-r--r-- 1 root root 0 2. September 14:57 memory.oom_control
---------- 1 root root 0 2. September 14:57 memory.pressure_level
-rw-r--r-- 1 root root 0 2. September 14:57 memory.soft_limit_in_bytes
-r--r--r-- 1 root root 0 2. Sep 14:57 memory.stat
-rw-r--r-- 1 root root 0 2. Sep 14:57 Speicher.swappiness
-r--r--r-- 1 root root 0 2. September 14:57 Speicherverbrauch in Bytes
-rw-r--r-- 1 root root 0 2. Sep 14:57 memory.use_hierarchy
-rw-r--r-- 1 root root 0 2. Sep 14:57 notify_on_release
-rw-r--r-- 1 root root 0 2. Sep. 14:57 Aufgaben

Sie können sehen, dass Docker ein Verzeichnis erstellt hat, das nach der Container-ID benannt ist. Verwenden wir den Befehl ls, um den Inhalt des Verzeichnisses anzuzeigen:

$ sudo ls -l /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1
 
gesamt 0
-rw-r--r-- 1 root root 0 2. September 15:21 cgroup.clone_children
--w--w--w- 1 root root 0 2. September 15:13 cgroup.event_control
-rw-r--r-- 1 root root 0 2. September 15:12 cgroup.procs
-rw-r--r-- 1 root root 0 2. September 15:12 memory.failcnt
--w------ 1 root root 0 2. September 15:21 memory.force_empty
-rw-r--r-- 1 root root 0 2. September 15:21 memory.kmem.failcnt
-rw-r--r-- 1 root root 0 2. September 15:12 memory.kmem.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:21 memory.kmem.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. September 15:21 memory.kmem.slabinfo
-rw-r--r-- 1 root root 0 2. September 15:21 memory.kmem.tcp.failcnt
-rw-r--r-- 1 root root 0 2. September 15:21 memory.kmem.tcp.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:21 memory.kmem.tcp.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. September 15:21 memory.kmem.tcp.usage_in_bytes
-r--r--r-- 1 root root 0 2. September 15:21 memory.kmem.usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:12 Speicher.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:12 Speicher.max_usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:21 memory.memsw.failcnt
-rw-r--r-- 1 root root 0 2. September 15:12 memory.memsw.limit_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:21 memory.memsw.max_usage_in_bytes
-r--r--r-- 1 root root 0 2. September 15:21 memory.memsw.usage_in_bytes
-rw-r--r-- 1 root root 0 2. September 15:21 memory.move_charge_at_immigrate
-r--r--r-- 1 root root 0 2. September 15:21 memory.numa_stat
-rw-r--r-- 1 root root 0 2. September 15:13 memory.oom_control
---------- 1 root root 0 2. September 15:21 memory.pressure_level
-rw-r--r-- 1 root root 0 2. September 15:21 memory.soft_limit_in_bytes
-r--r--r-- 1 root root 0 2. September 15:21 memory.stat
-rw-r--r-- 1 root root 0 2. September 15:21 memory.swappiness
-r--r--r-- 1 root root 0 2. September 15:12 Speicherverbrauch in Bytes
-rw-r--r-- 1 root root 0 2. Sep 15:21 memory.use_hierarchy
-rw-r--r-- 1 root root 0 2. Sep 15:21 notify_on_release
-rw-r--r-- 1 root root 0 2. Sep 15:21 Aufgaben

Wie oben zu sehen ist, befinden sich im Verzeichnis der Container-ID viele Dateien. Die Datei memory.limit_in_bytes stellt die Speichergrenzgröße des Containers in Bytes dar. Wir verwenden den Befehl cat (der Befehl cat kann den Dateiinhalt anzeigen), um den Dateiinhalt anzuzeigen:

$ sudo cat /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.limit_in_bytes

2147483648

Hier können Sie sehen, dass der Wert von memory.limit_in_bytes 2147483648 beträgt, was nach der Konvertierung genau 2 G entspricht und mit dem Speicherlimit von 2 G übereinstimmt, als wir den Container gestartet haben.

Am Beispiel des Speichersubsystems können wir erkennen, dass die Überwachungskomponente den Containerspeichergrenzwert durch Lesen der Datei memory.limit_in_bytes ermitteln kann. Nachdem wir die Speichergrenze des Containers verstanden haben, werfen wir einen Blick auf die Speichernutzung des Containers.

$ sudo /sys/fs/cgroup/memory/docker/51041a74070e9260e82876974762b8c61c5ed0a51832d74fba6711175f89ede1/memory.usage_in_bytes

4259840

Sie können sehen, dass die aktuelle Speichernutzung 4259840 Bytes, etwa 4 MB, beträgt. Verstehen Sie die Speicherüberwachung.

Als Nächstes werfen wir einen Blick auf die Quellen der Netzwerküberwachungsdaten.

Die Datenquelle zur Netzwerküberwachung wird aus dem Verzeichnis /proc/{PID}/net/dev gelesen, wobei PID die Prozess-ID des Containers auf dem Host ist. Als nächstes verwenden wir zunächst den Befehl docker inspect, um die PID des oben gestarteten nginx-Containers anzuzeigen. Der Befehl lautet wie folgt:

$ docker inspect nginx |grep Pid
 
   "Pid": 27348,
 
   "PidMode": "",
 
   "PidsLimit": 0,

Sie können sehen, dass die PID des Containers 27348 ist. Verwenden Sie den Befehl cat, um den Inhalt von /proc/27348/net/dev anzuzeigen.

$ sudo cat /proc/27348/net/dev
Inter-| Empfangen | Senden
Gesicht |Bytes Pakete Fehler Drop Fifo Rahmen komprimiert Multicast|Bytes Pakete Fehler Drop Fifo Colls Träger komprimiert
 
 siehe: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
 eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Die Datei /proc/27348/net/dev zeichnet den von jeder Netzwerkkarte im Container empfangenen und gesendeten Datenverkehr sowie die Anzahl der Fehler, die Anzahl der Paketverluste und andere Informationen auf. Es ist ersichtlich, dass von hier aus regelmäßig die Netzwerküberwachungsdaten des Containers ausgelesen und angezeigt werden.

Zusammenfassend lässt sich sagen, dass das Überwachungsprinzip des Containers eigentlich darin besteht, die relevanten Dateien auf dem Linux-Host regelmäßig zu lesen und sie dem Benutzer anzuzeigen.

Abschluss

k8s verwendet Metrikserver, cAdvisor stellt die zugrunde liegenden Daten bereit und die zugrunde liegende Datenquelle des Metrikservers ist cAdvisor.

cAdvisor stellt Überwachungsdaten bereit und Prometheus ist für die Datenerfassung verantwortlich. Diese beiden Funktionen sind unterschiedlich. In Produktionsclustern wird cAdvisor im Allgemeinen zusammen mit Prometheus verwendet.

Der obige Artikel zu den Prinzipien der Docker-Containerüberwachung und zur Installation und Verwendung von cAdvisor ist der gesamte Inhalt, den der Herausgeber mit Ihnen teilt. Ich hoffe, er kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen.