Monitorovací sonda do aplikačních serverů JBoss AS, WildFly, JBoss EAP

Monitorování aplikačních serverů

Nedávno jsem řešil problém jak monitorovat aplikační servery (JBoss AS, WildFly, JBoss EAP) pomocí monitorovacích nástrojů z tzv. „Nagios rodiny“ (Nagios, Icinga2, Centreon). Aplikační servery sice podporují jmx, ale bohužel standartní jmx_plugin, který je součástí rozšíření, které lze do monitorovacího nástroje instalovat nefunguje.

Návrh sondy

Rozhodl jsem se tedy vytvořit plugin, kterým lze rodina aplikačních serverů od JBoss monitorovat. Aplikační servery mohou běžet ve více režimech (Standalone, Managed domain). V režimu Standalone běží pouze jeden server s jedním management rozhraním.

V režimu „Managed domain“ může v rámci domény (jednoho management rozhraní) běžet více serverů. Snažil jsem se o to, aby si mohl případný uživatel plugin sám jednoduše upravit, takže jsem zvolil pro sondu bash script.

Tento skript využívá navíc jq příkaz pro podporu JSON formátu. Tento příkaz je potřeba většinou externě doinstalovat (v případě např. CentOs stačí napsat yum install jq). Sonda využívá REST API, které mají aplikační servery JBoss k dispozici.

Skript používá formát nagios pluginy, takže vrací definovaný stav (OK, ERROR, WARNING, UNKNOWN), případně performace data.

V této chvíli vrací aktuální hodnoty threadů a JVM Heapu, které pro základní monitorování JVM stačí. Případně lze tento plugin jednoduše upravit na vytahování dalších informací z aplikačních serverů. Pomocí REST API (defaultní adresa je http://localhost:9990/management) lze snadno zjistit velmi mnoho informací o běhu, případně konfiguraci.

Použití

Sonda lze volat lokálně, případně i nainstalovat přímo na server a volat například pomocí ssh nebo NRPE.

Sonda lze volat v konfiguraci aplikačního serveru standalone:

./check_wildfly.sh -u user -p userpassword -a http://server_url:9990 

Případně v konfiguraci aplikačního serveru managed domain:

./check_wildfly.sh -u user -p userpassword -a http://server_url:19990 -s server_name -c controller_name 

V tomto případě může aplikační server pomocí domain controlleru (adresa serveru, kam se sonda připojuje) řidit více serverů na různých host kontrolerech. V tomto případě je potřeba nakonfigurovat název monitorovaného serveru a název host kontroleru, který ho zpravuje.

Na management rozhraní se lze přihlásit pomocí stejných údajů jako do administrátorské konzole (defaultní url admin. konzole je http://localhost:9990/console).

Monitorování

Sondu jsem otestoval pomocí nástroje Icinga2 (podporuje nagios pluginy), kde performance data ze sondy ukládám do InfluxDB a poté zobrazují pomocí nástroje Grafana. V tomto případě výstup může vypadat například takto:

Další vylepšení

V rámci tohoto pluginu mě jich napadá velká část a postupně se k některým doufám dostanu:

• Kontrola hodnot Domain a Host kontroleru
• Deployment statistiky do performance dat
• Lepší kontrola a možnost nastavení thresholdů u kontroly
• Kontroly platnosti certifikátů (toto lze například http sondou)
• Monitorování počtu requestů

Odkazy

• Odkaz na zdrojové kódy vytvořené sondy
• Icinga2
• Nagios

Camel subsystém ve Wildfly

Camel subsystém ve Wildfly

Dnes napíšu o zajímavé možnosti spojení frameworku Camel s aplikačním serverem Wildfly.

Důvody využití

Máte aplikaci, které vyžaduje některé z těchto vlastností:

• Komunikace se systémy, možnost efektivně reagovat na výpadky
• Monitorování komunikace
• Modulární koncepce aplikace, možnost měnit nebo upravit část aplikace bez výpadku ostatních částí
• Transformace, validace dat, throttling, load balancing v rámci komunikace
• Využívaní integračních vzorů

Pak Camel je integrační a mediační framework, který vám je schopen tyto vlastnosti splnit.

Camel lze použít i tak, že Camel knihovny přímo přidáte do aplikace (do war, ear apod), případně si vytvoříte vlastní modul do aplikačního serveru. Lepší řešení pro aplikační server Wildfly je využití subsystému Camel.

Výhoda využití Camel subsystému:

• Integrovaná managovací konzole Hawtio
• Grafické zobrazení jednotlivých route a zobrazení vytížení
• Automatická incializace Camel při deployi aplikace
• Ukázky kódu a aplikací, ze kterých lze při vývoji vycházet
• Flexibilnější vývoj

Camel

V jednom z předchozích článku jsem psal o integraci Camel frameworku s Spring Boot, které je ideální například na vytváření mikroslužeb. Camel je integrační framework, který velmi zjednodušuje integraci mezi aplikacemi. Obsahuje spoustu podpůrných komponent, kterými se lze napojit na různé systémy (messaging, SOAP/REST služby, databáze apod.). Tento framework lze efektivně napojit například do aplikačních serverů, ale lze jednoduše integrovat do jakékoliv jiné aplikace (malý počet závislostí, modulární architektura). Výhoda tohoto projektu i velká členská základna, velký počet komponent, případně možnost rozšíření o vlastní komponentu.

Wildfly

Wildfly je opensource aplikační server, který podporuje zejména standardy JEE 7 (RedHat má komerční variantu nazvanou JBoss EAP 7). Wildfly je využíván pro běh a monitorování aplikací (war, ear, jar). Architektura Widfly aplikačního serveru je postavena tak, že pomocí rozšíření (subsystémy) lze rozšiřovat jeho funkcionalitu. Widlfly má dnes velmi dobře zpracované služby pro podporu běhu aplikací jako clustering, zabezpečení aplikací, monitorování a konfigurace bez výpadku. Mezi jeho další výhody pak patří možnost instalovat do Cloud prostředí (OpenShift, Azure, AWS), podpora vlastního load balanceru, efektivní konfigurace v cluster zapojení, instalace pomocí Docker. O Wildfly lze napsat samostatný článek, proto se mu někdy později budu věnovat. Aktuální verze je nyní 10.1.0.Final.

Instalace Camel subsystému do Wildfly

Camel není standardní součástí Wildfly a tak musí být odinstalován. Instalace je jednoduchá. Je potřeba stáhnout instalační balík zde. V případě, že běžíte na starší verzi aplikačního serveru Wildfly, je potřeba zkontrolovat kompatibilitu serveru. Stáhněte si aktuální verzi aplikačního serveru a Camel subsystému do jednoho adresáře.

Proveďte instalaci

[bash] unzip wildfly-dist-10.1.0.Final.zip
[bash] tar xvzf wildfly-camel-patch-4.7.0.tar.gz -C wildfly-10.1.0.Final/

V rámci čláku využívám proměnou WILDFLY_HOME, která odkazuje na adresář wildfly-10.1.0.Final. Konfigurace je ukázána v shell terminálu, ale analogicky lze konfiguraci provést na jiných platformách.

Subsystém se automaticky nainstaluje a vytvoří konfigurační soubory a moduly (knihovny v Camel).

Instalace Camel subsystému do Wildfly

Camel není standardní součástí Wildfly a tak musí být odinstalován. Instalace je jednoduchá. Je potřeba stáhnout instalační balík zde. V případě, že běžíte na starší verzi aplikačního serveru Wildfly, je potřeba zkontrolovat kompatibilitu serveru. Subsystém se automaticky nainstaluje a vytvoří konfigurační Instalace automaticky neupdatuje původní konfigurační soubory (standalone.xml, domain.xml), ale instaluje nové soubory (standalone-camel.xml, domain-camel.xml). Případně do adresáře WILDFLY_HOME/bin je soubor fuseconfig.sh, kterým lze subsystém automaticky vytvořit i v původních konfiguračních souborech.

$WILDFLY_HOME/bin/fuseconfig.sh --configs=camel --enable

Spuštění aplikačního serveru můžete provést například pomocí příkazu.

$WILDFLY_HOME/bin/standalone.sh -c standalone-camel.xml

Tím se spustí aplikační server ve standalone módu. V konzoli po spuštění aplikačního serveru, případně logu (server.log v adresáří WILDFLY_HOME/standalone/log) by se měla objevit následující informace.

[org.wildfly.extension.gravia] (MSC service thread 1-8) Activating Gravia Subsystem
[org.wildfly.extension.camel] (MSC service thread 1-7) Activating Camel Subsystem

A také naběhnutí monitorovací konzole hawtio.

 [org.wildfly.extension.camel] (ServerService Thread Pool -- 75) Add Camel endpoint: http://127.0.0.1:8080/hawtio

Nyní můžete přes příkaz CRTL+C aplikační server vypnout.

Konfigurace subsystému Camel

Aby bylo možné přistoupit do monitorovací konzole hawtio, která je součástí CAMEL subsystému, je potřeba přidat uživatele. K tomu lze využít skript add-user.sh, který je součástí aplikačního serveru v adresáří bin.

sh WILDFLY_HOME/bin/add-user.sh -m -u test -p test1234# -s

Tím se vytvoří management uživatel, kterým se lze přihlásit do hawtio konzole.

Spuťte znovu aplikační server

$WILDFLY_HOME/bin/standalone.sh -c standalone-camel.xml

A v prohlížeči zadejte url adresu http://127.0.0.1:8080/hawtio/. Měla by se objevit login stránka.

.

Přihlašte se pomocí uživatele test a hesla test1234#. Login by měl úspěšně proběhnout a měla by se objevit základní monitorovací stránka.

.

Nyní máme nainstalovaný subsystém Camel. Konfiguraci a vytváření toků (route) popíší v jednom z dalších článků.

• Camel projekt
• Aplikační server Wildfly
• Camel subsystém do Wildlfy
• EIP vzory

Spring Boot integrace s projektem Camel

Několik příspěvků zpětně jsem řešil jakou technologii zvolit (Wildfly Swarm vs Spring Boot). Nakonec zvítězila technologie Spring Boot a to zejména z těchto důvodů:

• Větší komunita uživatelů než u Wilfly Swarm
• Větší množství příkladů a testů
• Lepší a jednoduší integrace s Camel frameworkem

U projektů, které vyžadují komunikaci přes různé protokoly a v rámci logiky využívají integrační toky (přenos a transformace dat mezi různými body) využívam většinou framework Camel.

Camel

Camel je open source integrační framework, který podporuje EIP (Enterprise Integration Patterns). Tento framework umožnuje efektivně a rychle integraci nad různými datovými zdroji, umožnuje provádět transformace mezi daty a případně řešit error handling a další věci spojené s přenosem a transformacemi dat. Výhody a konfigurace Camel je na samostatný článek (rád v budoucnu o něm napíši).

Camel je součástí dnes i open source integračních řešení jako Apache Service Mix, případně SwitchYard, ale například i komerčních (JBoss Fuse od Red Hat). Camel je sada knihoven, takže lze snadno integrovat i do vlastních aplikací. Camel není jediný integrační framework. Spring má vlastní projekt Spring Integration. Camel jsem zvolil hlavně z těchto důvodů:

• Velká komunita uživatelů Camel
• Dlouhodobě udržovaný projekt
• Modulárnost celého řešení
• Rozšiřitelnost o vlastní komponenty
• Testovací komponenty, které umožnují dělat i složitější testy (Mockování služeb)
• Možnost zápisu integračních toků pomoci Spring DSL (XML) a Java DSL
• Předchozí zkušenosti s tímto frameworkem

Integrace se Spring Boot

Integrace se Spring Boot je jednoduchá. Stačí využít Spring Boot generátor, případně podle různých návodů nakonfigurovat například pom.xml používáte-li maven na sestavení.

V mé ukázce jsem nejdříve nakonfigurovat dependencyManagement, kde jsem nastavil dvě BOM závislosti. Jedna je pro Spring Boot a druhá pro integraci Spring Boot s Camel.

<dependencyManagement>
   <dependencies>
       <!-- Spring Boot BOM -->
       <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-dependencies</artifactId>
          <version>${spring.boot.version}</version>
          <type>pom</type>
          <scope>import</scope>
       </dependency>
       <!-- Camel BOM -->
       <dependency>
          <groupId>org.apache.camel</groupId>
          <artifactId>camel-spring-boot-dependencies</artifactId>
          <version>${camel.version}</version>
          <type>pom</type>
          <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Poté již je k dispozici většina knihoven potřebná pro sestavení aplikace a případný běh nebo testy. Camel má základní služby v modulu camel-core. Další adaptéry a komponenty jsou k dispozici v dalších podpůrných modulech např. komunikace se smtp nebo imap je v modulu camel-smtp.

	<dependency>
            <groupId>org.apache.camel</groupId>
            <artifactId>camel-mail</artifactId>
        </dependency>

        <dependency>
            <groupId>org.apache.camel</groupId>
            <artifactId>camel-servlet</artifactId>
        </dependency>

Vytváření integračních toků

Vytváření integračních toků je již velice jednoduché. Konfigurací již Spring Boot aplikace při startu bude hledat Camel routy (bloky ve kterých se tyto integrační toky definují) a bude je na základě konfigurace spouštět. Aby Spring Boot aplikace veděla, kde tyto bloky hledat, stačí označit třídy (pomocí spring anotace Component) ve kterých jsou tyto routy definované.

Ukázka konfigurace pomocí Java DSL, kde každá třída musí dědit abstraktní třídu RouteBuilder. V metodě configure je poté konfigurace samostatných route. Spring Boot umožnuje Camel routy také načítat pomocí Spring DSL (XML konfigurace).

@Component
public class DummyRoute extends RouteBuilder {
    @Override
    public void configure() throws Exception {

        from("direct:getInfo").process(exchange -> {
            exchange.getIn().setBody("Basic information");
        });
         

    }
}

Tento příklad pouze vytváření jednoduchou routu, která pouze vrací zprávu s obsahem Basic information. Route může být v aplikace více (preferuji rozdělení například podle komponent nebo integračních toků).

Vlastní logiku v Camel routách ukážu někdy v dalších příspěvkách.

Kompletní ukázka integrace Spring Boot s Camel je zde.

• Ukázka příkladu integrace Spring Boot s Camel
• Camel projekt
• Enterprise Integration Patterns
• Spring Boot generáror
• Spring Boot

Vyšla nová verze JB348

Nová verze JB348

Tento měsíc vyšla nová verze školení JB348, která je již zaměřena na novou verzi EAP 7. Tato verze je osnovou velmi podobná předchozí verzi EAP 6. Školení reflektuje změny, které jsou v EAP 7. Jako předchozí verze je tato verze 4 denní. Školení rozvíjí následující subsystémy a komponenty EAP 7:

• Migrace z EAP 6 - využití open source nástrojů pro migrace na EAP 7
• Clustering - best practice, konfigurace clusteringu - využití undertow load balanceru
• CLI a skriptování - možnosti konfigurace skriptování, využití skriptování pomocí dalších nástrojů
• Management, Management API a Native API
• Messaging - optimalizace messagingu ActiveMQ Artemis, bridge, HA, clustering
• Security - použití SSO, zabezpečení administrace
• Instalace a konfigurace v Cloudu
• Audit logging, patching

Toto školení rozvíjí znalosti ze školení JB248 (již na EAP 7) a dá vám další znalosti jak efektivne administrovat, případně používat EAP 7.

Bude se těšit až některé z vás na školení uvidím.

• Odkaz na novou verzi školení JB348
• Základní školení JB248

Icinga2 monitoring

Icinga2 monitoring

V dnešním článku se zmíním o projektu na monitorování zařízení Icinga2. V rámci jednoho projektu řešíme monitorování stovek zařízení, na kterých běží různé služby (ssh, smtp, db). V rámci předchozího projektu, již byla nasazena první verze Icinga2, který jsme začali rozšiřovat. Výhody tohoto projektu:

• Jednoduchá konfigurace
• Součástí systémů (CentOS, Ubuntu)
• Rozšiřitelnost o mnoho pluginů a komponent (nrpe klient, nsclient++)
• Díky REST API snadná integrace s CMDB databázemi a například ticketing systémy
• Možnost konfigurace HA, škálování, notifikačních pluginů
• Možnost konfigurace tzv. zón, ve kterých můžou být umístěné různé monitorovací systémy

Icinga2 projekt

Jedná se o projekt, který je fork projektu nagios. Výhoda tohoto projektu je, že lze využít většinu nagios pluginů. Icinga2 je modulární projekt, takže lze rozšiřovat o další funkcionalitu. Architektura aplikace je navržena pro škálovatelný průběh a také pro HA konfiguraci. Takže v případně výpadku jednoho monitorovacího nodu, můžou ostatní nody převzít jeho servery a dále monitorovat. Dnes je Icinga2 součástí většiny balíčkovacích systémů v prostředí linux.

Mnoho rozšíření je již instalovaných a lze je jednoduše konfigurovat. Tato vlastnost je výhodná například, kdy se testuje konfiguraci nového monitorovacího zařízení a nechcete, aby Icinga2 aktivně monitorovala, ale běžela pouze pasivně. Zde jsou zajímavé rozšíření Icinga2.

• checker - v případě, že je zapnutý, aktivně monitoruje zařízení
• notification - v případě zjištění problémů (výpadek, přesáhnutí thresholdu) spustí notifikaci
• ido-mysql (ido-postgresql) - ukládání dat a konfigurace do databáze
• api - Zapnutí Icinga2 API (REST API)
• debug - Zapnutí debug logu (doporučuji na začátek)

[icinga@localhost features-enabled]# icinga2 feature enable checker

Jak lze vidět na ukázce, Icinga2 má sadu commandů, kterými lze konfigurovat tento projekt.

Icinga2 konfigurace

Icinga2 projekt lze nakonfigurovat několika způsoby. V rámci Icinga2 projektu existuje několik základních objektů. Defaultně je veškerá konfigurace v souborech, které ovšem po změně vyžadují restart serveru.

• Host
• Služba
• Kontakt
• Skupiny
• Notifikace

Host

Konfigurace monitorovaného objektu. Monitorované objekty mohou být rozšířeny o vlastní proměnné (vars), případně jim lze nadefinovat společné vlastnosti pomocí šablony (generic-template).

object Host "TestHost" {
  import "generic-host"

  address = "172.25.1.6"

  vars.os = "Linux"

  vars.http_vhosts["http"] = {
    http_uri = "/"
  }
  vars.disks["disk /"] = {
    disk_partitions = "/"
  }

  vars.notification["mail"] = {
    groups = [ "icingaadmins" ]
  }
}

Služba

Služby slouží k samotnému monitorování hostů. Služby mohou monitorovat externě jako například volání služby nebo kontrola otevřenosti portu. Případně mohou volat interní operace přímo v monitorovacích objektech.

apply Service "postgress" {
  import "generic-service"

  check_command = "pgsql"
  vars.pgsql_hostname = "localhost"
  vars.pgsql_database = "icinga"
  vars.pgsql_username = "icinga"
  vars.pgsql_password = "icinga"
  vars.pgsql_port = "5432"

  assign where (host.address || host.address6) && host.vars.os == "Linux"  && host.vars.db == "postgres"
}

Pomocí assign ve službě lze automaticky definovat pravidla, podle kterých se budou vybírat hosty pro dané monitorování. Tyto pravidla zjednodušují konfiguraci monitorování služeb.

Kontakt

Pro správnou funkci notifikaci je potřeba mít nadefinované kontakty, na které se budou posílat notifikace.

object User "icingaadmin" {
  import "generic-user"

  display_name = "Icinga 2 Admin"
  groups = [ "icingaadmins" ]

  email = "icinga@localhost"
}

Skupiny

Různé objekty (kontakty, hosty, služby) lze shlukovat do skupin, kde tyto objekty mohou mít společné vlastnosti. Například v případě notifikace na skupinu může být email rozeslán všem kontaktům ve skupině.

object HostGroup "linux-servers" {
  display_name = "Linux Servers"

  assign where host.vars.os == "Linux"
}

object ServiceGroup "ping" {
  display_name = "Ping Checks"

  assign where match("ping*", service.name)
}

Notifikace

V případě, že na základě chyby vyhodnotí Icinga2, že se jedná o problém, který je potřeba notifikovat, spustí skript, který tuto notifikaci provede. Například defaultně se spouští skript, který pošle email. Tyto notifikační skripty lze jednoduše konfigurovat, případně přepsat na vlastní funkcionalitu (poslání sms, apod).

Icinga2 Persistence

Icinga2 může používat ukládání do relační databáze (postgresql, mysql). Do tohoto databázového schématu ukládá Icinga2 data, ale i aktuální konfiguraci. Icinga2 může běžet i bez ukládání do databáze.

Rest API

V případě Icinga2 lze zapnout REST API, které umožňuje vytvářet a upravovat objekty. V případě volání REST API a nastavení databázové konfigurace si Icinga ukládá data do databáze, ale zároveň generuje i konfigurační soubory. V případě, že chcete například vymazata databázi stovek zařízení, je potřeba data mazat na více místech (smazat konfigurační soubory i data v databázi).

curl -X "PUT" "https://172.27.1.3:5665/v1/objects/hosts/test.cz" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json; charset=utf-8" \
     -u root:icinga \
     -d "{\"templates\":[\"generic-host\"],\"attrs\":{\"address\":\"172.27.1.5\",\"check_interval\":30,\"check_command\":\"hostalive\",\"vars.os\":\"Linux\"}}"

Některé operace jsou trochu zvláštní. Například objekty se zakládají přes operace PUT a upravují přes operaci POST. Další zvláštností je například, že vám systém nedovolí upravit kontakt tím, že byste mu nastavili jinou skupinu (musíte objekt smazat a znova vytvořit).

Použití tohoto API vám eliminuje problém s nutností po každé konfiguraci restartovat Icinga2. Další výhoda, že v případě běhu v HA režimu stačí operaci provést pouze na jednom nodu a automaticky dojde k redistribuci.

Konfigurace zón

V případě, že potřebujete monitorovat například více lokalit a chcete tyto monitorování rozdělit, můžete využit funkcionalitu satelitů a zón, kdy více instancí icinga2 rozdělíte a každá z těchto instancí může monitorovat jiná zařízení (například rozdělení podle lokalit Praha, Berlín apod).

Icinga2 moduly

Icinga2 lze rozšířit o další moduly. Zde je několik z nich.

Icinga2 web

Jedná se o grafický front end pro Icinga2 monitoring. Tento modul běží na webovém serveru httpd. Má jednoduché intuitivní ovládání, které umožnuje zobrazovat informace a monitorovaných zařízeních a službách.

Icinga2 data pouze zobrazuje a neumožnuje například editaci konfigurací zařízení, případně změnu monitorovacích služeb. Toho lze docílit dalšími přídavnými moduly. Icinga web modul potřebuje pro ukládání svých informací vlastní schéma v relační databázi (opět je na výběr mysql nebo postgresql).

Modul director

Aby bylo možné upravovat konfigurace bez nutnosti zásahu přímo do konfiguračních souborů, nebo úpravy pomocí REST API, je možné doinstalovat rozšíření director. Toto rozšíření umožnuje provádět v GUI přímo úpravy.

• Vytváření, úprava a mazání šablon
• Vytváření, úprava a mazání hostů a služeb
• Možnost konfiguraci si nejdříve naklikat v draftu, kdy změny se přímo neprovádí, ale musí se ještě potvrdit.

Shrnutí

Velkou výhodou Icinga2 je jednoduchá a flexibilní konfigurovatelnost a možnost využít spousty již vytvořených pluginů z Nagios. Další výhoda je i integrace grafických rozšíření (zobrazování nasbíraných dat, využit pamětí, CPU). Pro monitorování stovky zařízení je to naprosto dostačující produkt, který svou flexibilitou lze jednoduše integrovat do prostředí, kde se musíte napojit na různé zdroje (notifikace do ticket systémů, databáze zařízení).

• Icinga2
• Icinga2 modul director
• Zdrojové kódy Icinga2
• Nagios
• Nagios pluginy
• Icinga2 REST API examples
• Icinga2 CLI Commands
• Icinga2 REST API