Non seulement avec inotify il y aurait moins de meta-données disponibles (pas de connaissance du process qui écrit les logs, ni du user/group de ce process), mais surtout avec fuse_kafka il est envisageable de proposer une petite évolution pour que les logs interceptées ne soient plus écrites sur le système de fichiers local:
Pour éviter le remplissage des disques par les X applications pour lesquels la rotation
des logs a été oubliée ou est faite mais sans taille max des logs tournées… grand
classique des pannes pour qui fait de la production!
Pour sécuriser les machines et le contenu des applications, car les logs contiennent souvent
des traces sur des données (voire au pire, des mots de passe… déjà vu!) qui devraient rester
confinées dans des stockages sécurisés / situés sur un réseau distinct de celui des machines
accessible depuis Internet.
Un système d'interception des logs basé sur inotify ne pourrait pas empêcher l'écriture sur les système de fichiers, à moins que je n'ai raté quelque-chose ?
[^] # Re: inotify
Posté par al3x . En réponse au journal présentation de fuse_kafka, un agent de logging pour kafka fondé sur FUSE. Évalué à 4.
Non seulement avec inotify il y aurait moins de meta-données disponibles (pas de connaissance du process qui écrit les logs, ni du user/group de ce process), mais surtout avec fuse_kafka il est envisageable de proposer une petite évolution pour que les logs interceptées ne soient plus écrites sur le système de fichiers local:
Un système d'interception des logs basé sur inotify ne pourrait pas empêcher l'écriture sur les système de fichiers, à moins que je n'ai raté quelque-chose ?
Al3x