Mettez vos journaux là où l'hôte en feu ne peut pas les atteindre

L'affirmation

Des journaux qui ne vivent que sur la machine qui les a produits sont inutiles dans exactement la situation où vous en avez le plus besoin : quand cette machine a échoué. Le disque se remplit, l'hôte est terminé et remplacé, le conteneur est reconstruit, l'instance est compromise et vous ne pouvez plus rien y croire — et dans chacun de ces cas, le relevé de ce qui s'est passé disparaît avec la chose qui a échoué. Les journaux doivent quitter l'hôte à mesure qu'ils sont écrits, vers un endroit que la défaillance de l'hôte ne peut pas toucher, sinon vous tenez un journal intime que vous perdrez le jour venu.

Les défaillances qui effacent les journaux locaux

Quatre événements ordinaires détruisent les journaux sur l'hôte, et aucun n'est exotique. Un disque plein arrête l'application et corrompt souvent le journal même qui expliquerait pourquoi. Un groupe de mise à l'échelle ou un orchestrateur termine une instance malsaine et en démarre une neuve, emportant les journaux de l'instance défaillante — ceux qui décrivent la défaillance ayant déclenché la terminaison. Un redémarrage de conteneur efface tout ce qui n'est pas sur un volume monté. Et un hôte compromis signifie que vous ne pouvez pas croire ses journaux du tout, car la première chose que fait un intrus compétent est de les modifier. Dans chaque cas, le moment où vous cherchez les journaux est le moment où ils sont indisponibles.

Expédiez à mesure que vous écrivez

Le principe est qu'une ligne de journal devrait quitter l'hôte presque dès qu'elle est écrite, pour que la copie sur laquelle vous comptez vive déjà ailleurs avant que l'hôte n'ait la moindre chance d'échouer. Un relayeur léger lit le flux de journal et l'envoie en continu vers un collecteur central :

# Vector, un petit relayeur, lisant le journal et l'expediant
[sources.app]
type = "journald"

[sinks.central]
type = "loki"                      # ou elasticsearch, s3, un service heberge
inputs = ["app"]
endpoint = "https://logs.internal.exemple.ca"

Le relayeur tamponne localement pendant les secondes ou minutes qu'un pépin réseau peut durer, puis livre au retour du lien, de sorte qu'une brève panne de la destination des journaux ne perd pas de données et ne bloque pas l'application. Ce que vous achetez, c'est que la copie faisant autorité n'est jamais celle sur l'hôte — la copie de l'hôte devient une commodité, et sa perte devient survivable.

La journalisation centrale sert aussi à chercher à travers les hôtes

L'argument de reprise après sinistre est le titre, mais les journaux centralisés règlent un second problème qui surgit chaque jour : corréler un événement à travers plus d'une machine. Quand une requête traverse un répartiteur, deux instances applicatives et une base, son histoire est éparpillée sur quatre hôtes, et la reconstituer en se connectant à chacun tour à tour est lent dans le meilleur des cas et impossible pendant un incident où l'un d'eux est en panne. Un magasin central permet de les interroger tous à la fois :

{service="orders"} | json | req_id="01J2K9X4"
# une requete, chaque hote ayant touche la requete, dans l'ordre

C'est la même corrélation par identifiant de requête qui est difficile sur un seul hôte et impossible à travers plusieurs sans d'abord expédier les journaux vers un endroit commun.

Ce qu'il faut envoyer, et ce que jamais

Centraliser les journaux multiplie les endroits où ils existent et le nombre de personnes qui peuvent les lire, ce qui aiguise la règle sur ce qui appartient à un journal. N'expédiez jamais de secrets, de détails de paiement complets, de jetons de session, d'en-têtes d'autorisation ou de dossiers personnels complets — l'accident de journaliser un corps de requête entier en cas d'erreur devient bien plus grave quand ce corps aboutit dans un magasin central interrogeable que des sous-traitants et le personnel de soutien peuvent consulter. Structurez les journaux en JSON à champs nommés pour que le magasin central les indexe, gardez des identifiants et les quatre derniers chiffres plutôt que des valeurs, et décidez délibérément, dans une politique de conservation écrite, quelles données personnelles peuvent paraître et pour combien de temps.

Conservation et coût, décidés à dessein

La journalisation centrale a un coût que la journalisation sur l'hôte cache, et ce coût est assez réel pour être une décision plutôt qu'une surprise. Les services de journaux hébergés facturent typiquement au volume ingéré, et une application bavarde peut générer plus de gigaoctets par jour que prévu. Partagez la conservation selon la durée d'utilité réelle de chaque palier :

La plupart des recherches portent sur les derniers jours ; ne gardez donc que ceux-là chauds et indexés, et roulez le reste vers le stockage objet où un gigaoctet coûte quelques cents plutôt que la prime d'un magasin indexé. Cela garde la facture proportionnelle à la valeur de chaque palier.

Le test

Posez une question à votre configuration actuelle : si votre hôte le plus important disparaissait à l'instant — terminé, effacé, parti — pourriez-vous encore lire la dernière heure de ses journaux ? Si oui, vos journaux sont expédiés et vous êtes couvert. Si la réponse est que vous devriez d'abord récupérer l'hôte pour lire les journaux expliquant pourquoi l'hôte a échoué, alors votre journalisation est circulaire, et le jour où vous en avez le plus besoin est le jour où elle ne sera pas là.