Logs applicatifs

Au-delà des exceptions, le SDK peut transmettre les messages de log de votre application à Quiet Guard. C'est opt-in et cela ajoute au plus un appel HTTP par requête.

Activation

La transmission des logs est désactivée par défaut. Activez-la et choisissez un niveau minimum :

MONITOR_LOGS_ENABLED=true
MONITOR_LOG_LEVEL=warning
MONITOR_LOGS_MAX_BATCH=200

Le hook de logs ne s'active que si toutes ces conditions sont réunies : le SDK est activé (MONITOR_ENABLED=true), les logs sont activés (MONITOR_LOGS_ENABLED=true), et MONITOR_URL comme MONITOR_KEY sont définis. Sinon le listener n'est jamais enregistré et il n'y a aucun surcoût.

Fonctionnement

Le SDK écoute l'événement MessageLogged de Laravel. Chaque message au niveau configuré ou au-dessus est bufferisé en mémoire pendant la requête puis envoyé une seule fois, en un seul batch, vers l'endpoint /api/v1/logs du serveur.

L'envoi (flush) a lieu à la fin de l'unité de travail :

• à la terminaison de l'application pour les requêtes HTTP et les commandes console ;
• après chaque job en file (JobProcessed et JobFailed), car les workers de file de longue durée ne se terminent jamais entre deux jobs.

Si le buffer atteint MONITOR_LOGS_MAX_BATCH entrées (200 par défaut) en cours de requête, il est vidé de façon anticipée afin que rien ne soit silencieusement perdu.

Niveaux

Le niveau minimum est un niveau PSR-3 standard. Tout ce qui est à ce niveau ou au-dessus (en sévérité) est capturé :

debug < info < notice < warning < error < critical < alert < emergency

Avec la valeur par défaut MONITOR_LOG_LEVEL=warning, les entrées warning, error, critical, alert et emergency sont transmises ; debug, info et notice sont ignorées. Une valeur de niveau non reconnue échoue en sécurité (elle capture moins, pas plus).

Ce qui est capturé, et ce qui ne l'est pas

Chaque entrée transmise contient : level, message, context masqué, environment, release et logged_at (ISO 8601).

Deux types d'entrées sont délibérément ignorés :

• Les entrées de log portant une exception (un context['exception']): déjà prises en charge par le pipeline d'exceptions ; les transmettre aussi en logs créerait des doublons.
• Les logs d'échec internes du SDK: marqués d'un drapeau interne pour qu'une erreur de transport ne puisse jamais se réinjecter dans le buffer de logs (pas de boucle de rétroaction).

Les valeurs de contexte passent par le même masquage que les exceptions, et les valeurs de contexte non scalaires sont normalisées en une forme sérialisable en JSON avant l'envoi.

Envoi en arrière-plan

Lorsque MONITOR_QUEUE est défini, le batch est dispatché comme job en file SendLogsToMonitor (2 tentatives) plutôt qu'envoyé en ligne. Voir Configuration.

Note sur le forfait

Les logs applicatifs sont une fonctionnalité payante côté serveur et comptent dans votre quota d'événements. Si votre forfait n'inclut pas les logs, le serveur rejette le batch ; le SDK avale cette réponse sans affecter votre application. Voir la documentation du serveur.