PROMETHEUS (prometheus.yml)
Monitoring infrastrukury IT - minimalna konfiguracja

    Prometheus ma główny plik konfiguracyjny, który jest czytany przez PROMETHEUS-a przy starcie Jego skutek wraz z opcjami domyślnymi (nie ujętymi w nim) możemy ujrzeć pod adresem http://127.0.0.1:9090/config. Na podstawie dokumentacji, czy też podpowiedzi samego programu:

  • prometheus --help

można stwierdzić, że jest nią opcja --config.file="prometheus.yml". Możem w niej jednocześnie określić jego lokalizację. Przyjeło się, że jest to:

  • /etc/prometheus/prometheus.yml

Gdy nie podamy ani nazwy pliku, ani scieżki do pliku konfiguracyjnego będzie domyślnie poszukiwany z punktu, z którego PROMETHEUS jest wywoływany. Przy tej okazji chciałbym zwrócić uwagę na trzy inne ustawienia wiersza poleceń konfigurujące niezmienne parametry systemowe PROMETHEUS-a. Są to flagi określające miejsce przechowywyanie danych w trybie serwer oraz adres i port na którym pracuje UI, API i telemetria oraz opcję zezwalającą na wykonanie HTTP POST żądania  /-/reload  do punktu końcowego umożliwiając ponowne przeładowanie reguł i plików, czy też wręcz wyłączenie narzędzia ( curl -X POST http://127.0.0.1:9090/-/reload ):

    Domyślna zawartość prometheus.yml jest obładowana wieloma dodatkowymi parametrami. Dotyczą one ustawień monitorowanych obiektów, częstotliwość pobierania (scrabowania) danych, przetwarzania danych oraz zasad ich przechowywania. Plik zawiera także reguły alarmów  i warunków powiadomień oraz inne pliki reguł, które mają być załadowane. Jednak na tą chwilę skupimy się na logice, a nie na szczegółach. W jego strukturze możemy wyróżnić kilka zasadniczych bloków global, alerting, rule_files, scrape_configs (patrz przykład poniżej):

  • global:
       scrape_interval: 15s
       scrape_timeout: 10s
       evaluation_interval: 15s
       query_log_file: /var/log/prometheus/query.log
       scrape_failure_log_file: /var/log/prometheus/scrape.log                                                     external_labels:                                                                                                                        environment: 'bit-pve-1'                                                                                                        datecenter: 'bit-srv-102'

    scrape_configs:
       - job_name: 'prometheus-102'
         static_configs:
             - targets: ['localhost:9090']

Parametry będące w sekcji global obowiązują, jako domyślne dla wszystkich innych grup zasad, reguł itd. Pierwsze ustawienie scrape_interval domyślnie wynosi 1 [m] natomiast w powyższym przykładzie wymusza pobieranie danych od celów co 15 [s]. Druga zmienna mówi ile czasu ma czekać (10[s]) na zadane pytanie o dane (scrape). Logicznym jest by wartość tego parametru nie była większa od scrape_interval. Trzecie ustawienie evaluation_interval określa okres czasu w którym następuje ocena zapytania pod kontem alertu. Sensownym jest by znowuż wartość tego parametry była identyczną z scrape_interval. Jednak bywają wyjątki w regule (PROMETHEUS is running as a remote write target.) i wtedy z pomocą nadchodzi stała rule_query_offset: domyślnie wynosząca 0[s]. Następne dwa wiersze opisują miejsce przechowywania logów serwera www PROMETHEUS-a (query.log) na porcie w powyższej konfiguracji 9090 oraz pobieranych danych (scrape.log). W tym momencie zamiast tłumaczyć po co są logi opiszę zastosowanie operacji rotacji tych plików by nie wypełniły wolnej przestrzeni dyskowej w 100%. Intalujemy pakiet logrotate:

  • apt-get install logrotate

Tworzymy plik prometheus w katalogu /etc/logrotate.d/ :

  • touch /etc/logrotate.d/prometheus

 i wypełniamy go (nano /etc/logrotate.d/prometheus) poniźszym tekstem :

  • /var/log/prometheus/query.log {
       daily
       rotate 7
       compress
       delaycompress
       postrotate
          killall -HUP prometheus
       endscript
    }
    /var/log/prometheus/scrape.log {
       daily
       rotate 7
       compress
       delaycompress
       postrotate
          killall -HUP prometheus
       endscript
    }

Sprawdzamy wykonaną pracę komendą z opcją -d (symulacja rotacji):

  • sudo logrotate -d /etc/logrotate.conf

Naszym oczom powinien się pokazać analogiczny widok:


Po 7 dniach możemy wystawić faktyczną ocenę zaglądając do logów Prometheus-a rozkazem:

  • ls -la /var/log/prometheus

    Skoro tak dogłębnie pochyliłem się nad rejestracją zdarzeń to było by dużym moim niedopatrzeniem bym nie wspomniał o miejscu przechowywania plików samej bazy danych. Nie są one przechowywane w katalogu z którego była wykonana komenda uruchomienia PROMETHEUS-a, a w podkatologach /var/lib/prometheus. Wynika to z stałej --storage.tsdb.path zawartej w plku uruchomieniowym /etc/systemd/system/prometheus.service (patrz mój poprzedni artykół  http://bit.sos.pl/blog/historia-sukcesu-2/prometheus-instalacja-62 ). 

    Ostatnie trzy wiersze w sekcji global służą dodaniu etykiet 'bit-pve-1' oraz 'bit-srv-100' do dowolnych serii czasowych lub alertów przy ich przekazywaniu do zewnętrznych systemów typu zdalny magazyn, menadzer alarmów itp. Może wydaje się to na początku przerostem formy nad treścią, ale w środowisku produkcyjnym sprawdza się.

    Kolejną sekcją w pliku prometheus.yml jest scrape_configs, Jest ona niezbędna z punktu widzenia logicznego, gdyż zawiera adresy zasobów z których są pobierane dane. Wartość stałej job_name jest dodawana do każdego zassanego szeregu czasowego pobranego z tej konfiguracji jako etykieta 'job=prometheus-1'. Opcja targets podaje adres z pod którego należy czytać informacje. W ten wbudowany sposób możemy automatycznie nadzorować samego PROMETHEUS-a mając z pierwszej ręki informacje o jego statusie. Analogicznie do powyższych ustawień w tej sekcji pojawią się inne maszyny, aplikacje, usługi, których stan będziemy chcieli mieć pod stałą kontrolą.

Opracowane na podstawie:


PROMETHEUS (instalacja)
MONITORING infrastruktury IT