Event log to… „wielki śmietnik” pełen mnóstwa ciekawych informacji. Problemem jest tylko wygrzebanie istotnej informacji.

Potrzebowałem np. sprawdzić, kto logował się interaktywnie do sysytemu w ciągu ostatnich 24 godzin. W tym celu stworzyłem „Custom View”, a w nim zbudowałem warunki filtrujące. To nie było trudne, bo event id dla zdarzenia logowanie to 4624. Problem tylko w tym, że w tym zdarzeniu, w EventData znajduje się pole Logon Type i za logowanie interaktywne odpowiada Logon Type równy 3. Ponieważ jednak każde zdarzenie ma nieco inne właściwości, to nie można wybrać Logon Type w kreatorze.

Na szczęście Event Viewer bazuje na XML i można zbudować w edytorze swoje własne zapytanie, które u mnie wyglądało mniej więcej tak:

<QueryList>
 <Query Id="0" Path="Security">
 <Select Path="Security">*[System[(EventID=4624) and TimeCreated[timediff(@SystemTime) &lt;= 86400000]]]</Select>
 <Select Path="Security">*[EventData[(LogonType=3)]]</Select>
 </Query>
</QueryList>

Wprawdzie po modyfikacji XML traci się możliwość wyklikiwania w tym widoku czegokolwiek z poziomu kreatora, ale to na tyle proste sprawy, że ponowne wyklikanie idzie dość szybko.

Osobiście jednak preferuję skrypt, każdorazowe klikanie, wklejanie XML, to nie dla mnie.

Można więc włożyć powyższy XML do cmdletu Get-WinEvent i …. gotowe. W przykładzie poniżej wybieram tylko 3 ostatnie logowania, ale śmiało można brać wszystkie:

$xmlQuery = @'
<QueryList>
 <Query Id="0" Path="Security">
 <Select Path="Security">*[System[(EventID=4624) and TimeCreated[timediff(@SystemTime) &lt;= 86400000]]]</Select>
 <Select Path="Security">*[EventData[(LogonType=3)]]</Select>
 </Query>
</QueryList>
'@
Get-WinEvent -FilterXML $xmlQuery -MaxEvents 3 | ft -wrap

Zacznijmy od tego, co to znaczy, że port jest otwarty? Dla mnie to sytuacja kiedy jestem w stanie podłączyć sie z zewnątrz do usługi nasłuchującej na tym porcie. Ponieważ port można zamykać lub odfiltrowywać na różnym poziomie (lokalny firewall, firewall na routerze itp.), to właściwie pytanie należałoby doprezycować. Czy port jest otwarty dla połączenia przychodzącego z x.y.z?

Dlatego nic lepiej nie sprawdzi otwartości portu, jak bezpośrednie połączenie z wybranej zewnętrznej maszyny.

Dla Windows:

W powershellu wykonaj

Test-NetConnection -computer <adres_serwera_docelowego> -port <numer portu>

Dla Linux/Unix

W shellu wykonaj:

telnet <adres_serwera_docelowego> <port>

Jeśli telnet byłby niedostępny skorzystaj z nmap lub zainstaluj telneta

dnf install telnet

No i co tu poradzić? Połączenia do bazy danych czasami się udają, ale nawet wtedy po krótkiej chwili sesja jest zabijana i można znaleźć komunikaty

WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit,                      because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

edb-psql: error: FATAL:  the database system is in recovery mode

Zwykle pierwszym dobrym krokiem, kiedy chce się zobaczyć coś więcej od środka, jest analiza zapisów w logu systemowym. Znajdziesz je w /var/lib/edb/as13/data/logs. Log pełen był zapisów w postaci: Czytaj dalej »

Na każdym systemie są dobrzy admini i źli użytkownicy. Użytkownicy (bo przecież nie admini) mogą uruchomić polecenie, które zablokuje innych użytkowników lub skonsumuje zbyt wiele zasobów. Co w takim przypadku robić?

1. Zidentyfikuj użytkownika – rozbójnika

Czasami identyfikacja nie jest łatwa, ale jeśli np. źródłem informacji o awarii jest przeciążony procesor, to taką identyfikację można rozpocząć na poziomie OS. Wyszukaj po prostu procesu, który konsumuje dużo CPU. Mająć PID procesu, można odszukać połączenie po stronie PG:

select * from pg_stat_activity where pid=XXX;

Tak dowiesz się między innymi, kiedy rozpoczęło się połączenie, transakcja, ostatnie zapytanie. Zobaczysz stan transakcji (np „idle transaction”, czyli w trakcie transakcji użytkownik poszedł na kawę), aplikację, serwer, nazwę użyszkodnika itp.

2. Spróbuj zakończyć aktualnie wykonywane zadanie

Jeśli przyczyną problemów jest intensywnie pracujące zapytanie, to można spróbować brutalnie je przerwać. Nie spowoduje to rozłączenia użytkownika:

select pg_cancel_backend(XXX);

3. Zamknij połączenie/sesję

Jeśli problem nadal występuje (np. użytkownik już nic nie robi, ale wcześniej założone blokady nadal uniemożliwiają pracę innym użytkownikom), to przerwij sesję zwalniając wszystkie zarezerwowane dla niej zasoby:

select pg_terminate_backend(XXX);

Jeśli tylko użyszkodnik został poprawnie zidentyfikowany w kroku (1), to ostatnie polecenie pomoże. Jeśli nie pomogło, to… no cóż… zabiliśmy kogoś innego przez pomyłkę… sorry

Zakładając, że PEM został zainstalowany już podczas wstępnej instalacji EDB, to w celu uruchomienia tego narzędzia wystarczy uruchomić skrypt konfiguracyjny:

/usr/edb/pem/bin/configure-pem-server.sh

Skrypt grzecznie pyta o wszelkie opcje konfiguracyjne. Na moim testowym serwerze wyglądało to tak: Czytaj dalej »

Aby skonfigurować Profilera w pierwszej kolejności należy zmodyfikować opcję shared_preload_libraries w postgresql.conf. Modyfikacja polega na dodaniu $libdir/sql-profiler,$libdir/index_advisor

Niestety ta modyfikacja wymaga wykonania restartu serwera

pg_ctl restart

Po restarcie można skontrolować ustawienie z posiomu psql:

edb=# select name, setting from pg_settings where name = 'shared_preload_libraries';
 name | setting
--------------------------+----------------------------------------------------------------------------------------------
 shared_preload_libraries | $libdir/dbms_pipe,$libdir/edb_gen,$libdir/dbms_aq,$libdir/sql-profiler,$libdir/index_advisor
(1 rows)

Kolejny krok, to  uruchomienie skryptów, które konfigurują profilera (i przy okazji index advisora)

edb-psql -f /usr/edb/as13/share/contrib/sql-profiler.sql edb
 edb-psql -f /usr/edb/as13/share/contrib/index_advisor.sql

Teraz można już przejść do PEM. W wersji 13 Profiler znajduje się w Tools >> Server >> SQL Profiler. Po utworzeniu sesji profilera od razy i prawie na żywo można ją obserwować. Prawie na żywo, bo żeby zobaczyć nowe przechwycone polecenia należy kliknąć „Refresh”. Narzędzie pozwala analizować zapytania użytkowników, czas trwania i obciążenie generowane przez te zapytania, a nawet podejrzeć wykorzystane plany zapytań:

Do instalacji PostgreSQL EDB na konkretnej wersji konkretnego systemu operacyjnego trzeba używać odpowiednich paczek instalacyjnych i uruchamiać je w odpowiedniej kolejności z dobrze dobranymi parametrami. To bywa kłopotliwe.

Na szczęście EDB udostępnia stronę, na której wystarczy wybrać żądane parametry instalacji, a sam skrypt instalacyjny zostanie wygenerowany automatycznie. Np. tak wygląda instalacja na Red Hat 8:

# Install the repository configuration
dnf -y install https://yum.enterprisedb.com/edbrepos/edb-repo-latest.noarch.rpm

# Replace 'USERNAME:PASSWORD' below with your username and password for the EDB repositories
# Visit https://www.enterprisedb.com/user to get your username and password
sed -i "s@<username>:<password>@USERNAME:PASSWORD@" /etc/yum.repos.d/edb.repo

# Install EPEL repository
dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

# Enable the codeready-builder-for-rhel-8-*-rpms repository since EPEL packages may depend on packages from it
ARCH=$( /bin/arch )
subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms"

# Disable the built-in PostgreSQL module:
dnf -qy module disable postgresql

# Install selected packages
dnf -y install edb-as13-server edb-pem

# Initialize Database cluster
PGSETUP_INITDB_OPTIONS="-E UTF-8" /usr/edb/as13/bin/edb-as-13-setup initdb

# Start Database server
systemctl start edb-as-13

# Connect to the database server
# sudo su - enterprisedb
# psql postgres

# Configure PEM
/usr/edb/pem/bin/configure-pem-server.sh

# You can now connect to PEM at https://127.0.0.1:8443/pem

Oto link do strony https://repos.enterprisedb.com/

Podczas instalacji EDB jest potrzebna nazwa użytkownika i haslo, jakie otrzymuje się po rejestracji w EDB. Te dane można odczytać z tej strony:

https://www.enterprisedb.com/user/