---
tags: datastage, dsevents
title : dsevents - livre blanc
description: Livre blanc outil dsevents
---
# Observabilité pour DataStage

[toc]

## But
Il s'agit pour les environnements DataStage de
* superviser l'activité (exécutions des jobs, statuts...)
* être en capacité d'analyser les logs / traces et déclencher les bonnes alertes
* contextualiser avec des métriques systèmes
* utiliser pour cela les outils standards et éprouvés

## Méthodes classiques
Les logs et traces DataStage sont écrites de manière immédiate dans la base Universe et consultables depuis le client lourd Director.
Elles sont également remontées dans une base de données (Db2, Oracle ou SQL Server) sur laquelle s'appuie la console d'opération.
A côté de cela des outils tiers permettent de surveiller et collecter les métriques du serveur (consommation cpu, mémoire etc...).

De manière générale on constate que s'il y a bien une supervision des systèmes, celle-ci est rarement rapprochée avec l'état des traitements DataStage ou mis à disposition des équipes opérationnelles.

Classiquement il était possible de développer et intégrer dans DataStage les instructions permettant d'exporter les traces dans des fichiers ou en base de plusieurs manières, au fil de l'eau ou à posteriori des traitements.
Cela pose notamment les problèmes de l'adhérence entre traitements opérationnels et traitements dédiés à l'observabilité, de la nécessité de répliquer le code sur les différents projets, de l'impact en termes de performances et le risque d'erreur provoquée par ce code.

De préférence il est également possible d'exploiter la base de données, construire des rapports sur celle-ci ou en extraire les données.

Toutes ces méthodes posent différents problèmes et imposent de mettre en place d'autres outils ou développements pour pouvoir réellement contextualiser ces traces avec des métriques serveur, intégrer des fichiers plats, extraire les données de la base et alimenter une autre base ou un outil d'indexation etc...
Par ailleurs s'appuyer directement sur les données produites par DataStage impose de les conserver un certain temps avec potentiellement des impacts en stockage ou performance.

## Exemple d'exploitation de la base de l'operation console

Une des références en termes de supervision d'environnements et d'indexation de logs est la stack ElasticSearch:
* Grâce à l'utilitaire MetricBeat on collecte les métriques système du serveur
* Grâce à l'utilitaire Logstash on peut extraire les information de la base, alimenter un index ElasticSearch, et éventuellement alimenter une autre base pour d'autres restitutions.

Cette architecture est relativement efficace mais repose sur la stack ElasticSearch, des composants issus de la communauté Open Source et un paramétrage parfois un peut complexe.
Si on souhaite par exemple utiliser d'autres outils de supervision (tels que Prometheus) des développements spécifiques seront nécessaires.

## Proposition

Un service qui permette de collecter les logs et traces DataStage extérieur à DataStage lui-même et qui soit capable d'alimenter divers outils de supervision.

### Comment
La base de l'operation console est alimentée par des fichiers "événements" générés par le moteur DataStage, ceux-ci sont capturés et traités pour charger la base puis supprimés.


Le service proposé intercepte ces fichiers, applique les filtres et transformations paramétrées et les route vers des connecteurs dédiés aux divers outils choisis.

### Connecteurs

Les connecteurs inclus dans le service sont actuellement:
* console/sortie standard (debug)
* logs rotatives agrégées (fichiers plats)
* ElasticSearch (indexation des logs)
* Prometheus (métriques)
* Kafka (streaming)
* Redis (pubsub, métriques/TimeSeries, graphes, streams)
* e-mail (alertes)
* Jaeger (traces)
* api arbitraire

Par ailleurs un système de cache (en mémoire ou Redis) permet d'accéder à des événements antérieurs pour enrichir les données.

Il est possible de développer des connecteurs additionnels à la manière de plugins, actuellement les connecteurs additionnels ci-dessous ont été développés:
* Sentry (alertes et erreurs)
* InfluxData (supervision et métriques en ligne)
* HonneyComb (traces en ligne)

### Architecture


## Exemples

### Prometheus

Avec Prometheus et Grafana on observe les métriques des traitements DataStage, contextualisées avec les métriques systèmes des serveurs (DataStage, bases de données etc...).
Ceci permet de surveiller en temps réel l'état des plateformes à instant t, leur évolution sur une période données et déclencher des alertes selon des critères définis.



### Jaeger

Avec Jaeger on retrouve les traces des traitements et leur hiérarchie, jusqu'au stage. On peut ainsi identifier des goulots d'étranglement, ou accéder aux logs des traitements.


### Kafka

En écrivant les informations dans un ou plusieurs topics Kafka, on peut les diffuser/streamer rapidement vers d'autres systèmes ou applications.


### ElasticSearch

ElasticSearch combiné à Kibana permet de retrouver les logs des traitements ainsi que de contextualiser les métriques DataStage avec celles du système.


### Redis

En fonction des modules activés sur Redis, plusieurs applications sont possibles.

#### Mise en cache

L'application la plus basique est la mise en cache des événements pour pouvoir enrichir d'autres événements. Ceci est également possible sans Redis mais avec un impact sur la mémoire utilisée.


#### TimeSeries

En stockant les métriques dans Redis TimeSeries on peut construire des tableaux de bords à la manière de Prometheus.


#### Graph

On peut construire le graphe des dépendances entres jobs grâce à Redis Graph.


#### PubSub

Avec Redis PubSub on peut publier les événements dans un canal auquel d'autres applications peuvent souscrire pour être alertés en temps réel.


#### Streams

De la même manière que Kafka on peut exploiter Redis Streams pour streamer les événements.


### Log rotatives

Exemple de logs agrégées dans un fichier rotatif par date:

2020-08-12 08:05:45.881 TRACE dstage1:NR_Test->Starting
2020-08-12 08:05:45.941 TRACE dstage1:NR_Test->Queued
2020-08-12 08:05:46.443 TRACE dstage1:NR_Test->Running
2020-08-12 08:05:46.641 INFO  dstage1:NR_Test->Control Starting Job NR_Test.
2020-08-12 08:05:47.358 FATAL dstage1:NR_Test->Running with fatals main_program: Error parsing modify adapter: Error in binding: Expected destination field selector, got: ";"; input: ;
2020-08-12 08:05:58.379 INFO  dstage1:NR_Test->Control Job NR_Test aborted.
2020-08-12 08:05:58.772 FATAL dstage1:NR_Test->Finished aborted

### Api

Exemple d'alerte déclenchée dans GitLab lorsqu'une erreur est rencontrée.


### Sentry

Avec le connecteur Sentry des alertes sont automatiquement créées lorsqu'une erreur est rencontrée. Les alertes sont enrichies avec les paramètres, variables d'environnement, stack d'exécution...