Easysoa integration architecture monitoring platform - easysoa/EasySOA GitHub Wiki
TODO translate fully
- Computes business indicators from technical service events according to EasySOA-known SLA configuration
- Displays business indicators back in EasySOA Dashboard, for CIOs
- also Jasmine console (configured) for technical operators
NB. à propos d'indicateurs monitoring etc. : voir WSLA ex. http://clip.dia.fi.upm.es/Projects/S-CUBE/.../keller03:wsla_framework.pdf
sauvé dans model :
- que les indicateurs haut niveau BS et IS ("indicateurs de santé de service")
- plus l'URL Jasmine Portal sur la plateforme d'exploitation operation_platform de l'endpoint / du projet
un indicateur est :
- service level health (ex. vert si gold, orange si silver, rouge si bronze),
- service level violation (rouge si violation),
- période sur laquelle est défini l'indicateur
- NB. rattachés sur SLA ou OLA
EasySOA Service Level Indicators dashboard UI : (for a Project + Environment) lists InformationServices (per BusinessService...) and their
- service name,
- SLA ou OLA name,
- environnement,
- noms client et fournisseur,
- indicateur : dans période fournie par l'utilisateur (OPT navigation paginée), par défaut : de la journée
Feeding Jasmine with events :
- Talend SAM database & Adapter probe : production SOA solution fills SQL database with technical events, using the Talend SAM (Service Activity Monitoring) format (*). Jasmine EasySOA Adapter looks in Talend SAM database, fills it in Jasmine database.
- Other Jasmine probes may be used to fill Jasmine with events.
In Jasmine :
- these technical events are processed by rules according to SLA technical configuration which produces business indicators.
- Jasmine sends these business indicators to EasySOA Registry which stores them, and is now able to display them in SOA Dashboard UI.
(*) To feed it :
- use Talend ESB SAM feature activated as SOA solution
- or use EasySOA HTTP Proxy or FraSCAti or FraSCAti Studio with https://github.com/easysoa/EasySOA/tree/master/easysoa-proxy/easysoa-proxy-intents/easysoa-proxy-intents-cxfMonitoringIntent (prototype, doesn't fill the MI_MESSAGE_ID & MI_FLOW_ID fields so can't compute SOA latency)
- or write your own service intercepting probe, see Talend SAM (Service Activity Monitoring) database format at http://www.liquid-reality.de/display/liquid/2011/05/25/Monitoring+your+CXF+Services+Calls+with+Talend+ESB+Standard+Edition and architecture analysis at the bottom of https://github.com/easysoa/EasySOA/wiki/Final-monitoring-design .
ses infos sont mashupées par les règles d'Alain avec les autres, dans le cadre d'un indicateur classique
=> TODO Q ccarbone quelle sonde JMX, où est-elle ?
Matcher l'event Talend avec le modèle EasySOA :
- sur l'url de l'Endpoint (étant donnés l'id nuxeo du sous-projet de déploiement et l'environnement)
- Talend SAM database provides fields :
- ORIG_HOSTNAME ex. "owsi5", ORIG_IP (comprenant le port) ex. "127.0.1.1",
- MI_PORT_TYPE ex. "{http://www.axxx.com/dps/apv}PrecomptePartenaireService"
- (and MI_OPERATION_NAME ex. "{http://www.axxx.com/dps/apv}creerPrecompte"). See other fields at http://www.liquid-reality.de/display/liquid/2011/05/25/Monitoring+your+CXF+Services+Calls+with+Talend+ESB+Standard+Edition
- about these fields :
- => TODO Q Bull ou Talend champ ORIG_IP : l'IP est elle locale (127.*) ? Si oui, comment configurer la bonne valeur ?
- => TODO Q Bull ou Talend de même pour les autres champs, le format donné dans les exemples ci-dessus est-il correct ??
- => TODO Q ccarbone (pas besoin ici mais) où est le port TCP, dans ORIG_HOSTNAME et / ou ORIG_IP ?
- => TODO Q ccarbone pas d'URL, (pas besoin ici mais) alors quid si plusieurs implémentations du même portType sur le même hôte ?? Faut-il rajouter des CustomKey (remplies par custom handler ex. https://github.com/Talend/tesb-rt-se/blob/83011aebc68c67cb177ff7e800afbe9bbcab7049/sam/sam-common/src/main/java/org/talend/esb/sam/common/handler/impl/CustomInfoHandler.java )
- solution la plus simple en l'état :
- avoir côté Jasmine une map : ORIG_HOSTNAME (ou sinon ORIG_IP) + MI_PORT_TYPE => identifiants de l'élement du modèle EasySOA (i.e. endpoint et SLA/OLA). NB. ces deux champs de la base correspondent grossièrement aux éléments "provider" et "service" de la configuration EasiFab "historique".
- cette map doit avoir été obtenue à partir du modèle EasySOA. Dans un premier temps elle peut être établie manuellement dans un fichier de configuration .properties. Ensuite elle sera obtenu en appelant le SimpleRegistryService qui retourne : endpointUrl + TODO OW wsdlPortType, et en déduisant de l'endpointUrl ORIG_HOSTNAME ou ORIG_IP.
- elle peut alors être exploitée pour obtenir, à partir d'une ligne de la base Talend SAM, l'endpoint et le SLA/OLA pour lesquels remonter un indicateur.
Matcher l'indicateur métier aggrégé avec le modèle EasySOA : retrouver à la fois
- l'Endpoint : id nuxeo du sous-projet de déploiement (versionné) + environnement + url endpoint (requis pour matching Talend) OU id EasySOA métier du service (requis pour affichage en console Jasmine). Ou seulement par l'id nuxeo versionné de l'Endpoint, plus performant pour EasySOA (ou n'importe lequel entre ces deux extrémités).
- le SLA ou OLA : id nuxeo du sous-projet de déploiement (ou de spécifications) + id EasySOA métier du SLA ou OLA (requis pour affichage en console Jasmine). Ou seulement par l'id nuxeo versionné du SLA/OLA (ou n'importe lequel entre ces deux extrémités). NB. un seul SLA sur BusinessService, plusieurs OLA sur InformationService.
La configuration technique assemblée en mémoire Jasmine comprend donc, pour chaque SLA/OLA :
- id nuxeo du sous-projet de déploiement (versionné)
- environnement
- url endpoint
- id nuxeo versionné de l'Endpoint
- id EasySOA métier du SLA ou OLA
Cette configuration technique est
- dans un premier temps : écrite (toutes ces propriétés) à la main à partir des infos du modèle EasySOA
- (OPT on pourrait écrire un template Nuxeo générant un début de fichier de configuration technique avec que les identifiants EasySOA)
- OPT dans un deuxième temps : étant donné un id de sous-projet de déploiement versionné, Jasmine récupére la première fois tous les fichiers SLAs & OLAs plus les identifiants EasySOA et endpointUrls et les assemble en un fichier de configuration technique
- se fait par une recherche dans Nuxeo en NXQL, envoyée par l'API REST Automation
- OPT plutôt envoyée par un service REST à développer, qui retourne non pas les informations mais un fichier de configuration technique généré (à partir d'un template ex. freemarker)
Sending aggregated business indicators to EasySOA :
- done by Jasmine EasySOA Adapter calling EasySOA's EndpointStateService.updateSlaOlaIndicators()
- using Jersey client. NB. not in Jasmine out of the box but already used elsewhere, perfectly appropriate : also used by Nuxeo, several options for authentication (see technical analysis below)
- in a first time, only Basic authentication ("Administrator:Administrator")
- OPT then : trusting authenticator if developed for FraSCAti Studio, else TLS/SSL if FraSCAti is embedded in Nuxeo. NB. OAuth 2-legged support is too limited in Nuxeo (supports POST only for web forms).
UPDATE 20121217 see source of
- service definition at https://github.com/easysoa/EasySOA-Incubation/blob/master/easysoa-registry-v1/easysoa-registry-rest-core/src/main/java/org/easysoa/registry/rest/integration/EndpointStateService.java
- service implementation (update, but also paginated getters) at https://github.com/easysoa/EasySOA-Incubation/blob/master/easysoa-registry-v1/easysoa-registry-rest-server/src/main/java/org/easysoa/registry/integration/EndpointStateServiceImpl.java
- how to use it remotely using Jersey client in test https://github.com/easysoa/EasySOA-Incubation/blob/master/easysoa-registry-v1/easysoa-registry-rest-server/src/test/java/org/easysoa/registry/integration/EndpointStateServiceTest.java
- (ONLY DONE FOR SIMPLEREGISTRYSERVICE FOR NOW) how to use it remotely using FraSCAti or CXF clients in tests https://github.com/easysoa/EasySOA-Incubation/tree/master/easysoa-registry-v1/easysoa-registry-integration-base/src/test/java/org/easysoa/registry/integration
- TODO OW UI in nuxeo webengine using said (paginated) getters
updateSlaOlaIndicators({endpointId, slaOrOlaName, timestamp, serviceLevelHealth=gold/silver/bronze, serviceLevelViolation=true/false})
- endpointId et slaOrOlaName sont à récupérer du modèle EasySOA des Specifications et mettre dans la configuration de la plateforme de monitoring (d'abord manuellement puis récupérés automatiquement au démarrage étant donné l'id du sous-projet de déploiement versionné)
get[Daily/Paginated/InPeriod]Indicator(s)(slaOrOlaId, [paramètres selon besoin UI])
- pouvoir rentrer une période (OPT navigation paginée), par défaut : de la journée
Il faut configurer un SQL Directory (mais sans fichier .csv qui ne sert qu'à initialiser le contenu, ce dont on n'a pas besoin ici), voir doc http://doc.nuxeo.com/display/NXDOC/Directories+and+Vocabularies
Voici un exemple de configuration avec juste ce dont on a besoin :
XXXX java:/nxsqldirectory 3600 1000 XXXXoù XXX est un schema .xsd définissant les champs requis, à l'image de ceux définissant les champs documentaires
Cela doit être défini dans une contribution dans easysoa-registry-rest-server/src/main/resources/OSGI-INF et raccrochée dans easysoa-registry-rest-server/src/main/resources/META-INF/MANIFEST.MF (voir comment dans easysoa-registry-doctypes-core/src/main/resources/META-INF/MANIFEST.MF ). Voir un exemple d'une telle contribution dans easysoa-registry-doctypes-core/src/main/resources/OSGI-INF/directory-contrib.xml , et un autre avec des choses dont on n'a pas besoin mais dans son contexte : http://explorer.nuxeo.org/nuxeo/site/distribution/current/viewExtensionPoint/org.nuxeo.ecm.directory.sql.SQLDirectoryFactory--directories
Ensuite, il faut utiliser programmatiquement DirectoryService (Framework.getService(DirectoryService.class)) qui donne accès à la Session, laquelle permet de gérer les données : getEntry(), query(), createEntry()... IMPORTANT il faut ouvrir et fermer la session, donc : storeIndicators() { openSession(); addRows(); closeSession(); }
TODO akervern enrichit les méthodes Session.query() pour les permettre sur des périodes (date range) et de pagination (limit et offset) donc pas des critères exacts. Elles ont déjà des Filter qui permettent des critères exacts, à utiliser pour les slaOrOlaName, endpointId...
- réalisation : dans Nuxeo, par AuditLog
- accroché à endpointDocId et slaOrOlaName
- TODO Q tdelprat sauver : NXAuditEventService newLogEntry(), newExtendedInfo(), addLogEntries() ; principalName, eventId (none ? required ??), date (timestamp ??), docUUID (slaOrOlaId, env voire (if not live) versioned endpointId), docPath docType docLifeCycle repositoryId (auto ?), category (string ex. easysoa.endpointState), extendedInfos (timestamp, slh, slv), comment
- TODO Q tdelprat OU BIEN créé par Event, quoi renseigné alors ?? comme dans https://github.com/nuxeo/nuxeo-platform-audit-web-access/blob/master/src/main/java/org/nuxeo/ecm/platform/audit/web/access/WebAccessLogActionListener.java
- lister : tous, HQL query on what was logged (extendedInfos)... voir http://community.nuxeo.com/5.3/books/nuxeo-book/html/audit-service.html NXAuditEventService audit = Framework.getService(NXAuditEventService.class); List entries = audit.getLogEntriesFor(document.getDocUUID()); entries = audit.nativeQueryLogs("log.docPath like '/somefolder/%' and log.extendedInfos['slaOrOlaId']='anUid'", 1, 10)
- TODO Q tdelprat lister : performances ? plutôt event=easysoa.endpointState and category=(versioned)deplProject+slaOrOla+env(ids) ??
- TODO Q tdelprat purge : quelle purge pour les AuditLogs ? le rendre tournant / borné ?
- UI : dashboard décrit plus haut, utilisant EndpointStateService.getIndicators()
- OPT dashboard UI graphe de l'évolution des indicateurs
- In a first time there will be no authentication until it works.
- Then auth will be added in the chosen solution, which must therefore support it.
About Nuxeo auth : see https://github.com/easysoa/EasySOA/wiki/Easysoa-integration-architecture---development-platform
Quelques pistes :
- client HTTP - Apache HTTPClient : supporte BasicAuth, TLS/SSL, 2-legged OAuth (avec signpost http://code.google.com/p/oauth-signpost , voir http://forum.springsource.org/showthread.php?103067-How-to-configure-2-Legged-OAuth ), 3-legged OAuth (voir http://www.ibm.com/developerworks/web/library/wa-oauthsupport/index.html )
- client HTTP OAuth - Scribe : supporte 2-legged OAuth ex. http://devlog.bafford.us/two-legged-oauth-in-java-using-scribe-to-acce , sinon voir https://github.com/fernandezpablo85/scribe-java/wiki/getting-started )
- utilisé par FraSCAti Studio pour appeler Facebook etc. voir http://websvn.ow2.org/filedetails.php?repname=frascati&path=%2Ftrunk%2Ffrascati%2Ffrascati-studio%2Fsrc%2Fmain%2Fjava%2Forg%2Feasysoa%2Fcatalog%2FFacebookCatalogServices.java
- client JAXRS - CXF : supporte BasicAuth, OAuth (voir http://cxf.apache.org/docs/jax-rs-oauth.html#JAX-RSOAuth-2legOAuthFlow ), TLS/SSL. Utilisable par JAXRSClientFactory.create(serverUrl, MyService.class) (voir FraSCAtiStudio DeployProcessor) et de la configuration programmatique.
- client JAXRS - FraSCAti : supporte (au-dessus de CXF) BasicAuth, TLS/SSL (voir https://github.com/easysoa/EasySOA/issues/27 ), pas OAuth mais TODO
- client JAXRS - Jersey :
- utilisé par les proxy OW de découverte pour appeler le DiscoveryService en BasicAuth
- helper : ClientBuilder https://github.com/easysoa/EasySOA-Incubation/blob/master/easysoa-registry-v1/easysoa-registry-rest-client/src/main/java/org/easysoa/registry/rest/client/ClientBuilder.java
- exemple d'utilisation : chercher registryApi.post dans https://github.com/easysoa/EasySOA/blob/master/easysoa-proxy/easysoa-proxy-core/easysoa-proxy-locator-mock-server/src/main/java/org/easysoa/proxy/cxflocator/DiscoveryProxyLocatorServiceImpl.java
- supporte BasicAuth, OAuth voir Jersey OAuthClientFilter :
- doc https://wikis.oracle.com/display/Jersey/OAuth
- exemple http://blog.alutam.com/2009/08/10/using-jersey-client-oauth-support-with-smugmug/
- source https://svn.java.net/svn/jersey~svn/trunk/jersey/contribs/jersey-oauth/oauth-client/src/main/java/com/sun/jersey/oauth/client/OAuthClientFilter.java
- javadoc http://jersey.java.net/nonav/apidocs/latest/jersey/contribs/jersey-oauth/oauth-client/com/sun/jersey/oauth/client/OAuthClientFilter.html
NB. comment rajouter le support OAuth à un client HTTP : l'enrichir en utilisant signpost comme fait pour HTTPClient, voir http://code.google.com/p/oauth-signpost/source/browse/trunk/signpost-commonshttp4/src/main/java/oauth/signpost/commonshttp/CommonsHttpOAuthConsumer.java?r=64