Exploitation

Exploiter & Superviser

    Metrics & Endpoints


    Plusieurs métriques sont mises à disposition afin d’avoir des retours quantitatifs sur l’utilisation de Flower. Ces métriques sont mises à dispostion à travers :

    • une API REST
    • des MBeans JMX accessibles depuis une JConsole ou JVisualVM (avec le plugin MBean installé)

    Certains endpoints nécessite une authentification qui doit être fournie par un jeton utilisateur :

    • via un paramètre token de l’URL
    • via une en-tête HTTP token

    Health

    Un endpoint permettant d’avoir un aperçu sur la santé d’une instance de Core est exposé sur /health Ce endpoint ne nécessite aucune authentification.

    Connexions par profile

    Ces métriques permettent d’obtenir des informations sur les utilisateurs s’étant connecté pour un profile particulier. Pour obtenir ces métriques, il est nécessaire de disposer du rôle ADMIN.

    • /rest/metrics/profiles/{profile} : Liste les connexions pour un profile donné
    • /rest/metrics/profiles/{profile}/count : Compte les connexions pour un profile donné
    Paramètre Description
    start Paramètre facultatif permettant d’indiquer le début de la plage de date sur laquelle la mesure doit portée.
    Par défaut, ce paramètre est valorisé à 24 heures avant la fin de la plage de date. timestamp
    end Paramètre facultatif permettant d’indiquer la fin de la plage de date sur laquelle la mesure doit portée.
    Par défaut, ce paramètre est valorisé à l’instant présent. timestamp

    Exemple :

    GET http://localhost:8080/flower-docs-ws/rest/metrics/profiles/ALL_USERS?token=<token>
    

    Opérations

    Sur le endpoint /metrics un ensemble de métriques sont fournies notamment celles concernant les opérations effectuées au sein du Core Flower. Ces métriques sont nommées tel que scope.categorie.operation (en minuscule).

    Les métriques liées aux opérations nécessitent le rôle ADMIN.

    Exemple : Métriques de recherche de document

    GET http://localhost:8080/flower-docs-ws/rest/metrics/gec.document.search.*?token=<token>
    

    Gestion des logs


    Flower s’appuie sur la librairie Log4j 1.2 pour la gestion des logs applicatifs. Trois fichiers de configuration sont nécessaires, un par application WEB :

    • log4j.xml : configuration des logs de la GUI
    • log4j-core.xml : configuration des logs du Core
    • log4j-arender.xml : configuration des logs d’ARender HMI

    Appenders

    Un appender Log4j permet de configurer un type de sortie de log. Cette section décrit quelques uns des appenders possibles.

    Afin de pousser l’ensemble des logs dans la console (et/ou donc dans les fichiers de logs du serveur d’application), il suffit d’utiliser un ConsoleAppender. Par exemple :

    <?xml version="1.0" encoding="UTF-8" ?>
    <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
    <log4j:configuration debug="false" xmlns:log4j='http://jakarta.apache.org/log4j/'>
    	<appender name="consoleAppender" class="org.apache.log4j.ConsoleAppender">
    		<layout class="org.apache.log4j.PatternLayout">
    			<param name="ConversionPattern" value="%d{ISO8601} [%t] %-5p %c - %m%n" />
    		</layout>
    	</appender>
    	<root>
    		<level value="INFO" />
    		<appender-ref ref="consoleAppender" />
    	</root>
    </log4j:configuration>
    

    L’appender RollingFileAppender permet de pousser les logs dans des fichiers tournants : les logs sont écrits dans le fichier configuré jusqu’à atteindre la taille définie. Une fois la taille maximale atteinte, le fichier est renommé avec un nombre comme suffixe (seul les x derniers fichiers sont conservés).

    <?xml version="1.0" encoding="UTF-8" ?>
    <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
    <log4j:configuration debug="false" xmlns:log4j='http://jakarta.apache.org/log4j/'>
    	<appender name="flowerdocs" class="org.apache.log4j.RollingFileAppender">
    		<param name="append" value="true" />
    		<param name="maxFileSize" value="10MB" />
    		<param name="maxBackupIndex" value="3" />
    		<param name="file" value="C:\\logs\\FlowerDocs\\flowerdocs-core.log" />
    		<layout class="org.apache.log4j.PatternLayout">
    			<param name="ConversionPattern" value="%d{ISO8601} [%t] %-5p %c - %m%n" />
    		</layout>
    	</appender>
    	<root>
    		<level value="INFO" />
    		<appender-ref ref="flowerdocs" />
    	</root>
    </log4j:configuration>
    

    Les appenders peuvent ensuite être référencés avec la balise <appender-ref ref=<nom de l'appender> /> (voir plus bas).

    Niveaux de logs

    Flower et les librairies utilisées poussent des logs de plusieurs niveaux :

    • TRACE : niveau le plus fin d’information permettant d’obtenir des informations facilitant le debug (peut être activé suite à une demande du support)
    • DEBUG : niveau permettant d’obtenir des informations nécessaires au debug (peut être activé suite à une demande du support)
    • INFO : message données à titre d’information
    • WARN : messages d’avertissement
    • ERROR: erreurs interceptées par l’application


    Le niveau de logs peut être défini par package Java. Deux notions permettent de le configurer :

    • <root/> : configuration globale (ou par défaut) des logs

      <root>
          <level value="INFO" />
          <appender-ref ref="flowerdocs" />
      </root>
      
    • <category/> : configuration pour un package Java donné

      <category name="com.flower.docs">
          <priority value="INFO" />
          <appender-ref ref="flowerdocs" />
      </category>
      

    Pour modifier le niveau de log d’une configuration, il suffit donc de modifier, selon le cas, le noeud level ou priority avec les valeurs possibles (listées ci-dessus).

    Variables

    Sur une plateforme mutualisée ou tout simplement très utilisée, il peut être nécessaire de contextualiser les logs. Flower met donc à disposition des variables pouvant être affichées dans les messages de logs :

    • user : identifiant de l’utilisateur courrant
    • scope : identifiant du scope sur lequel l’utilisateur courrant est authentifié
    • request : identifiant unique de la requête émise (dans le cas d’une requête émise sur la GUI et propagée sur le Core, l’identifiant est conservé)

    Pour utiliser ces variables, il suffit de modifier le paramètre ConversionPattern du layout de l’appender considéré : %X{variable} comme par exemple :

    <param name="ConversionPattern" value="%d{ISO8601} [%t] %-5p %c %X{request} %X{scope} %X{user} - %m%n" />