Posts Tagged JBoss

Różnice w konfiguracji pomiędzy profilami all i production w JBoss EAP 5

Paź 24

Posted by Łukasz Stelmach in JBoss AS | Comments off

Serwer aplikacji JBoss EAP 5 zawiera szereg profili, które pozwalają uruchomić rożne jego konfiguracje. Między innymi można znaleźć tam profile all oraz production.

Profil all wspiera klastrowanie i jest przeznaczony do używania podczas tworzenia czy też testowania aplikacji, natomiast profil production jest zoptymalizowany pod typowy serwer produkcyjny. Poniżej znajdzie się opis różnic w konfiguracji obydwóch profili.

Modyfikacje w logowaniu informacji

W wersji production występuje sporo różnic w sposobie logowania informacji przez serwer JBoss:

  • wyłączenie logowania informacji na konsolę
  • włączenie konfiguracji pozwalającej na logowanie asynchronicznie
  • przekierowanie komunikatów z pakietów org.jgroups oraz org.jboss.ha do pliku cluster.log
  • zwiększenie priorytetu logowanych informacji z INFO do WARN

Hot deploy

Zwiększenie czasu skanowania katalogu deploy z 5 na 60 sekund.

Modyfikacje w pliku hdscanner-jboss-beans.xml
all
14
<property name="scanPeriod">5000</property>
production
14
<property name="scanPeriod">60000</property>

Wyłączenie śledzenia połączeń do bazy danych

W profilu production zostaje wyłączone śledzenie otwartych połączeń do bazy danych i ich automatyczne zamykanie:

Modyfikacje w pliku jca-jboss-beans.xml
all
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">true</property>
production
47
48
<!-- Whether to track unclosed connections and close them -->
<property name="debug">false</property>

Generowanie unikalnych identyfikatorów

W usłudze uuid-key-generator.sar zostało zwiększone bezpieczeństwo uzyskiwanych danych w przypadku używania klastrów:

Modyfikacje w pliku uuid-key-generator.sar/META-INF/jboss-service.xml
all
42
43
44
45
46
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended)
<attribute name="SelectHiSql">
   select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE

-->
production
42
43
44
45
<!-- Uncomment to make it cluster-safe: Select current Hi value query (FOR UPDATE is recommended) -->
<attribute name="SelectHiSql">
    select HIGHVALUES from HILOSEQUENCES where SEQUENCENAME='general' FOR UPDATE
</attribute>

Wyłączenie możliwości ładowania klas nie będących ziarnami EJB

Klient RMI ma możliwość ładowania klas bezpośrednio z serwera aplikacji. Dzięki temu nie trzeba razem z klientem dostarczać klas znajdujących się po stronie serwera. Jednakże włączenie tej opcji udostępnia wszystkie wszystkie zasoby znajdujące się na w ramach zmiennej classpath każdemu klientowi, bez możliwości kontroli co on pobiera.

W przypadku profilu production zostaje włączona możliwość ładowania jedynie klas EJB.

Modyfikacje w pliku jboss-service.xml
all
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">true</attribute>
production
160
161
<!-- Should non-EJB .class files be downloadable -->
<attribute name="DownloadServerClasses">false</attribute>

Tags: , , ,

Automatyczne uruchamianie serwera RHQ Server (oraz Jopr) podczas startu systemu.

Cze 21

Posted by Łukasz Stelmach in RHQ/JON | 2 komentarze

W systemie produkcyjnym porządna jest sytuacja, gdy wszystkie potrzebne usługi uruchamiają się automatycznie podczas jego startu oraz korzystają z minimalnych uprawnień jakie można im przydzielić. Serwer RHQ zawiera skrypty uruchomieniowe, które pozwalają go odpowiednio uruchamiać oraz zatrzymywać, nie pozwalają jednak skonfigurować użytkownika, który ma zostać użyty do jego uruchomienia. Serwer do swojego działania nie potrzebuje uprawnień innych niż posiada zwykły użytkownik (przynajmniej w sytuacji, gdy nie używamy wbudowanego agenta).

Konfiguracja systemu

Pierwszym krokiem będzie stworzenie odpowiedniego użytkownika, który zostanie użyty do uruchamiania serwera RHQ. Będzie on się nazywał rhqadmin i można utworzyć go następującym poleceniem:

# useradd -b /opt/rhq-server -d /opt/rhq-server -s /bin/bash rhqadmin

Polecenie powyższe doda nowego użytkownika rhqadmin, skonfiguruje odpowiedni katalog domowy dla niego oraz powłokę domyślną. Nie będzie miał on również skonfigurowanego hasła – nie ma potrzeby aby logował się do systemu.

Pozostaje zmienić uprawnienia do katalogów:

# chown -R rhqadmin.rhqadmin /opt/rhq-server
# chmod -R ug+rw,ug+X,o-rwx rhq-server
# chmod -R ug=rwx,o-rwx rhq-server/bin/*.sh

Utworzenie skryptu startującego RHQ Server

W domyślnej instalacji istnieje skrypt, który pozwoli uruchomić serwer RHQ przy użyciu uprawnień bieżącego użytkownika. Można go znaleźć w tym miejscu: /opt/rhq-server/bin/rhq-server.sh. Bezpośrednio w skrypcie nie ma zaimplementowanej możliwości zmiany użytkownika używanego do jego uruchomienia. Do wyboru są więc dwie możliwości:

  • zmodyfikować skrypt rhq-server.sh tak, aby uruchamiał serwer JBoss korzystając z wybranego użytkownika – to było moje pierwsze podejście, jednak okazało się, że wymaga w praktyce sporo modyfikacji, i jakoś tak do końca nigdy mi to rozwiązanie nie zadziałało do końca poprawnie
  • utworzyć wrapper na skrypt rhq-server.sh, który od razu ten skrypt będzie wykonywał na uprawnieniach wybranego użytkownika – okazuje, że utworzenie tego wrappera jest dosyć prostym rozwiązaniem i co najważniejsze, działa bez kłopotów

Poniższy skrypt należy zapisać w pliku /etc/init.d/rhq-server. Można go dostosować do swoich potrzeb (modyfikując odpowiednio ścieżki dostępu, użytkownika i tak dalej). Jak łatwo zauważyć, skrypt sam w sobie wiele nie robi, po prostu wywołuje skrypt rhq-server.sh modyfikując tylko użytkownika i delegując już resztę roboty do niego. Skrypt doskonały nie jest (w szczególności jeżeli jakieś błędy będą występować), ale działa.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#! /bin/sh
### BEGIN INIT INFO
# Provides:          rhq-server
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: RHQ Server start script
# Description:       Start RHQ Server
### END INIT INFO

PATH=/opt/rhq-server/bin:/sbin:/usr/sbin:/bin:/usr/bin
DESC="Uruchomienie RHQ Server"
NAME=rhq-server
DAEMON=/opt/rhq-server/bin/rhq-server.sh
SCRIPTNAME=/etc/init.d/$NAME
RHQ_USER="rhqadmin"

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

case "$1" in
  'console')
        su - $RHQ_USER -c "$DAEMON console"
        ;;
  'start')
        su - $RHQ_USER -c "$DAEMON start"
        ;;
  'stop')
        su - $RHQ_USER -c "$DAEMON stop"
        ;;
  'kill')
        su - $RHQ_USER -c "$DAEMON kill"
        ;;
  'status')
        su - $RHQ_USER -c "$DAEMON status"
        ;;
  *)
        su - $RHQ_USER -c "$DAEMON usage"
        ;;
esac

Automatyczne uruchamianie skryptu

Ostatnim elementem będzie skonfigurowanie automatycznego uruchamiania serwera w Debianie

# update-rc.d rhq-server defaults 90 10
update-rc.d: warning: /etc/init.d/rhq-server missing LSB information
update-rc.d: see <http ://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/rhq-server ...
   /etc/rc0.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc1.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc6.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc2.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc3.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc4.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc5.d/S90rhq-server -> ../init.d/rhq-server

Tags: , , , , ,

Zatrzymanie i uruchomienie zainstalowanej aplikacji przy użyciu linii poleceń w serwerze JBoss AS

Cze 19

Posted by Łukasz Stelmach in JBoss AS | Comments off

Aplikacje zainstalowane w serwerze JBoss można zarówno zatrzymywać jak i ponownie uruchamiać, bez konieczności ich instalacji.

Odpowiednie akcje można bez trudności znaleźć w np. w konsoli administracyjnej:

Admin Console - kontrola aplikacji

Admin Console - kontrola aplikacji

Odpowiednie akcje pozwalają na zatrzymanie, uruchomienie lub restart aplikacji.

Co jednak zrobić, aby takie same akcje wykonać przy użyciu linii poleceń?

Za zarządzanie serwerem JBoss z linii poleceń odpowiada polecenie twiddle, można je znaleźć w katalogu bin serwera, tam gdzie pliku run.sh. Przy jego pomocy można wykonywać określone akcje na odpowiednich ziarnach.

Pozostaje więc teraz tylko znaleźć ziarna odpowiedzialne za poszczególne akcje i powinno być po sprawie.

Operacja na aplikacjach typu WAR

Aplikacje typu war to aplikacje webowem uruchamiane w ramach kontenera JBoss Web Container (czyli we wbudowanym Tomcacie). Aby taką aplikację zatrzymać czy też wystartować, należy znaleźć tylko odpowiednie ziarno, które za nią stroi. W tym przypadku wystarczy się przyjrzeć zawartości ziaren znajdujących się w grupie jboss.web.deployment.

Można to zrobić albu używając konsoli JMX lub też bezpośrednio przy użyciu polecenie twiddle:

$ twiddle.sh query 'jboss.web.deployment:*'
jboss.web.deployment:war=/ROOT
jboss.web.deployment:war=/admin-console
jboss.web.deployment:war=/jmx-console
jboss.web.deployment:war=/invoker
jboss.web.deployment:war=/juddi

Tym sposobem otrzymamy listę ziaren, które odpowiadają za zarządzaniem poszczególnymi aplikacji. Teraz pozostaje się dowiedzieć, jakich metod można na nich używać:

$ twiddle.sh info 'jboss.web.deployment:war=/ROOT'
Description: Management Bean.
+++ Attributes:
 Name: SecurityManagement
 Type: org.jboss.security.ISecurityManagement
 Access: -w
 Name: PolicyRegistration
 Type: org.jboss.security.authorization.PolicyRegistration
 Access: -w
 Name: Kernel
 Type: org.jboss.kernel.Kernel
 Access: -w
+++ Operations:
 void destroy()
 void start()    
 void stop()
 void create()

Interesujące są dwie metody: start oraz stop. Polecenie, które zatrzyma aplikację:

$ twiddle.sh invoke 'jboss.web.deployment:war=/ROOT' stop

W logach JBossa powinien pojawić się taki komunikat:

15:35:35,665 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/

Uruchomienie aplikacji jest możliwe poprzez taką komendę:

$ twiddle.sh invoke 'jboss.web.deployment:war=/ROOT' start

I w logach można znaleźć informację o uruchomieniu aplikacji:

15:37:20,268 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/

Inne typy aplikacji

Niestety, nie udało mi się znaleźć odpowiednich ziaren dla typów EAR czy RAR. Widać, że takie istnieją, ale nie zachowują się do końca tak jak bym chciał.

Polecenie to wyświetli listę ziaren z grupy jboss.j2ee:

$ twiddle.sh query 'jboss.j2ee:*'

W moim przypadku wyświetlone zostały dwa ziarna które pasowały do aplikacji. Jedno z nich zawierało akcje start oraz stop. I tak wywołanie akcji stop niczego nie zmieniło (aplikacja dalej działała). Wywołanie natomiast akcji start powodowało wyświetlenie komunikatów o zainstalowaniu aplikacji, ale także niczego nie zmieniło w jej działaniu (jak obsługiwała połączenia tak obsługiwała je cały czas).

Metodą, która natomiast zadziałała bez zastrzeżeń, jest wymuszenie odinstalowania aplikacji. Więcej można przeczytać w tym artykule: Zarządzanie instalacją aplikacji w JBoss AS. W skrócie wygląda to tak:

  • usunięcie aplikacji:
    $ twiddle.sh invoke "jboss.system:service=MainDeployer" undeploy "file:/ścieżka/do/pliku/do/instalacji"
  • instalacja aplikacji:
    $ twiddle.sh invoke "jboss.system:service=MainDeployer" deploy "file:/ścieżka/do/pliku/do/instalacji"

Przy takim instalowaniu aplikacji należy jednak pamiętać o dwóch sprawach:

  • jeżeli JBoss ma uruchomioną usługę HDScanner, to jeżeli zostanie odinstalowana aplikacje znajdująca się w katalogu deploy, może ona zostać zaraz zainstalowana ponownie przez tą usługę
  • aplikacje, które nie znajdują się w katalogu deploy nie są automatycznie instalowane podczas startu serwera JBoss, więc trzeba je zainstalować później[/cci]

Źródła

Tags: , , , , ,

Aktualizacja platformy RHQ z wersji 1.3 i 1.4 do wersji 3.0

Cze 13

Posted by Łukasz Stelmach in RHQ/JON | Comments off

Dwa tygodnie temu została wydana wersja 3.0.0.B06 serwera RHQ. Zachciało m się więc sprawdzić, co też w niej słychać. Zamiast jednak pobrać tę wersję ze stron projektu, zapragnąłem skompilować je samodzielnie i zrobić aktualizację używanej przeze mnie wersji serwera 1.4-SNAPSHOT.

Kolejne kroki jakie przedstawię poniżej pozwoliły mi zaktualizować:

  • serwer RHQ wraz z dołączanymi wtyczkami
  • wtyczki do serwera JBoss
  • agentów monitorujących wraz z ich wtyczkami


Na samym początku jeszcze mam jedną uwagę: mogę się założyć, że droga którą wybrałem była jedną z trudniejszych i na pewno istnieje prostszy sposób kompilacji źródeł serwera RHQ i aktualizacji istniejącego już systemu. W moim przypadku zacząłem od kompilacji kodu a następnie po kolei rozwiązywałem problemy jakie się pojawiały w kolejnych krokach. Myślę jednak, że musi istnieć prostsza metoda, więc myślę że zanim zaczniesz realizować kolejne kroki, postaraj się ją najpierw znaleźć, a tutaj wróć w ostateczności :).

Krok 1: przygotowanie środowiska

Pierwszym krokiem będzie przygotowanie środowiska, w którym będzie można skompilować serwer RHQ. W moim przypadku środowisko już miałem wstępnie przygotowane ze względu na kompilację wersji 1.4. Będziemy potrzebowali:

  • Java – zainstalować JDK 6, należy także poprawnie skonfigurować zmienną systemową $JAVA_HOME, która powinna wskazywać na katalog domowy z Javą
  • Maven – zainstalowany w wersji przynajmniej 2.1.x, można pobrać go ze strony http://maven.apache.org/download.html
  • PostgreSQL – zainstalować bazę danych, w wersji przynajmniej 8.3 (ja używałem wersji 8.4)
  • Git – system kontroli wersji

Krok 2: pobranie źródeł

W stosunku do poprzedniej wersji systemu RHQ uległ zmianie używany system kontroli wersji: wersja 1.3/1.4 używa systemu Subversion, aktualna systemu Git. W związku z tym pobranie i aktualizacja źródeł wygląda inaczej. Do aktualnej wersji RHQ zostały także włączone wtyczki pozwalające na zarządzanie serwera aplikacji JBoss, więc nie będzie także potrzeby pobrania osobnych źródeł dla nich.

Pobranie źródeł:

git clone git://git.fedorahosted.org/rhq/rhq.git

Pobranie źródeł trochę potrwa, u mnie zajęły w sumie około 150 MB, z tym że sam katalog git miał rozmiar 50MB.

Możemy także aktualizować źródła przy użyciu tego polecenia (wykonywanego w katalogu z pobranymi źródłami RHQ):

git pull -v --stat

Krok 3: konfiguracja bazy danych

Konfigurację bazy danych opisałem w artykule Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr w punkcie 3. Zamiast jednak tworzyć bazę danych o nazwie rhq należy utworzyć bazę o nazwie rhqdev:

createdb -U postgres -O rhqadmin rhqdev

Krok 4: kompilacja źródeł

Czas teraz na kompilację źródeł. Robi się to przy użyciu aplikacji maven. Pierwsza kompilacja może zająć sporo czasu (nawet do godziny), ponieważ zostaną pobrane biblioteki niezbędne do kompilacji i działania serwera RHQ. Każda następna powinna już być zdecydowania szybsza.

Kompilację rozpoczynamy będąc w katalogu ze źródłami aplikacji następującą komendą:

mvn -Penterprise,dev -Dmaven.test.skip=true -Ddbsetup install

Podczas procesu kompilacji zostanie utworzona baza danych, w związku z tym musi ona być odpowiednio skonfigurowana.

Po zakończeniu kompilacji można znaleźć serwer RHQ w katalogu modules/enterprise/server/container/target. Można w nim znaleźć także archiwum o nawie rhq-server-3.0.0-SNAPSHOT.zip, które można użyć do instalacji nowej wersji serwera lub też do aktualizacji już istniejącej.


Można także skompilować RHQ przy użyciu takiego polecenia:

mvn -Penterprise,dist -Dmaven.test.skip=true -Ddbsetup install

Spowoduje to utworzenie archiwum przeznaczonego do instalacji i aktualizacji. Ja niestety tak nie zrobiłem, co naraziło mnie na późniejsze problemy. Być może użycie tak przygotowanych plików binarnych rozwiązałoby je samo….

Krok 5: konfiguracja nowej wersji RHQ

Pozostaje teraz skopiować plik rhq-server-3.0.0-SNAPSHOT.zip na serwer docelowy i przystąpić do instalacji nowej wersji RHQ.

W moim przypadku instalowałem serwer w katalogu /opt/rhq-server. Początkowa konfiguracja sprowadza się do podania ścieżki dostępu do środowiska Java, czyli definiujemy odpowiednie zmienne w pliku bin/rhq-server.sh:

86
87
88
RHQ_SERVER_HOME=/opt/rhq-server
# RHQ_SERVER_DEBUG=true
JAVA_HOME=/usr/lib/jvm/java-6-sun

Teoretycznie, teraz można było uruchomić serwer, ale niestety nie w tym przypadku. Ponieważ podczas kompilacji została utworzona wersja deweloperska, to jest ona już przygotowana do pracy z odpowiednią bazą danych. Nie ma możliwości przeprowadzenia aktualizacji już istniejącego schematu. W związku z tym należy odwrócić proces instalacji, i przygotować tak serwer, aby pozwalał na uruchomienie procesu instalacji.

Nie ma takiej potrzeby, jeżeli kompilacja odbywała się z opcją dist.

Poniższe akcje należy wykonać w katalogu jbossas/server/default/deploy/. Zmieniają one nazwy niektórych aplikacji i usuwają niepotrzebne aplikacje (które zostaną utworzone podczas konfiguracji).

cd /opt/rhq-server/jbossas/server/default/deploy/
mv alert-cache-service.xml{,.rej}
rm -fr jms
mv jmx-console.war{,.rej}
mv mail-service.xml{,.rej}
mv rhq-agent.sar{,.rej}
rm rhq-ds.xml
mv rhq.ear{,.rej}

Powyższe kroki spowodują, że teraz serwer RHQ uruchomi się w trybie instalacji.

Można teraz uruchomić serwer RHQ, najlepiej w trybie konsoli:

bin/rhq-server.sh console

Po pomyślnym uruchomieniu, można połączyć się z adresem http://localhost:7080 i dalszą konfigurację przeprowadzić przy użyciu przeglądarki internetowej.

Na drugim ekranie możemy zdefiniować podstawowe dane potrzebne do instalacji serwera. Ponieważ przeprowadzamy aktualizację serwera, należy podać namiary na istniejącą bazę danych i po ich podaniu wybrać przycisk Test connection. Połączenie zostanie sprawdzone, RHQ wykryje że baza danych istnieje i będzie istniała możliwość zdefiniowania co z nią zrobić. Należy wybrać opcję Keep.

Ostatnim elementem będzie zdefiniowanie informacji o serwerze, na którym będzie pracował serwer RHQ. Można to zrobić przy polu Registered Servers. Z wyświetlonej listy wybieramy nasz serwer.

RHQ Server - aktualizacja serwera

RHQ Server - aktualizacja serwera

Warto pamiętać, że informacje o połączeniu z bazą danych oraz o konfiguracji serwera można znaleźć w pliku rhq-server.properties.

Po wykonaniu powyższych modyfikacji, można rozpocząć instalację serwera.

W moim przypadku w tym momencie zaczął pokazywać się dosyć długi wyjątek, który sprowadzał się do następującego komunikatu:

Cause: org.postgresql.util.PSQLException: BŁĄD: relacja "rhq_raw_config_id_seq" już istnieje

Przyczyną jego występowania jest próba utworzenia już istniejącej sekwencji (co można łatwo sprawdzić łącząc się z bazą danych). Usuwanie tej sekwencji z bazy i ponowne uruchamianie procesu instalacji niestety nie rozwiązywało problemu, w dalszym ciągu komunikat się pojawiał.

I w tym miejscu rozpoczyna się bardziej żmudna część tej instalacji. Nie będę już przynudzał, co i gdzie sprawdzałem aby się dowiedzieć w jaki sposób jest dokonywana aktualizacja bazy danych, skupię się tylko na sposobie rozwiązania tego problemu.

Baza danych aktualizowana jest na podstawie zawartości pliku db-upgrade.xml, który można znaleźć w archiwum jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar. Należy ten plik otworzyć, wprowadzić modyfikację oraz zapisać. Ponieważ plik znajduje się w archiwum jar, dobrze jest tutaj użyć jakiegoś narzędzia, które pozwoli na modyfikowanie jego zawartości bez ręcznego wypakowywania plików. Ja używałem aplikacji Midnight Commander, który sobie z tym poradził znakomicie. I po kolei, trzeba zrobić:

  1. Otwieramy plik jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar
  2. Otwieramy plik db-upgrade.xml w trybie edycji
  3. Znajdujemy linię, która zawiera definicję sekwencji rhq_raw_config_id_seq i komentujemy ją:
    1668
    <!-- <schema-createSequence name="RHQ_REPO_GROUP_ID_SEQ" initial="10001" /> -->
  4. Ponownie uruchamiamy instalację serwera
  5. Jeżeli wystąpi błąd z inną sekwencją, wykonujemy ponownie kroki od 2 do 4. W moim przypadku musiałem tę operację powtórzyć dla następujących linii:
    1725
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_TYPE_ID_SEQ" initial="10001" /> -->
    1749
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_ID_SEQ" initial="10001" /> -->
    1808
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_TYPE_ID_SEQ" initial="10001" /> -->
    1915
    <!-- <schema-createSequence name="RHQ_TAG_ID_SEQ" initial="10001" /> -->
    1929
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_FILE_ID_SEQ" initial="10001" /> -->
    2298
    <!-- <schema-createSequence name="RHQ_REPO_SYNC_ID_SEQ" initial="10001" /> -->
    2358
    <!-- <schema-createSequence name="RHQ_BUNDLE_ID_SEQ" initial="10001" /> -->
    2399
    <!-- <schema-createSequence name="RHQ_BUNDLE_VERSION_ID_SEQ" initial="10001" /> -->
    2464
    <!-- <schema-createSequence name="RHQ_BUNDLE_FILE_ID_SEQ" initial="10001" /> -->
    2588
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEPLOY_ID_SEQ" initial="10001" /> -->
    2624
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEP_HIST_ID_SEQ" initial="10001" /> -->
    2710
    <!-- <schema-createSequence name="RHQ_SAVED_SEARCH_ID_SEQ" initial="10001" /> -->
    2762
    <!-- <schema-createSequence name="RHQ_ROLE_LDAP_GROUP_ID_SEQ" initial="10001" /> -->
  6. W przypadku wystąpienia różnych innych błędów, warto rozpocząć proces instalacji od nowa lub w skrajnych przypadkach zrestartować serwer RHQ i ponownie rozpocząć instalację

W moim przypadku po zakomentowaniu ostatniej sekwencji instalacja przebiegła pomyślnie, baza danych została zaktualizowana, RHQ poprawnie się skonfigurował i mogłem już zalogować się na własne konto.

Krok 6: aktualizacja agentów monitorujących

Ostatnim elementem związanym z aktualizacją serwera jest poprawny upgrade agentów monitorujących. I tutaj pokazała się siłą tej architektury :). W moim przypadku wystarczyło po prostu zrestartować agenty, i już samoczynnie się one zaktualizowały.

Jeżeli posiadasz zdefiniowaną grupę z agentami (informacje o tym jak to zrobić możesz znaleźć w tym wpisie: Definiowanie grupy usług w serwerze RHQ), to wystarczy ją wybrać i wydać polecenie restartu. Polecenie zostanie zdalnie wykonane, agenty się zrestartują i zaktualizują.

W moim przypadku agenci wykryli nowe zasoby na serwera oraz niestety od nowa niektóre serwery JBoss (przynajmniej tyle na razie zauważyłem). Przestało także działać monitorowanie serwera Apache.

Tym sposobem dotarliśmy do końca, mam nadzieję że na więcej problemów nie natraficie.

Źródła

Tags: , , , , , , ,

Instalacja agenta monitorującego RHQ

Maj 25

Posted by Łukasz Stelmach in RHQ/JON | Comments off

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: , , , , , ,