To narzędzie open source do monitoringu baz danych PostgreSQL, MySQL, MongoDB i pochodnych. Oparte na Grafanie, VictoriaMetrics, ClickHouse, alertmanager, PostgreSQL i innych.

Składa się z części serwerowej (pmm-server) i klienta instalowanego na serwerze bazodanowym (pmm-client). Klient zbiera informacje o systemie operacyjnym i bazie danych za pomocą eksporterów zainstalowanych lokalnie na serwerze db. W przypadku, kiedy nie chcemy lub nie możemy zainstalować klienta, np. RDS, część serwerowa przejmuje odpowiedzialność za zbieranie informacji. Dla RDS za pomocą API pobiera informacje o systemie operacyjnym i klastrze postgresa lub w przypadku klasycznych implementacji może łączyć się zdalnie do postgresa i zbierać dane do monitoringu.

Instalacja serwera jest bardzo prosta, można ją wykonać jednym poleceniem, jako root lub z uprawnieniami roota. Na serwerze 4 lub 5 wykonujemy:

curl -fsSL https://www.percona.com/get/pmm | /bin/bash

Skrypt sam wykrywa system operacyjny, instaluje dockera, pobiera obraz dla dockera i uruchamia PMM.

Starting PMM server...
Created PMM Data Volume: pmm-data
Created PMM Server: pmm-server
    Use the following command if you ever need to update your container by hand:
    docker run -d -p 443:443 --volumes-from pmm-data --name pmm-server --restart always percona/pmm-server:2


PMM Server has been successfully setup on this system!

You can access your new server using one of the following web addresses:
    https://172.17.0.1:443/
    https://10.0.2.15:443/
    https://192.168.56.15:443/
    https://127.0.0.1:443/

The default username is 'admin' and the password is 'admin' :)
Note: Some browsers may not trust the default SSL certificate when you first open one of the urls above.
If this is the case, Chrome users may want to type 'thisisunsafe' to bypass the warning.

Po zainstalowaniu możemy otworzyć konsolę PMM w przeglądarce, używając użytkownika i hasła admin/admin, przy pierwszym logowaniu zmieniamy hasło.

Od razu po instalacji monitorowana będzie jedna instancja postgresa, ponieważ PMM również stoi na Postgresie i monitoruje też sam siebie.

Kolejnym krokiem będzie instalacja klienta na serwerach z postgresem.

Pobranie i instalacja repozytorium i pmm-clienta na Ubuntu

# pobieramy informacje o repozytorium
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb


# instalacja repozytorium
sudo dpkg -i percona-release_latest.generic_all.deb

Aktualizacja informacji o paczkach dostępnych w repozytoriach i instalacja klienta

sudo apt update


sudo apt install -y pmm2-client

Pobranie i instalacja repozytorium i pmm-clienta na systemach z rodziny Red Hat

# pobieramy informacje o repozytorium
sudo dnf install -y \
https://repo.percona.com/yum/percona-release-latest.noarch.rpm


# instalacja klienta
sudo dnf install -y pmm2-client

Sprawdzamy zainstalowaną wersję PMM serwera i klientów na wszystkich serwerach, musi być wszędzie taka sama. Następnie możemy zarejestrować klienta na serwerze. W miejsce X.X.X.X wstawiamy IP serwera:

pmm-admin --version


sudo pmm-admin config --server-insecure-tls --server-url=https://admin:haslo@X.X.X.X:443 <adresserveraklienta> generic(lub container) <nazwa>

sudo pmm-admin config --server-insecure-tls --server-url=https://admin:qwe123@192.168.0.23:443 192.168.0.50 generic pg2

Przed dodaniem postgresa do monitoringu musimy stworzyć użytkownika z odpowiednimi uprawnieniami.

CREATE USER pmm WITH PASSWORD '******';


grant pg_monitor to pmm;

Następnie dodajemy odpowiednie wpisy do pg_hba.conf dla użytkownika 'pmm', przeładowujemy konfigurację i sprawdzamy, czy użytkownik jest pytany o hasło przy logowaniu.

# na serwerze bazodanowym
# edycja pg_hba
vi /postgres/data/pg_hba.conf
host all pmm <adres_ip_serwera_PMM>/32 md5
# przeładowanie konfiguracji
psql -c "select pg_reload_conf()"


# test połączenia z serwera z PMM
psql -h <adres_ip_serwera_PMM> -U pmm postgres

Ostatnim krokiem będzie zarejestrowanie klienta na serwerze, co automatycznie rozpocznie zbieranie danych z postgresa i systemu operacyjnego.

# z serwera bazodanowego z zainstalowanym pmm-clientem
postgres@ubuntu:/etc/postgresql/15/main$ pmm-admin add postgresql \
--username=pmm \
--password=<haslo_uzytkownika_pmm> \
--server-url=https://admin:haslo@<adres_ip_serwera_PMM>:443 \
--server-insecure-tls \
--service-name=nazwa \
--query-source="pgstatmonitor"

Po zarejestrowaniu klienta i serwisu dla postgresa PMM automatycznie zacznie monitorować setki parametrów. Na stronie głównej mamy przegląd naszego środowiska, gdzie od razu po otworzeniu strony możemy zobaczyć, które serwery monitoring wykrywa jako potencjalnie problematyczne.

Pulpity z bardziej szczegółowymi informacjami znajdziemy w menu po lewej lub klikając na "Home Dashboard" na górze ekranu. Z odpowiednich kategorii wybieramy interesujące nas widoki, sortujemy według serwerów lub środowisk, które chcemy sprawdzić, i mamy przegląd informacji o serwerach oraz bazach danych.

Integracja z pg_stat_statements i pg_stat_monitor

Dodając postgresa do monitoringu przez linię poleceń, PMM domyślnie włącza integrację z pg_stat_statements. Jeżeli chcielibyśmy skorzystać z pg_stat_monitor, musimy dodać przełącznik --query-source="pgstatmonitor"

postgres@ubuntu:/etc/postgresql/15/main$ pmm-admin add postgresql \
--username=pmm \
--password=123 \
--server-url=https://admin:haslo@X.X.X.X:443 \
--server-insecure-tls \
--service-name=nazwa \
--query-source="pgstatmonitor"

Dzięki integracji z oboma rozszerzeniami mamy możliwość wygodnej analizy zapytań, z przeglądem ich statystyk. Dla obu rozszerzeń dane są rozłożone w czasie, więc nawet jeżeli korzystamy z pg_stat_statements, możemy śledzić, jak w czasie rozkładały się zapytania, czego nie możemy zrobić z samym rozszerzeniem. Używając pg_stat_monitor, razem z przykładowymi zapytaniami, mamy możliwość sprawdzenia histogramów, listy relacji, z których zapytanie korzystało razem z ich definicją oraz przejrzenia planów wykonania, jeżeli je zbieramy.

Do narzędzia Query Analytics, w którym mamy przegląd zgromadzonych zapytań, możemy przejść z ekranu głównego za pomocą przycisku w prawym górnym rogu:

lub menu znajdującego się po lewej stronie:

Wewnątrz znajdziemy wszystkie zapytania, które były przechwycone przez pg_stat_statements lub pg_stat_monitor, z czasem ich wykonania, częstotliwością oraz liczbą. Dobrą praktyką jest od czasu do czasu wykonywać analizę zapytań. Można polecić trzy kategorie, top X najczęściej wykonywanych zapytań, posortowane przez "Query Count", top X zapytań, których suma czasów wykonania była najdłuższa, sortowane według kolumny "Load" oraz X najdłuższych zapytań w bazie, posortowane przez "Query Time". Często poprawiając te zapytania, możemy znacząco obniżyć obciążenie w bazie danych i jednocześnie poprawić jej wydajność.

Customowe zapytania

Jeżeli jednak brakuje nam jakiegokolwiek parametru, możemy go dodać w bardzo prosty sposób za pomocą "custom queries". Wystarczy, że dodamy brakujące zapytanie w formacie YAML do jednego z katalogów w jednym z poniższych katalogów na serwerze, na którym działa postgres_exporter, lub w kontenerze pmm-server dla postgresa w chmurze, np.rds

ls /usr/local/percona/pmm2/collectors/custom-queries/postgresql
high-resolution  low-resolution  medium-resolution

Aby skorzystać z własnych zapytań do monitoringu baz na RDS, lub gdziekolwiek indziej, gdzie nie mamy dostępu do systemu operacyjnego i nie możemy zainstalować PMM clienta, możemy na serwerze, na którym zainstalowany jest PMM, otworzyć konsolę dla kontenera pmm-server i w ten sam sposób dodać własne zapytania:

sudo docker exec -it pmm-server /bin/bash


ls /usr/local/percona/pmm2/collectors/custom-queries/postgresql
high-resolution  low-resolution  medium-resolution

Katalogi low, medium i high odpowiadają interwałom, w jakim dane zapytanie będzie wykonywane. Znajdziemy je w ustawieniach PMM i możemy ustawić według upodobań.

Przykładowo, do monitorowania konfliktów blokad możemy stworzyć plik w wybranym katalogu, high, medium lub low resolution. Podany poniżej przykład został włączony do postgres_exportera w wersji 3.37 z mojej inicjatywy, jest to projekt z otwartym źródłem, więc każdy może dokonać jakiś zmian i zaproponować ich wdrożenie, o czym nieco informacji na końcu w ramach ciekawostki.

vi /usr/local/percona/pmm2/collectors/custom-queries/postgresql/high-resolution/pg_lock_conflicts.yml


pg_lock_conflicts:
  query: "SELECT blockinga.pid AS blocking_pid, count(*) as count FROM pg_catalog.pg_locks blockedl JOIN pg_stat_activity blockeda ON blockedl.pid = blockeda.pid JOIN pg_catalog.pg_locks blockingl ON(blockingl.transactionid=blockedl.transactionid AND blockedl.pid != blockingl.pid) JOIN pg_stat_activity blockinga ON blockingl.pid = blockinga.pid WHERE NOT blockedl.granted group by blocking_pid"
  metrics:
    - blocking_pid:
        usage: "LABEL"
        description: "PID of blocking session"
    - count:
        usage: "GAUGE"
        description: "Number of blocked sessions"

Dodając niestandardowe zapytania, musimy pamiętać, że każdy skrypt będzie wykonywany co zadany interwał, korzystając z własnego połączenia do postgresa. Im więcej skryptów, tym więcej zapytań. Możemy wpisać kilka zapytań do jednego skryptu, ale musimy mieć pewność, że skrypt zdąży się wykonać w czasie "metric resolution".

W ramach ciekawostki wspomnianej wcześniej, PMM i postgres_exporter to oprogramowanie open source, dlatego zawsze możemy sięgnąć do źródła i dopisać sobie własne zapytania do exportera i podmienić tylko plik wykonywalny postgres_exporter w obrazie "pmm-server" lub dla pmm-agenta na serwerze z bazą danych, co również jest dość proste. A jeżeli uważamy, że jest ono bardzo dobre i mogłoby zostać włączone do projektu, możemy wysłać Pull Request ze swoimi zmianami, a po weryfikacji może zostać włączony do głównego repozytorium.

Do pliku queries.go dopisujemy zapytanie opisane wartością, pod którą nowa metryka pojawi się w PMM.

  "pg_lock_conflicts": {
    {
      semver.MustParseRange(">0.0.0"),
                        `SELECT blockinga.pid AS blocking_pid, count(*) as count
                        FROM pg_catalog.pg_locks blockedl
                        JOIN pg_stat_activity blockeda ON blockedl.pid = blockeda.pid
                        JOIN pg_catalog.pg_locks blockingl ON(blockingl.transactionid=blockedl.transactionid
                          AND blockedl.pid != blockingl.pid)
                        JOIN pg_stat_activity blockinga ON blockingl.pid = blockinga.pid
                        WHERE NOT blockedl.granted
                        group by blocking_pid`,
    },
  },

Do pliku postgres_exporter.go dopisujemy opis zbieranych wartości wraz z ich typem, do dyspozycji mamy LABEL czyli tekst, GAUGE wartość liczbowa parametru, COUNTER licznik, który może tylko rosnąć lub DISCARD, jeżeli danej wartości nie chcemy zwracać w PMM. Każda wartość zwracana przez zapytanie powinna być tutaj uwzględniona.

"pg_lock_conflicts":{
  map[string]ColumnMapping{
  "blocking_pid": {LABEL, "PID of blocking session", nil, nil},
  "count": {GAUGE, "Number of blocked sessions", nil, nil},
  },
 true,
 0,
 },

A następnie skompilować wg instrukcji https://github.com/percona/postgres_exporter/tree/pmm-2.38.0

Konfiguracja monitoringu Patroni na podstawie danych z RestAPI /metrics

PMM umożliwia również dodawanie własnych "exporterów", czyli źródeł danych dla monitoringu. W przypadku Patroni możemy w bardzo prosty sposób wykorzystać jego RestAPI nasłuchujące na porcie 8008, aby rozpocząć zbieranie informacji o klastrze do monitoringu.

Konfiguracja zewnętrznego exportera w PMM ogranicza się do wykonania jednego polecenia na każdym z serwerów Patroni pod warunkiem, że mamy tam już skonfigurowany klienta PMM (usługa pmm-client).

pmm-admin add external --listen-port=8008 --service-name=patroni-szkolenie-pgX

Jako service name podajemy dowolną nazwę, która pozwoli nam na łatwą identyfikację monitorowanego klastra Patroni. Od tego momentu wartości dostępne w RestAPI dla zapytania /metics będą widoczne w PMM.

Aby od razu sobie te informacje zwizualizować, możemy dodać nowy pulpit zawierający widoki dla Patroni, klikając na ikonę "Dashboards", a następnie " + Import",

importując pulpit o numerze identyfikacyjnym 18870. Jest to szablon dostępny na oficjalnych stronach grafany przygotowany właśnie pod RestAPI Patroni

Podajemy nazwę dla importowanego pulpitu oraz wybieramy, gdzie ma zostać zapisany. Może być to dowolny katalog w PMM, najlepiej wybrać ten, który będzie dla nas najwygodniejszy w użyciu. W polu metrics wybieramy "Metrics", powinna być dostępna tylko jedna opcja, jeżeli konfiguracja PMM nie była wcześniej modyfikowana.

Mamy teraz dostęp do pulpitu obrazującego wszystkie wartości z dostępnej z Patroni /metrics, oprócz patroni_xlog_replayed_timestamp, patroni_cluster_unlocked oraz patroni_failsafe_mode_is_active.

Nowy pulpit znajdziemy, klikając na link "Insight / Home Dashboard":

Następnie nawigujemy do katalogu, w którym zapisaliśmy zaimportowany pulpit i klikamy na "PostgreSQL Patroni".