Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu SNMP

Serwer RHQ może monitorować Apache, ale do uzyskania informacji o wirtualnych serwerach wy,aga instalacji modułu SNMP. Umożliwi to agentowi monitorującemu pobieranie tych informacji bezpośrednio z serwera Apache, bez potrzeby analizy plików konfiguracyjnych.

Pozostałe wpisy z tej serii to:

Aby mieć możliwość instalacji tego modułu trzeba spełnić kilka warunków:

  • Apache musi być skompilowany z obsługą modułów
  • należy skompilować moduł lub użyć plików binarnych oraz zainstalować w ramach serwera Apache
  • należy odpowiednio skonfigurować serwer tak, aby z niego korzystał

Informacje skąd można pobrać pliki źródłowe można znaleźć we wpisie: Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu Response Time.

Po dekompresji pliku connector-apache.zip pliki modułu można znaleźć w katalogu apache-snmp. Tutaj również można naleźć dwa katalogi: ze wersjami binarnymi pakietów oraz ze źródłami. Tym razem jednak mamy w źródłach skompilowane moduły dla różnych wersji serwera Apache oraz dla architektur intelowskich 32 i 64 bitowych.

Kompilacje ze źródeł jest opisana w pliku apache-snmp/sources/README.txt, w praktyce powinno wystarczyć wywołanie polecenia build_apache_snmp.sh.

$ cd apache-snmp/sources
$ ./build_apache_snmp.sh 2.0 /usr/bin/apxs2

Jednak z moim przypadku kompilacja się nie powiadała. Na szczęście w tym przypadku są dostępne już skompilowane wersje modułów z których można skorzystać.

Czyli trzeba moduły rozkompresować:

$ cd apache-snmp/binaries
$ unzip snmp_module-x64-linux-apache2.2.zip

Zostanie utworzony katalogu snmp_module_2.2 a w nim niezbędne pliki konfiguracyjne oraz z modułami. Moduły dla serwera Apache znajdują się w katalogu module, czyli kopiujemy je teraz do odpowiedniej lokalizacji:

# cd snmp_module_2.2
# mkdir -p /usr/local/lib/apache2/modules
# cp module/*.so /usr/local/lib/apache2/modules/

Kopiujemy plik konfiguracyjny modułu:

# mkdir -p /etc/apache2/snmpd/conf
# cp conf/snmpd.conf /etc/apache2/snmpd/conf

W domyślnej konfiguracji moduł SNMP nasłuchuje na przychodzące połączenia od klientów na porcie 1610 na wszystkich interfejsach sieciowych. Ponieważ w naszym przypadku klientem będzie agent monitorujący działający na maszynie lokalnej, można otworzyć jedynie ten port na interfejsie localhost. Czyli należy w pliku /etc/apache2/snmpd/conf/snmpd.conf zmienić wpis agentaddress na taki:

34
agentaddress 1610@127.0.0.1

Należy jeszcze utworzyć specjalny katalog na pliki tworzone przez moduł:

# mkdir -p /var/lib/apache2/snmpd/var

Tworzymy plik /etc/apache2/mods-available/snmpd.load ładujący moduł SNMP do serwera Apache:

1
2
LoadModule snmpcommon_module /usr/local/lib/apache2/modules/libsnmpcommon.so
LoadModule snmpagt_module /usr/local/lib/apache2/modules/libsnmpmonagt.so

Teraz tworzymy plik konfigurujący moduł /etc/apache2/mods-available/snmpd.conf:

1
2
SNMPConf /etc/apache2/snmpd/conf
SNMPVar /var/lib/apache2/snmpd/var

Ostatnim krokiem będzie włączenie modułu:

# a2enmod snmpd

Aby moduł SNMP działał poprawnie, muszą zostać precypitynie zdefiniowane nazwy serwerów wirtualnych. W nazwie musi znaleźć się nie tylko nazwa tego serwera, ale także port na którym serwer Apache będzie nasłuchiwał. Czyli odpowiedni wpis w definicji serwera wirtualnego musi mieć następującą postać:

1
2
3
4
<VirtualHost *:80>
        ServerName blog.stelmisoft.pl:80
        ....
</VirtualHost>

Teraz pozostaje restart serwera Apache i sprawdzenie czy wszystko zadziała:

# /etc/init.d/apache2 restart

Źródła

Tags: , , , , , ,

Monitorowanie serwera Apache przy użyciu RHQ Server – instalacja modułu Response Time

Serwer RHQ może monitorować Apache, ale uzyskał maksymalną ilość informacji o czasach jego odpowiedzi konieczna jest instalacja dodatkowego modułu Apache Response Time. Moduł ten będzie zapisywał w specjalnym pliku logu dodatkowe informacje pomocne w monitorowaniu.

Pozostałe wpisy z tej serii to:

Aby mieć możliwość instalacji tego modułu trzeba spełnić kilka warunków:

  • Apache musi być skompilowany z obsługą modułów
  • należy skompilować moduł oraz zainstalować w ramach serwera Apache
  • należy odpowiednio skonfigurować serwer tak, aby z niego korzystał

Pozostaje jeszcze jedna kwestia, skąd można pobrać te moduły Znam następujące miejsca:

  • Nie udało mi się znaleźć odpowiedniego poliku w wersjach społecznościowych serwera RHQ czy też Jopr.
  • Są one dostarczane przez Red Hata razem z dystrybucją serwera JON 2.3.1, ale żeby je uzyskać trzeba mieć zawartą odpowiednią umową z Red Hatem. Będą one wtedy znajdować się w pliku connector-apache.zip razem z zainstalowanym agentem. Można także je znaleźć w w tym miejscu: jon-server-2.3.1.GA/jbossas/server/default/deploy/rhq.ear.rej/rhq-downloads/connectors/connector-apache.zip.
  • Bardzo możliwe, ze moduły te są zawarte w produkcie SpringSource ERS, ale nie sprawdzałem tego

Ja pobrałem wersje dystrybuowaną wraz z serwerem JON 2.3.1. W dostarczanych źródłach nie ma niestety informacji na jakiej licencji są one rozprowadzane.

Kompilacja modułu mod_rt.so

Po rozpakowaniu pliku connector-apache.zip pliki tego modułu będą się znajdowały się w katalogu apache-rt. Wewnątrz tego katalogu możemy znaleźć katalog z plikami binarnymi modułu przeznaczonymi dla Apache 2 i chyba dla w wersji dla Windowsa (chyba to dlatego, że sam moduł ma rozszerzeniowy so). W związku z tym, trzeba będzie skompilować ten moduł i ręcznie go zainstalować w ramach serwera Apache.

Pierwszym krokiem będzie instalacja odpowiednich dodatkowych pakietów, niezbędnych do przeprowadzenia kompilacji:

aptitude install apache2-dev gcc autoconf automake

Teraz nie pozostaje nic innego jak skompilować moduł poprzez wywołanie skryptu build_apache_module.sh. Jako ego parametry podajemy wersję serwera Apache dla którego tworzymy moduły oraz ścieżkę dostępu do polecenia apxs.

$ cd apache-rt/sources
$ ./build_apache_module.sh 2.x /usr/bin/apxs2

Po kompilacji moduł można znaleźć w tym miejscu: apache2.x/.libs/mod_rt.so.

Instalacja modułu mod_rt.so w serwerze Apache

Moduły Apache, które są instalowane z pakietów znajdują się w katalogu /usr/lib/apache2/modules. Można również tam umieścić skompilowany moduł i korzystać z niego tak i z innych modułów serwera. Ja proponuję jednak umieść ten moduł w wydzielonym katalogu /usr/local/lib/apache2/modules. Myślę, że lepiej nie mieszać ze sobą plików pochodzących z pakietów i kompilowanych ze źródeł samodzielnie.

# mkdir -p /usr/local/lib/apache2/modules
# cp apache2.x/.libs/mod_rt.so /usr/local/lib/apache2/modules

Teraz plik ładujący moduł /etc/apache2/mods-available/rt.load:

1
LoadModule  rt_module  /usr/local/lib/apache2/modules/mod_rt.so

Plik z konfiguracją modułu /etc/apache2/mods-available/rt.conf:

1
LogFormat  "%S"  rt_log

I włączenie modułu w serwerze Apache:

# a2enmod rt

Pozostaje teraz jeszcze skonfigurowanie wszystkich serwerów wirtualnych tak, aby logowały dodatkowe informacje przy użyciu tego modułu. Należy w tym celu dodać w w definicji każdego serwera następujący wpis:

1
2
3
4
5
6
<VirtualHost *:80>

        .......
        CustomLog  /var/log/apache2/access.NAZWA_SERWERA_rt.log rt_log

</VirtualHost>

W podanym pliku będą zapisywane informacje o czasach odpowiedzi, które potem zostaną odpowiednio zinterpretowane przez serwer RHQ. Należy dla każdego serwera zdefiniować oddzielny plik. Będzie on nam potrzeby podczas konfiguracji serwera RHQ pod koniec wpisu.

Teraz nie pozostaje nic innego jak zrestartować serwer i sprawdzić powiedzie się jego uruchomienie i czy informacje są odkładane we wskazanych przez nas plikach.

Źródła

Tags: , , , , , ,

Automatyzacja wykonywania kopii bezpieczeństwa przy użyciu duply i duplicity

We wpisie Tworzenie kopii zapasowej plików przy użyciu aplikacji duplicity oraz duply opisałem, w jaki sposób skonfigurować aplikację duplicity wraz ze skryptem duply w celu wykonywania kopii zapasowych. Chciałbym teraz to trochę uszczegółowić, pod kątem automatycznego wykonywania kopii zapasowej.

Zakładam, że posiadasz już skonfigurowaną aplikację duply i możesz spokojnie za jej pomocą zrobić kopię wybranych plików. Teraz czas aby to zautomatyzować przy zachowaniu takich warunków:

  • kopia zapasowa ma być wykonywana raz dziennie (przyrostowa)
  • raz w tygodniu ma zostać uruchomione robienie pełnej kopii bezpieczeństwa
  • informacje z polecenia duply i duplicty powinny być zapisane w jakimś logu
  • chcemy zostawić sobie tylko dwa najnowsze pełne backupy

Więc do dzieła :).

Na początek zacznijmy od ostatniego punktu: zostawiamy tylko dwie ostatnie kopie bezpieczeństwa. Za takie zachowanie odpowiada definicja zmiennej MAX_FULL_BACKUPS w pliku conf definiującym dany profil duply:

52
53
54
55
# Number of full backups to keep. Used for the "purge-full" command.
# See duplicity man page, action "remove-all-but-n-full".
# defaults to 1, if not set
MAX_FULL_BACKUPS=2

Ustawienie tej wartości na 2 powoduje zostawienie tylko dwóch ostatnich pełnych kopii bezpieczeństwa (oczywiście, wraz z przyrostowymi backupami).

Co warto zauważyć, stare kopie bezpieczeństwa nie zostaną automatycznie usunięte podczas robienia kopii. Należy powołać polecenie duply odpowiednim parametrem, aby zostały one usunięte:

# duply PROFIL purge-full --force

Wywołanie samego polecenia purge-full spowoduje wyświetlenie informacji o tym co ma zostać usunięte, a dodanie do tego jeszcze przełącznika --force spowoduje usunięcie starych plików.

Teraz czas na zdefiniowanie lokalizacji, gdzie będą zapisywane logi z tworzenia kopii bezpieczeństwa. Załóżmy, że mają one znaleźć się w katalogu /var/log/duply, więc:

# mkdir -p /var/log/duply

Ostatnim krokiem będzie poinformowanie aplikacji cron kiedy ma uruchomić odpowiednie skrypty. Można to zrobić poprzez odpowiednią modyfikację pliku /etc/crontab lub też dodając nowy plik z definicją do katalogu /etc/cron.d.

Wybierzmy drugą opcję, czyli należy utworzyć plik /etc/cron.d/duply o takiej zawartości:

1
2
3
4
5
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

10 2 * * 0      root    (duply PROFIL full && duply system_backup purge-full --force; duply system_backup status) 2>&1 | tee /var/log/duply/duply-$(date +\%Y\%m\%d-\%H\%M\%S).log
10 2 * * 1-6    root    (duply PROFIL backup; duply system_backup status) 2>&1 | tee /var/log/duply/duply-$(date +\%Y\%m\%d-\%H\%M\%S).log

Oto co jest zdefiniowane:

  • definicja zmiennych środowiskowych używanych podczas wywoływania skryptów, ważne jest poprawne zdefiniowanie zmiennej PATH
  • linia 4 – definicja wywołania robienia pełnej kopii bezpieczeństwa, będzie ona wykonywana w każdą niedziele o godzinie 2:10, najpierw zostanie wykonana pełna kopia, następnie zostaną usunięte stare kopie bezpieczeństwa, zostanie wypisany status archiwum i to wszystko zostanie zapisane do pliku /var/log/duply/duply-DATA-GODZINA.log, gdzie DATA i GODZINA to odpowiednio data i godzina rozpoczęcia kopii bezpieczeństwa
  • linia 5 – wykonanie przyrostowej kopii bezpieczeństwa w każdy dzień tygodnia (poza niedzielą) o godzinie 2:10, następnie statusu archiwum, i podobnie zapisanie tych informacji w logu.

Od tej pory kopie bezpieczeństwa powinny wykonywać się automatycznie o zadanych porach.

Źródła

Tags: , , , ,

Monitorowanie bazy danych MySQL przy użyciu RHQ Server

Jedną z usług jakie oferuje system monitorujący RHQ Server jest monitorowanie bazy danych MySQL. Niestety, ta baza danych nie jest (a przynajmniej u mnie nie została) wykrywana automatycznie przez agenta monitorującego. Na szczęście dodanie jej obsługi nie jest bardzo kłopotliwe.

Pierwszym krokiem powinno być wybranie serwera (platformy) na której znajduje się baza danych (oczywiście, musi tam być również wcześniej zainstalowany i działający agent). Następnie wybieramy zakładkę INVENTORY->OVERVIEW. Strona ta wyświetli listę monitorowanych serwerów. Na samym dole znajduje się lista rozwijalna o nazwie Manually Add z której wybieramy serwer MySql.

RHQ - Dodanie bazy danych MySql

RHQ - Dodanie bazy danych MySql

Zostanie wyświetlona strona, na której będzie można zdefiniować potrzebne parametry do połączenia.

RHQ - Konfiguracja połączenia z MySQL

RHQ - Konfiguracja połączenia z MySQL

Trzeba podać następujące parametry definiujące połączenie:

  • listen host – numer IP lub nazwa komputera na którym działa MySql
  • listen port – port, na którym nasłuchuje baza danych
  • database name – nazwa bazy danych z którą należy się połączyć
  • JDBC driver class – sterownik JDBC
  • role name – nazwa użytkownika użytego do połączenia
  • role password – hasło użytkownika

Po zatwierdzeniu opcji monitorowanie powinno działać. Niestety, wtyczka ta jest dosyć uboga, ciągle znajduje się ona w wazie eksperymentalnej i nie udostępnia dużej ilości opcji.

Źródła

Tags: , , , , ,

Instalacja agenta monitorującego RHQ

Po zainstalowaniu i skonfigurowaniu serwera RHQ jest już dostępna cała infrastruktura potrzebna do monitorowania i zarządzania systemami. Brakuje jednak ciągle systemu, którym można zarządzać. Aby włączyć możliwość monitorowania danego systemu, trzeba skonfigurować agenta monitorującego.

Instalację agenta pokażę na przykładzie systemu operacyjnego RHEL 5.5 oraz Debian Lenny. W praktyce podobnie będzie wyglądał na każdym systemie Linuksowym, będzie tylko trzeba odpowiednio dostosować definicje ścieżek dostępu.

Instalacja agenta

Serwer RHQ zawiera instalacje agenta monitorującego. Można ją pobrać bezpośrednio ze strony serwera, aby się na nią dostać należy z menu wybrać pozycję Administration->Downloads. Na stronie która się pojawi będzie istniał link pozwalający na pobranie agent oraz krótka instrukcja jak go należy zainstalować.. Należy go pobrać na system na którym ma zostać zainstalowany.

RHQ Server: pobranie agenta monitorującego

RHQ Server: pobranie agenta monitorującego

Po pobraniu agenta należy z poziomu użytkownika root wykonać następujące polecenie:

# java -jar rhq-enterprise-agent-1.4.0-SNAPSHOT.jar --install=/opt

Spowoduje to instalację agenta w podanym katalogu, w przykładzie do katalogu /opt. W katalogu tym pojawi się katalog z agentem: /opt/rhq-agent.

Konfiguracja agenta

Przed uruchomieniem aplikacji należy skonfigurować jeszcze odpowiednie zmienne środowiskowe. Znajdują się one w pliku /opt/rhq-agent/bin/rhq-agent-env.sh.

  • konfiguracja katalogu domowego agenta:
    25
    RHQ_AGENT_HOME="/opt/rhq-agent"
  • konfiguracja katalogu domowego Javy:
    • w systemie RHEL:
      33
      RHQ_AGENT_JAVA_HOME="/etc/alternatives/jre"
    • w systemie Debian:
      33
      RHQ_AGENT_JAVA_HOME="/usr/lib/jvm/java-6-sun"

Po zapisaniu zmian można już uruchomić agenta monitorującego przy użyciu polecenia /opt/rhq-agent/bin/rhq-agent.sh i przystąpić do jego konfiguracji

# /opt/rhq-agent/bin/rhq-agent.sh
RHQ 1.4.0-SNAPSHOT [5305] (null)
Answer the following questions to setup this RHQ Agent instance.
- After each prompt, a default value will appear in square brackets.
  If you press the ENTER key without providing any value,
  the new preference value will be set to that default value.
- If you wish to rely on the system internal default value and
  not define any preference value, enter '!*'.
- If you wish to stop before finishing all the questions but still
  retain those preferences you already set, enter '!+'.
- If you wish to cancel before finishing all the questions and revert
  all preferences back to their original values, enter '!-'.
- If you need help for a particular preference, enter '!?'.

Agent Name [jboss] :

Przy pierwszym uruchomieniu agent zada cztery pytania służące do jego konfiguracji:

  • Agent Name – nazwa agenta, powinna być unikalna w ramach wszystkich monitorowanych maszyn
  • Agent Hostname or IP Address – adres IP, na którym agent ma używać aby nasłuchiwać na połączenia ze strony serwera
  • Agent Port – port, na którym agent ma nasłuchiwać na połączenia
  • RHQ Server Hostname or IP Address – nazwa serwera RHQ, do którego ma się przyłączyć agent
  • RHQ Server Port – port, który ma być użyty do połączenia

Po podaniu tych informacji agent połączy się z serwerem RHQ, pobierze dostępne wtyczki, przeprowadzi automatyczne wykrywanie komponentów systemu i wyśle te informacje do serwera RHQ.

Po zakończeniu tych operacji znajdziemy się w trybie interaktywnym agenta, będzie można mu wydawać polecenia, konfigurować go. Więcej informacji można otrzymać wpisując słowo help.

Konfiguracja serwera RHQ

Poprawna konfiguracja agenta nie oznacza, że informacje z niego są przekazywane do serwera RHQ. Musimy jeszcze odpowiednie zasoby zaimportować do serwera RHQ. Jeżeli agent poprawnie zostanie skonfigurowany, to powinien się pojawić jako nowy zasób:

RHQ: Auto-Discovery

RHQ: Auto-Discovery

Wystarczy zaznaczyć zasoby i wybrać przycisk Import. Od tego momentu serwer i jego usługi będą monitorowane.

Może istnieć jeszcze potrzeba dodatkowej konfiguracji połączeń z pomiędzy agentem i poszczególnymi serwerami (np. konfiguracja bazy danych Postgres, serwera JBoss, Tomcat).

Automatyczne uruchamianie agenta

Jeżeli już mamy skonfigurowanego agenta, nie pozostaje zrobić nic innego, jak skonfigurować go tak, aby uruchamiał się automatycznie podczas startu systemu.

W katalogu /opt/rhq-agent/bin znajduje się skrypt rhq-agent-wrapper.sh pozwala na zarządzanie agentem. Dostępne akcje można łatwo poznać wywołując go bez żadnych parametrów:

# /opt/rhq-agent/bin/rhq-agent-wrapper.sh
Usage: /opt/rhq-agent/bin/rhq-agent-wrapper.sh { start | stop | kill | restart | status }

Czyli mamy do czynienia ze zwykły skryptem w standardzie System V, a skoro tak to można go bezpośrednio użyć w celu uruchomienia agenta.

Konfiguracja automatycznego startu sprowadza się do:

  • utworzenie odpowiedniego linku w katalogu /etc/init.d (nie należy kopiować tego skryptu, wymaga on do działania dostępu do pliku rhq-agent-env.sh):
    # ln -s /opt/rhq-agent/bin/rhq-agent-wrapper.sh /etc/init.d/rhq-agent
  • konfiguracja automatycznego uruchamiania skryptu:
    • w systemie RHEL:
      # chkconfig rhq-agent on
    • w systemie Debian
      # update-rc.d rhq-agent defaults 90 10
      update-rc.d: warning: /etc/init.d/rhq-agent missing LSB information
      update-rc.d: see <http ://wiki.debian.org/LSBInitScripts>
       Adding system startup for /etc/init.d/rhq-agent ...
         /etc/rc0.d/K10rhq-agent -> ../init.d/rhq-agent
         /etc/rc1.d/K10rhq-agent -> ../init.d/rhq-agent
         /etc/rc6.d/K10rhq-agent -> ../init.d/rhq-agent
         /etc/rc2.d/S90rhq-agent -> ../init.d/rhq-agent
         /etc/rc3.d/S90rhq-agent -> ../init.d/rhq-agent
         /etc/rc4.d/S90rhq-agent -> ../init.d/rhq-agent
         /etc/rc5.d/S90rhq-agent -> ../init.d/rhq-agent

  • uruchomienie agenta:
    # /etc/init.d/rhq-agent start

I to będzie wszystko.

Źródła

Tags: , , , , , ,