Architecture

La gateway (ou historian server) est implémenté avec vertx. Ce serveur propose une API REST que le grafana-historian-datasource utilise pour tracer les graphes dans Grafana. Cela implique que ces deux modules sont étroitement liés, si on modifie l’api de la gateway cela aura un impact sur la datasource Grafana et vice versa.

La datasource est implémentéé en utilisant javascript, le projet github correspondant est disponible [ici](https://github.com/Hurence/grafana-historian-datasource), nous recommendons de développer ce plugin directement dans son propre projet. Une fois que vous avez poussé vos modifications dans le projet de la datasource, vous pouvez mettre à jour le sous module dans ce projet avec la commande suivante :

Cela va automatiquement mettre à jour le projet avec le dernier commit du projet du sous module.

C’est un module qui sert à partager des classes. Il est utilisé par la gateway (le serveur historian) mais aussi d’autres modules. Par exemple le module loader. Cela évite de devoir embarquer la dépendance sur la gateway (qui contient beaucoup de choses).

Ce module contient des utilitaires pour faire des tests d’intégration. Il contient notamment des extensions junit5 pour Spark et pour Solr. L’extension pour Solr utilise les libraries [testcontainers](https://www.testcontainers.org/), pour constituer un cluster Solr avec docker compose. Ce module contient également dans ses ressources les configurations nécessaires pour créer les différentes collections utilisées par notre historian.

Le loader contient des jobs batch. Pour l’instant ce module ne contient qu’un unique job qui sert a recompacter les chunks de l’historian avec différentes tailles paramétrables (le compacteur). Par exemple lors de l’injection temps réel dans le data historian, on injecte des chunks de petites tailles. Hors, pour optimiser les performances nous avons besoin de chunks de grosses tailles. De plus selon le type de requêtes effectuées et la fréquence des measures pour une métrique donnée , pouvoir jouer sur la taille des chunks, et la faire varier selon le cas d’usage, est très important.

Par exemple si l’on fait des requêtes sur de grandes périodes, nous avons besoin de gros chunks pour gagner en performance. En effet nous n’aurons même pas besoin de décompresser ces chunks, utiliser leur agrégation précalculée sera suffisant. D’ailleurs ce job de recompaction pourra également servir de base pour nous permettre dans le futur de rajouter de nouvelles agrégations pré-calculées si nécessaire, ou bien de rajouter n’importe quelle information qui nous paraît nécessaire.

Le compacteur utilise Spark et Solr.

Ce module contient des processeurs logisland utilisant la librarie timeseries. Ces processeurs manipulent des timeseries. Certains sont utilisés pour compacter des données dans le compacteur. A terme, il serait bien de supprimer ce module et de n’utiliser que des outils présents dans le module timeseries. En effet il ne paraît pas nécessaire d’embarquer des logiques métier logisland dans l’historian.

C’est une librarie qui permet de manipuler les métriques d’une manière générale. On peut par exemple les compresser et calculer des pré agrégations.