W ostatnim czasie miałem fazę na tworzenie monitoringu w systemie. Zaczęło się oczywiście od samych kontenerów, ale chwila moment doszedłem do wniosku, że potrzebuję też informacji o zajętości dysków. Wiedziałem, że tego nie będę w stanie zmierzyć używając cAdvisora (tj. w sensie, w którym chciał bym), więc muszę znaleźć rozwiązanie, aby odczytywać dokładny procent zapełnienia dysków per mountpoint. Do tego celu użyłem node_exportera. Ta usługa, domyślnie integruje się z Prometheusem, a w związku z tym z Grafaną. Następnie, po skończeniu tego zostałem z kolei zainspirowany pogodą. Ostatnie wysokie temperatury spowodowały, że chciałem wiedzieć jak radzi sobie jeden i drugi procesor oraz dyski NVMe w obu maszynach w tych temperaturach.

Widząc dyski, czas na temperaturę

Zgodnie ze wstępem, gdy dodałem wykresy dla dysków (i tego ile mam jeszcze miejsca na faktyczne dane, ale też cache czy bufor pobierania) uznałem, że jest tak gorąco, że dobrze byłoby wiedzieć jak sobie procesory radzą temperaturowo i jak się wykres (rozkład średniej temperatury) pokrywa ze średnim obciążeniem procentowym w czasie (np. 5 minut). Zakładałem, że ani jeden, ani drugi serwer nie są wyjątkowo obciążone w czasie. Ale okazało się, że jednak są. A, właściwie - jeden z nich okazał się zewnętrznie cieplejszy od drugiego i nie miało to wiele wspólnego z tym, gdzie stoi sam w sobie w pokoju. Z jednej strony to dobrze, bo ciepły był na wylotach powietrza z budy, wszędzie indziej był chłodny, co oznacza, że system daje radę odprowadzić ciepło poprawnie. Z drugiej strony, ten serwer konkretny to Storage region mojego systemu. Ma głównie przechowywać dane, backupy itd, nie robi zbyt wiele. Nawet “workery” indeksujące treści wewnątrz S3 pracują wyłącznie na drugim regionie, a nie na tym. I nadal pozostaje pytanie co dokładnie obciąża ten serwer. W sytuacji, gdybym nie sprawdził wykresami, że coś jest z temperaturami rozłożonymi w czasie nie tak, nawet nie spróbowałbym go dotknąć, żeby zobaczyć jaką ma temperaturę organoleptycznie.

Co było potencjalnym źródłem?

Tak na prawdę to nie wiem. Z monitorowania obciążenia rdzeni procesora używając interwału 5m tak samo jak dla temperatury na “CPU package”, to się niespecjalnie pokrywa ze sobą, więc niewiele z tego realnie wynika. Natomiast zużycie procesora w czasie rzeczywistym patrząc na htopie wskazuje, że chodzi o Garage S3, który jest wiecznie “szturchany” przez jedną z instancji PikaCore, by zweryfikować aktualny stan bucketów. Ta usługa jako jedyna realnie zajmuje dużo czasu procesora i ma uśredniony CPU usage dość wysoki, co sugeruje, że to on powoduje peaki temperaturowe, jednak nadal nie jestem pewny, bo skoki uśrednionej temperatury na procesorze są nieregularne, a “szturchanie” odbywa się w trybie ciągłym z perspektywy sample’owania danych (ma miejsce średnio co sekundę).

A co ma do tego Pika Note?

Jest powiązany pośrednio tylko dlatego, że sam ostatnio trafił na monitoring, a od wczoraj został również zmigrowany na lokalne regiony ze zdalnego środowiska na Azure. Dodatkowo, poszły również quick fixy dotyczące działania zakładek oraz odświeżania tokenów autoryzacyjnych w tle (a właściwie to przejście na mechanizm odświeżania per request basis, gdy jest potrzeba, a nie na bieżąco). W związku z tym rozszerzyłem również monitoring dla backendu (uptime, zużycie procesora, aktualne zużycie RAM).