Днес трябваше да дебъгвам малко докер images и се сетих за нещо, което е полезно, но не винаги е очевидно при дебъгването. Днес ще си говорим за docker stats.

nedko@vortex$ docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
b1075225ec45 dreamy_blackwell 1.07% 599.2MiB / 7.697GiB 7.60% 18.2MB / 9.06MB 53.1MB / 23.1MB 132
36d367f20b13 zealous_elbakyan 1.20% 585MiB / 7.697GiB 7.42% 29.1MB / 20MB 67.9MB / 23.1MB 131
16b464b3eadc relaxed_bell 1.20% 640.9MiB / 7.697GiB 8.13% 30.7MB / 21.5MB 118MB / 23.1MB 130
b139b36a1c5c focused_night 1.22% 602.2MiB / 7.697GiB 7.64% 18.5MB / 9.44MB 119MB / 23.1MB 132

И ето, че имаме статистики за CPU/Memory usage/limits (ако не е сме ограничили използването на RAM памет на контейнера обикновено е лимита на хоста върху който върви), Network и Disk usage и PID.

Като изпълните docker stats ще се учудите защо премига така – това е заради постоянния refresh на статистиките. docker stats приема и четири много полезни параметъра, които често използвам и аз:

-aПоказва всички контейнери, пo default показва само тези, които са running
-formatМожете да използвате Go template за да изберете какво точно да виждате, пример по-долу
–no-streamДа покаже само първите резултати и да не рефрешва постоянно
–no-truncДа показва пълните ID-та на контейнери, например 7c37df0bd781b924e92218bd006a950fcc2871e26f17886f98c281de49c91216 вместо 7c37df0bd781
docker stats parameters

Както видяхте по-горе в импровизираната табличка можем да използваме –format и да output-нем JSON dada например.

Това е една малка, но съществена стъпка в дебъгването на проблеми свързани с докер контейнери. Скоро смятам да разпиша една по-подробна статия с моя начин за дебъг.