Docker Monitoring – 7 Rzeczy O Których Warto Wiedzieć

Decydując się na użycie Dockera produkcyjnie, oprócz benefitów związanych z skalowalnością czy łatwością przenoszenia na różne środowiska, czekają nas również wyzwania. Bez wątpienia, jednym z największych wyzwań jest monitoring. Aby móc kontrolować nasze środowiska, potrzebujemy również zrozumieć co naprawdę dzieje się wewnątrz skonteneryzowanych aplikacji. Monitoring jest pierwszym krokiem ku temu. Jesteśmy w stanie śledzić na bieżąco stan naszego środowiska i wykrywać potencjalne problemy wydajnościowe.

1. Czym jest monitoring kontenerów

Monitoring kontenerów to proces śledzenia aplikacji zawartych w kontenerze poprzez kolekcjonowanie i analizowanie metryk dotyczących ich wydajności. Proces ten jest bardziej złożony i różni się nieco od monitorowania tradycyjnych aplikacji działających na maszynach wirtualnych. Wynika to z ogólnej natury kontenerów, które są emferyczne. Pomimo złożoności problemu nie możemy „nie monitorować”. Chcąc zapewnić wysoką wydajność oraz dostępność naszych aplikacji, nadal kwestia ta jest krytyczna.
Oprócz monitorowania aplikacji działających w kontenerach, musimy również skupić się na monitorowaniu…kontenerów. Mam tutaj na myśli zasoby sprzętowe przypisane do kontenera takie jak pamięć operacyjna czy zużycie procesora.

2. Benefity monitoringu

Nie mając monitoringu, nie mamy pewności, że obecna wydajność aplikacji spełnia nasze początkowe założenia. Nie wiemy czy wraz ze wzrostem użytkowników aplikacja działa ciągle tak samo.
Innymi słowy, nie jesteśmy w stanie zmierzyć wydajności naszego systemu.

Obecnie wymagania co do dostępności aplikacji (biznesowych) są wygórowane. Nie możemy sobie pozwolić na przestoje w działaniu aplikacji. Dzięki monitoringu jesteśmy w stanie wychwycić wszelkie niedociągnięcia, zanim dowiemy się o nich od użytkowników systemu.

Każdy monitoring jest lepszy niż brak monitoringu.

3. Różnice w monitoringu

Monitorowanie kontenerów nie różni się całkowicie od tradycyjnego monitoringu. Nadal potrzebujemy zbierać logi, metryki oraz używać health-checków. Podstawową różnicą jest dodatkowa warstwa do monitorowania, wynikająca z architektury i budowy kontenerów oraz Dockera. Mówi się, że dobry monitoring powinien pokrywać wszystkie warstwy całego ekosystemu.

4. Idealny system monitoringu

1. Po pierwsze powinien zawierać podstawowe parametry takie jak bieżące wykorzystanie pamięci czy procesora hosta. Dodatkowo należy pamiętać, że każdy kontener ma przydzielone limity procesora i pamięci. Dzięki takim metrykom, jesteśmy w stanie ustalić i zdecydować w którą stronę należy skalować naszą solucję. Jeżeli mamy do dyspozycji wolne zasoby, być może wystarczy tylko zwiększenie samego limitu dla poszczególnych kontenerów.
2. Po drugie, monitorowanie kontenerów powinno pokrywać również infrastrukturę. W przypadku środowisk opartych o Docker Swarm czy Kubernetes – musimy zwrócić uwagę na wskaźniki procesora nie tylko dla pojedynczej maszyny, ale dla całego klastra. Dzięki temu możemy również zadecydować o kierunku skalowania.
3. Po trzecie, oprócz infrastruktury, nie możemy zapomnieć o monitorowaniu samej aplikacji działającej wewnątrz kontenera. Przykładowo, jeżeli mamy do czynienia z aplikacją webową, należy monitorować czasy odpowiedzi czy liczbę żadąń do serwera. Nie jesteśmy w stanie uzyskać tych informacji np. z runtime’u mówiącemu nam o cyklu życia kontenerów.

Podsumowując, każda warstwa wewnątrz naszego ekosystemu może wpłynąć na finalne działanie skonteneryzowanej aplikacji. Tworząc monitoring, warto pomyśleć o takim, który obejmie wszystkie warstwy – począwszy od infrastruktury, aż po warstwę aplikacji.

5. Najprostszy monitoring – Docker API

Nie możemy do końca nazwać to monitorowaniem, aczkolwiek uważam że każdy powinien wiedzieć o takiej możliwości. Chodzi tutaj o wbudowane komendy CLI: min. docker logs czy docker stats wykorzystujące Docker API do wyświetlania odpowiednio logów oraz aktualnego zużycia zasobów sprzętowych.

Podstawowa wbudowana komenda służąca do wyświetlania logów z kontenera to docker logs. Zwykle by z niej skorzystać, musimy najpierw użyć komendy docker ps, by uzyskać ID kontenera, z którego logi chcemy wyświetlić.

docker logs CONTAINER_ID

Przykładowo, aby wyświetlić tylko 10 ostatnich logów z kontenera, należy użyć polecenia:

docker logs CONTAINER_ID --tail 10

$ docker logs postgres --tail 10
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

PostgreSQL Database directory appears to contain a database; Skipping initialization

LOG:  database system was shut down at 2020-01-20 07:59:45 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

Drugim istotnym poleceniem jest docker stats. Wyświetla „na żywo” stan zużycia zasobów przez poszczególne kontenery (uruchomione) oraz przypisane limity.

CONTAINER ID        NAME                                 CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
dda1311d5d21        visitbooker_visitbooker-postgres_1   0.01%               8.07MiB / 1.934GiB    0.41%               3.75kB / 0B         26.8MB / 2.85MB     6   
2296b6704d71        mvc_db_1                             1.35%               634.7MiB / 1.934GiB   32.05%              1.11MB / 325kB      1.23GB / 44.3MB     134 

Jak widać w powyższym listingu, dla dwóch kontenerów pamięć operacyjna została przydzielona równo po 1.934 GiB.

Warto to kontrolować i uniknąć sytuacji, w której limity zasobów sprzętowych mogą okazać się niewystarczające. Warto również wiedzieć, że jeżeli sami nie wyspecyfikujemy limitu zasobów dla danego kontenera, Docker ustawi je automatycznie.

6. Analiza logów

Zamiast samodzielnie i manualnie używać Docker API (docker logs) do analizowania logów pochodzących z kontenerów, możemy ułatwić i zautomatyzować ten proces, wykorzystując dostępne narzędzia open-source.

Obecnie popularnym narzędziem do gromadzenia logów jest Elasticsearch, który najczęściej łączy się z innymi narzędziami tworząc tzw. ELK Stack

Po pierwsze, może to być Logstash – służący do zasilania Elastica danymi oraz Kibana do ich wizualizacji.

7. Zbieranie metryk

Do zbierania metryk jednym z najbardziej popularnych i zarazem rekomendowanych przez Dockera narzędzi jest Prometheus. Należy podkreślić, że nie służy on wyłącznie do monitoringu kontenerów. Używając tego narzędzia możemy monitorować: serwery, bazy danych, wirtualne maszyny. Krótko mówiąc, prawie wszystko 🙂

Prometheus jest narzędziem open-source, jednak jego popularność jest na tyle duża, że jest używany przez duże organizacje. Dodatkowo jest prężnie rozwijany przez społeczność.

Jako ciekawostkę można przytoczyć fakt, iż w 2016 roku Prometheus dołączył do Cloud Native Computing Foundation, jako drugi projekt project po Kubernetes.

W połączeniu z narzędziem takim jak Grafana, służącym do wizualizacji danych, możemy uzyskać podobny efekt jak poniżej.

Podsumowanie

Nie ważne z ilu kontenerów składa się Twój system. Monitoring zawsze będzie kluczową kwestią, aby zapewnić ciągłość działania aplikacji. Jako DevOps czy osoba odpowiadająca za projekt potrzebujesz zintegrowanego monitoringu, dzięki któremu możesz śledzić wydajność i odpowiednio reagować.

Czas poświęcony na konfiguracje środowiska oraz potencjalne koszty dedykowanej infrastruktury z pewnością szybko się spłacą. Z biznesowego punktu widzenia, jest to również kluczowa kwestia. Często większe firmy zawierają kontrakty, w których definiują kary umowne w razie niedostępności systemów.

W kolejnym artykule, przedstawię obszerny monitoring oparty o Prometheusa. Cała solucja będzie składać się z dodatkowych narzędzi.

• Node Exporter gromadzącym głownie metryki sprzętowe i systemu operacyjnego
• cAdvisor dostarczający metryki zużycia zasobów przez poszczególne kontenery
• Grafana do wizualizacji i tworzenia dashboardów.

Warto dołączyć do newslettera, by nie przegapić tego wpisu!