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.