Abyss Monitor
@abyss-project/monitor
Supervision applicative : logs, événements, alertes, Sentinels et Cron Tasks.
Application monitoring: logs, events, alerts, Sentinels and Cron Tasks.
Installation
npm install @abyss-project/monitor
# or
pnpm add @abyss-project/monitor
Liens
- Documentation : https://docs.abyss-project.fr/monitor
- NPM : @abyss-project/monitor
- Swagger : https://monitor-api.abyss-project.fr/swagger
- Application Abyss : app.abyss-project.fr
- Statut des services : status.abyss-project.fr
Usage
Voir la documentation produit pour les guides d'utilisation, la configuration du Core, les exemples d'appel et la référence des permissions.
Livraison fiable des logs
Depuis la version portant le pipeline de logs fiable (SP-1), le Logger n'envoie plus un POST par
ligne : les logs sont mis en file, regroupés en lots (100 lignes ou 1 Mo, toutes les 500 ms) puis
envoyés à POST /application-log/:applicationId/bulk. En cas de coupure réseau ou de crash du process,
les lots en attente sont conservés sur disque et rejoués, et un lot rejoué est dédupliqué côté serveur
par clientLogId. Ce qui peut encore se perdre est borné : les lignes jetées par une file saturée
(10 000 lignes ou 32 Mo en mémoire), évincées d'un spool plein (64 Mo) ou refusées définitivement par
le serveur sont comptées, et ce nombre est remonté au serveur avec le lot suivant ; les lignes encore en
mémoire quand le process est tué sans arrêt propre (SIGKILL, OOM) — celles émises depuis le dernier
flush, 500 ms d'ordinaire, davantage pendant un envoi en cours — meurent avec lui sans être comptées.
AbyssMonitorCore.setConfig({
// ... vos options habituelles
shipper: {
spoolDirectory: '/var/lib/my-app/abyss-monitor-spool', // ou ABYSS_MONITOR_SPOOL_DIR
},
});
Sur Kubernetes/k3s, le répertoire par défaut (le répertoire temporaire du système) ne survit pas à un
redémarrage de conteneur : montez un volume sur le chemin donné à ABYSS_MONITOR_SPOOL_DIR pour que les
logs en attente survivent au redémarrage. Un emptyDir survit au redémarrage d'un conteneur, pas au
remplacement du pod (déploiement, drain d'un nœud) : seul un volume persistant couvre ce cas. Chaque
application écrit dans son propre sous-dossier, <ABYSS_MONITOR_SPOOL_DIR>/<applicationId>/.
Dans les tests d'un service consommateur, désactivez le spool — shipper: { spoolDirectory: null }
— ou pointez ABYSS_MONITOR_SPOOL_DIR vers un répertoire temporaire propre au run : sinon les tests
écrivent dans le spool réel de la machine. Un process qui n'appelle jamais setConfig avec un
applicationId et un secretPublishToken garde ses logs en mémoire, jusqu'à 10 000 lignes ou 32 Mo,
en attendant une identité qui ne vient pas.
Détails complets — options du shipper, contrat de l'endpoint bulk, ce que la fiabilisation garantit
et ne garantit pas — dans la documentation du Logger.
Support
Pour toute demande, ouvrir un ticket depuis l'application Abyss.