Hoe verbind je Elastic Logstash met JMS?

Snelle responstijden en inhoudelijk zoeken in berichten

Elastic staat bekend om zijn monitoring en database die heel eenvoudig documenten opslaat en zeer snel resultaat levert bij zoekopdrachten.

Veel bedrijven hebben een integratieplatform, een zogenaamde Enterprise Service Bus (ESB). Voor veel mensen is het onduidelijk en niet zichtbaar wat er op zo’n ESB gebeurd. Hiervoor zijn er vaak log-in mogelijkheden ingebouwd om de berichten die over en weer gaan op te slaan in een database. Vaak is op zo’n database een webapplicatie gebouwd waarmee zowel technische als business gerelateerde mensen kunnen kijken naar details van berichten. Over het algemeen gaat het om een traditionele SQL database welke ook zijn limieten heeft. Je moet namelijk van te voren goed vastleggen waar je op wil zoeken en het doorzoeken van hele berichten is lastig. Elastic maakt door middel van een NOSQL database snelle responstijden en inhoudelijk zoeken in berichten wel mogelijk.

Logstash verbinden met JMS

Het monitoren van berichten en deze sturen richting Elastic moet non-intrusive zijn ten opzichte van je huidige business proces. De monitoring is vaak losgekoppeld van je business process op de ESB, zodat bij storingen in de monitoring dit geen effect heeft op het berichtenverkeer. Dit doe je vaak door gebruik te maken van een queue mechanisme. Dit biedt Elastic Logstash mooi de gelegenheid om via de JMS input plugin verbindingen te maken met de JMS providers van je integratie laag. Standaard worden een aantal JMS providers ondersteund, denk hierbij aan RabbitMQ of ActiveMQ. Dat neemt niet weg dat het verbinden met JMS providers die niet ondersteund zijn ook mogelijk is. In deze blog gaan we daar dieper op in door Logstash te koppelen aan de JMS provider Sonic MQ van Aurea. Elke andere JMS werkt ongeveer vergelijkbaar.

Aan de slag: hoe configureer je Elastic Logstash om via Sonic JMS berichten in te lezen?

1. In mijn ESB heb ik voor de JMS configuratie een JNDI entry gemaakt in Sonic (Hoe dit te doen kun je terug vinden in de Sonic MQ documentatie).
2. In heb een yaml file gemaakt met configuratie instellingen welke gebruikt kan worden door mijn Logstash pipeline.
3. Ik heb een pipeline definitie gemaakt met daarin verwijzingen naar een yml file met de JMS JNDI specificatie (file uit stap 2).
4. Ik heb Logstash gestart en daarna in Elastic ervoor gezorgd dat de aangemaakte index gebruikt kan worden.

Stap 1

Zoals je ziet hebben we een JNDI entry aangemaakt in Sonic van het type “Connection Factory” met de naam Message01CF.  Deze naam is de JNDI naam die we ook terug laten komen (gebruiken dus) in onze config files in de volgende stappen.

Stap 2 

We maken een yml file met daarin de JNDI connectie specificaties. Laten we dit yml bestand als volgt noemen: tst_aureasonicjms_msg01.yml

Naast dat we de naam van onze JNDI entry weer terug laten komen moeten we ook vastleggen hoe we verbinding kunnen maken met Sonic. Als laatste voegen we verwijzingen toe waar de jar files staan die nodig zijn om JMS met Sonic te kunnen verbinden.

Onze yml file ziet er als volgt uit:

Stap 3

We moeten nu nog een Logstash pipeline opzetten waarin we zorgen dat we via de input JMS plugin de verbinding met Sonic maken. Bij de Input definieer je vanaf welke queue (destination) je berichten wilt consumeren (dit kan ook een topic zijn, zorg dan wel dat je de juiste connection factory hebt gedefinieerd in je JNDI entry).

In ons voorbeeld verbinden we naar Sample.Q1 om berichten uit te lezen. In het gedeelte van yaml_file / yaml_section bepaal je waar Logstash de juiste configuratie kan vinden om de verbinding via JNDI op te zetten naar Sonic.

In het Filter gedeelte voeg ik nu een extra veld toe waardoor ik per bericht weet in elke omgeving van mijn OTAP straat dit bericht komt. Ook verwijder ik overbodige velden. In dit geval alles dat of begint met jms / JMS of de naam transactionID heeft.

Als output geef je de informatie op om met je eigen Elastic cluster om te verbinden en de juiste index te kiezen.

Twee handige tips om rekening mee te houden.

1. Binnen de JMS specificaties heeft Sonic een eigen extentie, het Multipart principe. Een Multipart JMS bericht zijn eigenlijk meerdere JMS berichten in 1, iets wat niet onder de standaard specificaties valt. Hierdoor is deze ook niet ondersteund vanuit de Elastic JMS implementatie en zal je als Sonic gebruiker er altijd voor moeten zorgen dat je geen JMS Multipart berichten aanlevert aan Elastic.
2. Alle JMS properties die bekend zijn van een bericht worden automatisch omgezet naar fields van je Index in Elasticsearch. Dit is heel handig en flexibel.

Als kleine toegift nog; denk eens aan het gebruik van Elastic Heartbeat voor het monitoren van je JMS laag. Is deze JMS laag up en bereikbaar? Door in de heartbeat configuratie een TCP monitoring te definiëren kan je de JMS laag van je ESB in de gaten houden.

Uptime in Kibina

Conclusie

Ondanks dat niet alle JMS providers worden ondersteund bij Elastic is het heel eenvoudig om Logstash te verbinden met JMS. Je hebt nu de mogelijkheid om vanuit één Elastic omgeving zowel je JMS berichten te loggen en dit te combineren met informatie vanuit Heartbeat. Zo weet je of je JMS nog actief is. Daarnaast kun je ook je logfiles toevoegen. Deze combinatie resulteert in veel inzichten die niet altijd bekend waren.

Vanuit Devoteam hebben we dit voor klanten met Tibco EMS en met Sonic MQ naar volle tevredenheid gedaan. Op deze manier bieden we de klanten een stabiele log omgeving die klaar is om te groeien in de toekomst, afhankelijk van hoe het integratie landschap zal veranderen.