Audit instances SOA 11g 4/4 : Use-case analyse

Cet article met fin à la série consacrée aux audits des instances SOA. Pour terminer nous allons illustrer l’utilisation des points précédents dans le cadre d’un cas pratique. Pas d’implémentation présentée ici, mais une problématique réelle, ainsi que la réflexion qui a abouti à une solution pratique.

Présentation du problème

Dans le cadre des développement, les services SOA sont au cœur des échanges. Il s’agit de la source d’information première lorsqu’un problème survient.
Lorsque des lenteurs se font sentir, il est nécessaire de déterminer où celles-ci ont lieu. Généralement, dans le cadre d’échanges synchrones, elles peuvent avoir plusieurs origines :

  • Transformations consommatrices
  • Service appelé lent (dû au volume échangé ? A un problème interne au service ? …)
  • Enchainement d’appel de services qui bout à bout donne une réponse dans des temps peu acceptables

Pour le déterminer, la manière la plus simple qui vient à l’esprit est de se rendre sur les instances dans l’Enterprise Manager et de regarder les informations à disposition.
Cependant plusieurs points peuvent rendre cette méthode longue, imprécise :

  • Ralentissement de la console pour accéder aux logs
  • Détermination de l’instance concernée dans un ensemble important d’instances difficile.
  • Temps peu précis dans les logs de la console (à la seconde près)

Enfin, l’analyse de performance d’un service n’est pas possible de manière générale : on a des informations sur les performances depuis le démarrage serveur, mais pas de possibilité pendant une période horaire. Si le serveur ne vient pas de redémarrer, un ralentissement temporaire ne se verra pas par ces informations.

Le principe

Nous avons vu dans les précédents articles comment récupérer les audits des instances d’un composite. Finalement, ils contiennent toutes les informations que l’on aurait eu via la console, et ceci avec certainement plus de précisions (temps).
Cette solution part tout d’abord d’une hypothèse, pas forcément totalement fondée, mais que l’on utilise à la lecture de la console. En effet chaque élément d’audit fait référence à une date/heure dans la console. On peut donc supposer que le temps entre la précédente étape, et l’étape en question correspond à son temps de réalisation approximatif.
En partant de cette hypothèse, et en regardant des exemples d’audit en base, on se rend compte que les date/heure dans les audits sont en fait des timestamp allant jusqu’à la milliseconde. Cette information peut se révéler importante :
L’appel de ce service a eu lieu entre le 07/09/2013 à 10h00m10s et 07/09/2013 à 10h00m11s… cela a pris donc pris entre presque 2 secondes (10.001s à 11.999) et quelques ms (10.999 à 11.001)…. Pas très précis… et totalement inutile pour déterminer une lenteur légère.
Le principe de ce use-case a donc été d’utiliser les audits présent en base pour déterminer les temps par composants, et par étape du composant.
Des filtres ont été mis en place pour limiter la recherche au niveau des volumes :

  • Composite DN
  • Date de début
  • Date de fin
  • Liste de composite instance ID

Des options ont également été mises en place pour rechercher plus ou moins précisément dans les logs, pour des questions de performances principalement. Ainsi on pourra :

  • Etape 1 : s’intéresser aux temps généraux des composites. Cela nous permettra de déterminer quelques cas à analyser plus précisément, et une visualisation sur une large période des temps mis par les instances.
  • Etape 2 : s’intéresser aux temps des composants pour ces composites : où dans ces composites consomme-t-on le plus ?
  • Etape 3 : Une fois les instances de composants problématiques identifiées, on pourra aller plus profondément en obtenant les temps par étape des médiators, des BPEL.
  • Etape 4 : Enfin on pourra unitairement (ou presque) récupérer l’audit complet d’un composite, et ainsi visualiser les données échangées exactement.

De cette manière nous avons à présent une solution simple d’utilisation, qui nous permet une analyse générale, ou plus ciblée.

Aller plus loin !

BPEL : les sensors DB

Les processus BPEL permettent la mise en place de sensors, avec notamment une publication possible en base de données.
Ces sensors peuvent fournir le temps d’une étape du processus. La mise en place de ceux-ci sur les étapes clefs du processus permet de s’abstraire de l’audit du BPEL et n’avoir que les étapes intéressantes remontées.

Performances

Notre batch récupère un certain nombre d’information concernant les délais de différentes instances.
Un traitement de toutes ces données nous permet d’avoir un rapport déterminant (suivant le niveau de détail précisé par nos options) :

  • Les temps minimum, maximum, moyen par composite/opération, ainsi que par sous-composant / étape.
  • Les même informations par instances.

Conclusion

Au travers de ce use-case, nous avons pu voir une utilisation pratique de l’accès aux audits, avec une vrai valeur ajoutée dans nos opérations d’analyse journalières.
En allant plus loin avec le rapport de performances nous pouvons jauger plus rapidement les points de contention que l’on pourrait rencontrer.
Bien sûr, le pré-requis principal reste que les logs doivent être activés (selon le niveau de détail que l’on souhaite). Des logs en niveau :

  • off : rendent cette utilisation presque impossible
  • production : limité à une analyse générale
  • development : utilisation complète

Au final, c’est un outil pratique, utilisable lorsque le serveur est down, avec une analyse possible à postériori (suite à un test de charge), tout un ensemble d’avantages non négligeables !
Un point d’attention tout de même : à ne pas utiliser sur un environnement de production ou très sollicité (ou en de manière très limité) pour éviter tout risque de comportement anormal dû aux interrogations de la base, qui pourrait entrainer des ralentissements sur un serveur critique.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *