Où un package / opt doit-il écrire des journaux?

J'installe un package personnalisé dans /opt/package_name, stockant les fichiers de configuration dans /etc/opt/package_nameet les fichiers statiques dans /var/opt/package_name/static/- suivant les conventions suggérées par FHS. [ 1 ] [ 2 ] [ 3 ]

J'ai également besoin de stocker des fichiers journaux. Je veux qu'ils soient détectables par des outils d'analyse, donc ils devraient également être dans un emplacement conventionnel. Devraient-ils entrer:

• /var/log/package_name (comme un package système, même s'il s'agit d'un package personnalisé)
• /var/opt/package_name/log(suivant la /var/optconvention - mais est-ce découvrable?)
• autre chose?

Je les mettrais dedans /var/log/package_name; il satisfait mieux que le principe de la moindre surprise /var/opt/package_name/log. Je n'ai pas de citation pour cela; il correspond simplement à l'endroit où je rechercherais les journaux.

Je pourrais également renoncer à écrire mes propres fichiers journaux et me connecter à la place syslogavec une balise et une installation appropriées; si je recherche une intégration claire avec des outils d'analyse établis, je ne pense pas que je puisse faire mieux pour un canal de communication:

• Chaque outil générique avec "analyse de journal" comme fonctionnalité répertoriée surveille déjà syslog.
• La sémantique de libération et de rotation des fichiers journaux est gérée pour moi; Je n'ai pas besoin de mettre en place un mécanisme pour logrotateme dire de lâcher le fichier et d'en ouvrir un nouveau. Je n'ai même pas besoin de parler logrotatede nouveaux fichiers à faire tourner!
• Le déchargement des journaux vers les serveurs de journalisation centraux est géré pour moi, si le site l'exige; Les outils existants existants comme rsyslogseront utilisés si nécessaire, donc je n'ai pas à envisager de mettre en œuvre cette fonctionnalité moi-même.
• Les contrôles d'accès (POSIX et, par exemple SELinux) autour des fichiers journaux sont déjà gérés, donc je n'ai pas besoin d'accorder autant d'attention à la sémantique de sécurité spécifique à la distribution.

À moins que je ne fasse un format binaire personnalisé pour mon journal et même dans ce cas, je préfère les formats de texte analysables par ordinateur compatibles Syslog comme JSON. J'ai du mal à justifier mes propres fichiers journaux séparés; les outils d'analyse regardent déjà syslogcomme un faucon.

Comme vous suivez les conventions FHS pour vos fichiers de configuration de package, vous devez être cohérent et stocker les fichiers journaux dans /var/opt/package_name/log.

La FHS déclare:

Les données variables des packages dans / opt doivent être installées dans / var / opt /

et déclare également

Aucun autre fichier de package ne peut exister en dehors des hiérarchies / opt, / var / opt et / etc / opt, à l' exception des fichiers de package qui doivent résider à des emplacements spécifiques dans l'arborescence du système de fichiers pour fonctionner correctement. Par exemple, les fichiers de verrouillage de périphérique doivent être placés dans / var / lock et les périphériques doivent être situés dans / dev.

Avoir les fichiers journaux sous /var/optn'empêche pas le package de fonctionner correctement, donc l'utilisation à la /var/logplace viole clairement la norme.

On ne sait pas ce que vous entendez par "est-ce découvrable?" étant donné que vos journaux personnalisés sont de toute façon susceptibles d'être gérés par des outils personnalisés, mais en supposant qu'un outil générique est conçu pour les traiter, il doit explorer l'emplacement standard des packages dégroupés comme le vôtre.

Notez que syslogc'est une fonctionnalité utile pour centraliser et régler la configuration de la journalisation, mais ne résout pas complètement le problème de l'emplacement de stockage des journaux lorsque vous devez le faire dans des fichiers simples avec un chemin bien connu. Certains fichiers parfois stockés dans un répertoire de journal d'application sont conçus pour être accessibles en utilisant leur chemin d'accès prévu par l'application elle-même ou par des programmes associés, par exemple un fichier stockant un ID de processus, donc syslogne fonctionnera pas pour eux.