Follow Us on Twitter

End-to-end logging in een Oracle Fusion Middleware omgeving

Mei 2014 - Bij het opzetten en bouwen van een Service Oriented Architecture (SOA) omgeving neemt het aantal services naarmate de tijd vordert steeds toe. Dit is natuurlijk ook het geval wanneer het een SOA-omgeving betreft gebaseerd op de Fusion Middleware stack van Oracle. In eerste instantie zal de standaard logging van de Oracle Service Bus (OSB) en de SOA Suite voldoende zijn. De SOA Suite heeft in de Enterprise Manager een audit trail waar de procesflow te volgen is. OSB kent alerts en log stappen welke inzichtelijk zijn vanaf de SBConsole. In beide gevallen is de logging afzonderlijk makkelijk te bereiken en snel te implementeren. Het correleren van de logging binnen de serviceketen is echter niet mogelijk. Daarnaast zijn de services binnen een SOA-omgeving slechts een schakel in de gehele keten. Ze staan meestal tussen de front-end en de back-end applicaties. Dit betekent dat het samenvoegen van de logging van de SOA Suite en de OSB-componenten onvoldoende is om end-to-end logging te realiseren.

Met end-to-end logging moet het mogelijk zijn om snel een foutmelding in het scherm van de gebruiker te kunnen herleiden naar een onverwachte fout bij een service-aanroep. Dit met als doel om opgetreden fouten snel te kunnen herleiden naar de veroorzaker. Dit wordt ook wel root cause analyses genoemd.

Met dit Whitebook wil ik je laten hoe je end-to-end logging kunt opzetten en waar je rekening mee moet houden.

Doel

Het is mogelijk om alles te loggen en dat is in een kleine omgeving geen probleem. Zodra het aantal service-calls toeneemt wordt dit steeds minder praktisch. De hoeveelheid data die wordt gelogd neemt dusdanig toe dat het onmogelijk is om alles op te slaan en effectief te gebruiken. Daarom is het verstandig om de logging te beperken tot het minimale noodzakelijke. Om dit te realiseren is het noodzakelijk om de doelstellingen van de logging vast te leggen. Deze bepaalt namelijk de mate en manier van loggen.

Mogelijke doelen van logging zijn:

  • Snelle en goede analyse ten behoeve van het oplossen van incidenten;
  • Pro-actief monitoren;
  • Ondersteuning bij governance (door wie wordt de service aangeroepen, wordt hij überhaupt nog aangeroepen);
  • Trend analyse om pro-actief beheer te ondersteunen (sizing van de omgeving etc.)
  • Service Audit Trail te realiseren;

Elk doel heeft specifieke eisen met betrekking tot de logging, wat voor informatie, moment van loggen, snelheid van de ontsluiting van de data. In andere woorden: moet de informatie real-time in een database worden weggeschreven of is een logbestand op een server voldoende.

conversation ID

Het belangrijkste onderdeel van end-to-end logging is het correleren van de logging. Als je alle logbestanden hebt verzameld en samengevoegd zul je de data moeten correleren. Indien je dit niet snel en efficiënt kunt doen, zal het oplossen van incidenten tijdrovend zijn. Daarom heb je een unieke sleutel nodig die gebruikt wordt binnen het gehele service landschap. Deze unieke sleutel wordt vaak "conversation ID" (conversation identifier) genoemd. Hoe eerder de conversation ID wordt gezet hoe effectiever de logging zal zijn. Het stelt je namelijk in staat om een fout te herleiden naar de oorspronkelijke service call.

De conversation ID is niet direct onderdeel van een regulier servicebericht. Dit betekent dat het toegevoegd moet worden aan het soap bericht. Een mogelijke locatie hiervoor is de SOAP-header. Door de conversation ID op te nemen in de header wordt het onderdeel van een service call zonder dat het in de payload, de daadwerkelijke inhoud van het bericht, terecht komt. Vervolgens kan de header, en daarmee de converstation ID, door het gehele service landschap mee worden gestuurd. Alle opvolgende service calls bevatten daarmee de conversation ID en kunnen dus gelinkt worden aan de originele service call.

Wat te loggen

Afhankelijk van het doel van de logging moet je bepalen wat je wilt vastleggen. Het is natuurlijk makkelijk om alles gewoon vast te leggen. Gezien dit niet altijd noodzakelijk is en het complexiteit met zich meebrengt is dit niet verstandig. Bijvoorbeeld bij de opslag van de data, de manier van zoeken, privacy etc. Het is dus van belang om de logging zoveel mogelijk te beperken. Hierbij is het verstandig om de logging op te splitsen in verschillende segmenten. Deze segmenten kunnen vervolgens al dan niet afzonderlijk worden opgeslagen zodat ze elk op hun eigen manier behandeld en benaderd worden. Drie mogelijke segmenten zijn:

  • Conversation logging;
  • Payload logging;
  • Error logging;

Conversatie logging

Om end-to-end logging te faciliteren moet niet alleen de fout gelogd worden maar ook het feit dat een call gedaan is. Dit kun je doen in de conversatielogging. Hierin leg je vast dat een bepaalde service call is gedaan, zowel de request als de reply. Je legt als het ware vast dat een conversatie plaats heeft gevonden, wie de conversatie is gestart wanneer deze heeft plaatsgevonden. Op deze manier kun je aantonen dat je bepaalde berichten hebt ontvangen en verwerkt. Bij het analyseren van een probleem kun je snel services uitsluiten als oorzaak van het probleem. Mogelijke informatie die in deze logging vastgelegd kan worden is:

  • Conversatie identifier;
  • Timestamp;
  • Component (servicenaam, versie);
  • Operatie;
  • Status;
  • Aanroepende partij;
  • Composite instance id;
  • Servernaam;

Payload logging

Indien noodzakelijk kan de gehele payload van het bericht worden vastgelegd. Dit met als doel om de gemaakte call te kunnen analyseren. Het loggen van de payload moet in ieder geval gebeuren als er een fout is opgetreden. Als in een conversatie een fout optreedt, is het noodzakelijk om in elk geval de payload van de eerste service in de conversatie te loggen. Zodat het met het orginele bericht mogelijk is om de conversatie, in een andere omgeving, opnieuw te starten. Eventueel met andere log-configuratie, met als doel het probleem nader te analyseren. Mogelijke informatie die in deze logging vastgelegd kan worden is:

  • Conversatie identifier;
  • Timestamp;
  • Component (naam, versie);
  • Operatie;
  • Request bericht (soap envelop met daarin de gehele payload);

Error log

Indien een bericht fout is gegaan moet dit worden gelogd. De fout die wordt ontvangen moet worden gelogd in de error log.  Mogelijke informatie die in deze logging vastgelegd kan worden is:

  • Conversatie identifier;
  • Timestamp;
  • Component (naam, versie);
  • Operatie;
  • Foutcode;
  • Foutbericht;
  • Stacktrace;

Manier van loggen

Zodra bekend is wat het doel van de logging is kun je kijken naar de manier van loggen. Afhankelijk van het doel, de grootte van het serverlandschap bestaan er verschillende keuzes. Een aantal van deze keuzes worden toegelicht in dit Whitebook.

Custom logfunctie

Zowel de OSB als de SOA Suite bieden de mogelijkheid om eigen Java functies te definiëren. Deze functies kunnen bijvoorbeeld als een custom xpath-functie of embedded java ontsloten worden in zowel de OSB als de SOA suite. Hiermee beschik je over de mogelijkheid om de manier van loggen geheel naar eigen wens in te richten. Zo kun je de log-informatie simpelweg naar een logbestand schrijven. Maar je kunt de informatie ook wegschrijven naar een jmsQueue. Vanuit daar kun je de informatie simpel oppakken en bijvoorbeeld wegschrijven naar een Database. De mogelijkheden met een custom logfunctie zijn zeer divers.

Het grote nadeel van een dergelijke implementatie is dat de logstap onderdeel is van de service. Dit betekent dat je niet alleen goed moet nadenken over de implementatie van de logging zelf maar ook moet kijken naar de mogelijke impact die de logstap heeft op je service. Wat moet je doen indien de logfunctie een fout retourneert.

Log policy

OWSMOracle heeft een standaard log policy, deze kan op zowel een OSB proxy als een SOA Composite worden geplaatst. Het betreft de oracle/log_policy, dit is een OWSM policy. OWSM staat voor Oracle Webservice Service Manager. OWSM verzorgt een laag welke je bovenop je services kunt plaatsen. Elke service call naar de betreffende service wordt eerst opgepikt door de policy alvorens hij daadwerkelijk door de service wordt opgepakt. Het mooie van een policy is dat je de extra logica buiten je service houdt en slechts op één plek hoeft uit te programmeren.  Een veel gebruikte implementatie waarbij OWSM wordt gebruikt is webservice security, het beveiligen van webservices.

Met de standaard log policy is het mogelijk om alle inkomende (request en reply) service calls te loggen. Wat er wordt gelogd is afhankelijk van de instellingen. De policy biedt de volgende opties:

  • all;
  • header;
  • SOAP body;
  • SOAP envelope;

De logging wordt weggeschreven naar een logbestand op de server, waarvan de logging vervolgens bekeken kan worden ter analyse.

Custom log policy

Het is mogelijk dat de OWSM als locatie voor je logmechanisme voldoet aan je eisen echter de implementatie van de log policy niet. De locatie waarop de logging wordt weggeschreven voldoet niet of je wilt de logging naar een database wegschrijven. Door je eigen log policy te implementeren ben je instaat om de manier van loggen zelf in te richten en deze middels een OWSM policy te implementeren. Dit betekent dat je de voordelen hebt van een custom logfunctie zonder direct de code van je service te raken.

Transactie monitoring

De bovengenoemde manieren van loggen komen allen voort uit de service zelf. Een vierde alternatief komt voort uit de onderlaag van een servicelandschap, de infrastructuur. Het verkeer dat door het servicelandschap gaat wordt uiteindelijk door servers verwerkt. De Oracle SOA Suite, OSB, Database etc. Er bestaan tools om in te prikken op deze servers en vanuit daar logging data te verzamelen. Oracle heeft hier bijvoorbeeld het product Business Transaction Management (BTM) voor.

Business Transaction Management Flow

Door "observers" (listeners) te installeren in je middleware omgeving verzamelt BTM transactie-data. Deze data op zich zelf zegt nog weinig. Binnen BTM worden de afhankelijkheden tussen de transacties vastgelegd en dat geeft BTM zijn meerwaarde. Met de transactie-data en de vastgelegde transacties kan BTM  conversaties direct monitoren. Het biedt de mogelijkheid om SLA’s vast te leggen, snel bottlenecks in je conversaties te vinden etc. BTM is geen standaard onderdeel binnen de SOA Suite. Het valt onder andere binnen de licentie voor het SOA Management Pack Enterprise Edition. In onze ervaring is het een erg krachtige tool, die in eerste instantie goed moet worden geconfigureerd om effectief te zijn. In het Whitebook "Enterprise Manager Cloud Control - SOA Management Pack" worden de mogelijkheden van BTM verder uiteen gezet..

Opslag en analyse

De manier van loggen kan bepalend zijn voor de manier waarop de data wordt opgeslagen. Bij het gebruik van de standaard log policy ben je bijvoorbeeld gebonden aan logbestanden op de server waarop de service staat. Bij custom log policies heb je echter de keus waar je de data wilt opslaan.

Er bestaan grofweg twee opties waar je, je logdata kunt opslaan. Namelijk in een logbestand of in een database. Beide hebben voor- en nadelen. Het voornaamste voordeel van een logbestand is dat het snel is te realiseren. Zowel de OSB als de SOA Suite beschikken over logmechanismes waar al dan niet gebruik van gemaakt kan worden. Daarnaast kan er weinig fout gaan bij het opslaan van logging op een filesysteem. Bij het wegschrijven van informatie naar een database kan het natuurlijk zijn dat deze tijdelijk niet beschikbaar is. Dit is natuurlijk erg vervelend vooral wanneer het informatie is die essentieel is bij het monitoren van je productie-omgeving. Hierdoor zul je ervoor zorg moeten dragen dat het wegschrijven van de logging naar de database zoveel mogelijk gegarandeerd wordt. Dit kan bijvoorbeeld door, zoals eerder beschreven, gebruik te maken van een jmsQueue.

Het grootste nadeel van logbestanden ten opzichte van de database is dat het doorzoeken van logbestanden lastiger is. Bij een database is het mogelijk om de logging gestructureerd op te slaan en daarmee kun je makkelijk en snel informatie opzoeken. Binnen een logbestand is dit niet mogelijk.

Om het doorzoeken van logbestanden toch efficiënt te doen kun je natuurlijk gebruik maken van tooling. Er bestaan verschillende tools waarmee je ongestructureerde data kunt inladen en vervolgens gestructureerd kunt doorzoeken. Een voorbeeld hiervan is Splunk (http://en.wikipedia.org/wiki/Splunk).

Conclusie

Logging is een belangrijk onderdeel van een servicelandschap. Hoe beter het logging mechanisme in elkaar zit hoe efficiënter je het landschap kunt beheren en dat is essentieel voor het succesvol zijn van een servicelandschap. Gezien elke organisatie en daarmee servicelandschapimplementatie verschilt zul je goed moeten kijken wat het doel is van je logging. Hierbij moet je goed kijken naar wat het minimale is wat je moet loggen om dit te bereiken. Bij het loggen van informatie hebben we namelijk snel de neiging om te veel op te slaan. Dit kan weer leiden tot inefficiëntie.

Zodra je het doel hebt vastgesteld kun je bepalen wat je wilt gaan loggen en hoe je het wilt doen. Hierbij heb je verschillende keuzes, het belangrijkste is om te kijken wat realistisch is. Je kunt de mooiste manier van loggen implementeren, waarbij de log informatie realtime automatisch wordt geanalyseerd. Echter wanneer er slechts 10 service calls per uur worden verwerkt is dit natuurlijk niet noodzakelijk.

Referenties

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.