Utilisation d'un serveur SQL pour la consignation des applications. Avantages/inconvénients?

Question

J'ai une application multi-utilisateur qui conserve un fichier journal centralisé pour l'activité. En ce moment, cette journalisation va dans les fichiers texte à hauteur d'environ 10MB-50MB/jour. Les fichiers texte sont tournés quotidiennement par l'enregistreur, et nous conservons les 4 ou 5 derniers jours. Plus que cela ne nous intéresse pas.

Ils sont rarement lus: soit lors du développement de l'application pour les messages d'erreur, les messages de diagnostic, ou lorsque l'application est en production pour faire le tri sur un problème signalé par l'utilisateur ou un bogue.

(Ceci est strictement un journal d'application. Journal de sécurité est maintenue ailleurs.)

Mais quand ils sont lus, ils sont une douleur dans le cul. Grepping 10MB fichiers texte n'est pas amusant, même avec Perl: les champs (ID de transaction, ID utilisateur, etc ..) dans le fichier sont utiles, mais seulement du texte. Les messages sont écrits séquentiellement, un comme à la fois, de sorte que l'activité entrelacée est tout mélangé lorsque vous essayez de suivre une transaction ou un utilisateur particulier.

Je cherche des idées sur le sujet. Quelqu'un a fait la journalisation au niveau de l'application avec une base de données SQL et l'a aimé? Je l'ai détesté?

Answer 1

Oui, nous le faisons ici, et je ne peux pas le supporter. Un problème que nous avons ici est s'il y a un problème avec la base de données (connexion, corrompu etc), toute la journalisation s'arrête. Mon autre gros problème, c'est qu'il est difficile de trouver des problèmes. Nous avons également des problèmes avec les journaux de table qui occupent trop d'espace, et nous devons nous soucier de les tronquer lorsque nous déplaçons des bases de données car nos journaux sont trop volumineux. Je pense que c'est compliqué par rapport aux fichiers journaux. Je trouve difficile de voir la "grande image" avec ce qui est stocké dans la base de données. J'admettrai que je suis une personne de fichier journal, j'aime pouvoir ouvrir un fichier texte et le parcourir (regex) au lieu d'utiliser sql pour essayer de chercher quelque chose.

Le dernier endroit où j'ai travaillé nous avions des fichiers journaux de 100 meg plus. Ils sont un peu difficiles à ouvrir, mais si vous avez le bon outil, ce n'est pas si grave. Nous avions aussi un système pour enregistrer les messages. Vous pourriez rapidement regarder le fichier et déterminer quel ensemble d'entrées de journal appartenait quel processus.

Answer 2

Nous avons utilisé une base de données de journal lors de mon dernier travail, et c'était génial.

Nous avions des procédures stockées qui crachaient des aperçus de l'état général du système pour différentes mesures que je pouvais charger à partir d'une page Web. Nous pourrions également cracher rapidement une trace pour une application donnée sur une période donnée, et si je le voulais, il serait facile de l'obtenir en tant que fichier texte, si vous aimez vraiment graver des fichiers. Pour garantir que le système de journalisation ne pose pas lui-même de problème, il existe bien sûr un cadre de code commun que nous avons utilisé parmi les différentes applications qui ont traité l'écriture dans la table de journalisation. Une partie de ce cadre incluait et se connectant à un fichier, dans le cas où le problème est avec la base de données elle-même, et une partie de celle-ci implique le recyclage des journaux. En ce qui concerne les problèmes d'espace, la base de données du journal est sur un calendrier de sauvegarde différent, et ce n'est vraiment pas un problème. L'espace (non sauvegardé) est bon marché.

Je pense que cela répond à la plupart des préoccupations exprimées ailleurs. Tout est une question de mise en œuvre. Mais si je m'arrêtais ici, ce serait toujours un cas de "pas beaucoup pire", et c'est une mauvaise raison de se donner la peine de configurer la journalisation DB. Ce que j'ai aimé à ce sujet, c'est que nous a permis de faire nouveau choses qui serait beaucoup plus difficile à faire avec des fichiers plats.

Quatre améliorations principales ont été apportées aux fichiers. Le premier est les aperçus du système que j'ai déjà mentionnés. Le deuxième, et le plus important, consistait à vérifier si une application ne contenait pas de messages là où nous nous attendrions normalement à les trouver. Ce genre de chose est presque impossible à repérer dans la journalisation traditionnelle des fichiers à moins que vous ne passiez beaucoup de temps chaque jour à consulter des journaux abrutissants pour des applications qui vous disent que tout va bien 99% du temps. C'est incroyable de voir à quel point libérer la vue pour montrer les entrées manquantes est. La plupart du temps, nous n'avions pas besoin de regarder la plupart des fichiers journaux ... quelque chose qui serait dangereux et irresponsable sans la base de données.

Cela amène la troisième amélioration. Nous avons généré un seul e-mail d'état quotidien, et c'était seulement chose que nous devions revoir les jours où tout fonctionnait normalement. L'e-mail inclus a montré des erreurs et des avertissements. Les journaux manquants ont été journalisés comme avertissement par le même travail db qui envoie l'e-mail, et l'absence de l'e-mail était une grosse affaire. Nous pourrions envoyer un message particulier à notre outil de suivi des bogues en un clic, directement à partir de l'e-mail quotidien (formaté en html, extrait des données d'une application web). L'amélioration finale était que si nous voulions suivre une application spécifique de plus près, par exemple après avoir apporté une modification, nous pourrions nous abonner à un flux RSS pour cette application spécifique jusqu'à ce que nous soyons satisfaits. C'est plus difficile à faire à partir d'un fichier texte. Là où je suis maintenant, nous comptons beaucoup plus sur les outils tiers et leurs capacités de journalisation, ce qui signifie revenir à une révision beaucoup plus manuelle. La base de données me manque vraiment et je suis en train d'écrire un outil pour lire ces journaux et les réenregistrer dans une base de données pour récupérer ces capacités. Encore une fois, nous l'avons fait avec des fichiers texte en tant que solution de rechange, et ce sont les nouvelles capacités qui font vraiment la valeur de la base de données. Si tout ce que vous allez faire est d'écrire dans une base de données et d'essayer de l'utiliser de la même façon que les anciens fichiers texte, cela ajoute une complexité inutile et vous pouvez aussi bien utiliser les anciens fichiers texte. C'est la capacité de construire le système pour de nouvelles fonctionnalités qui en vaut la peine.

Answer 3

Je pense que le problème que vous avez avec la journalisation pourrait être résolu avec la connexion à SQL, fourni que vous êtes en mesure de diviser les champs qui vous intéressent, dans différentes colonnes. Vous ne pouvez pas traiter la base de données SQL comme un champ de texte et attendez-vous à ce qu'il soit meilleur, ce ne sera pas le cas. Une fois que vous obtenez tout ce qui vous intéresse de vous connecter aux colonnes que vous voulez, il est beaucoup plus facile de suivre les actions séquentielles de quelque chose en étant capable de l'isoler par colonne. Comme si vous aviez un processus "entrée", vous vous connectez tout normalement avec le texte "processus d'entrée" mis dans la colonne "logtype" ou colonne "process". Ensuite, lorsque vous rencontrez des problèmes avec le "processus d'entrée", une instruction WHERE sur cette colonne isole tous les processus d'entrée.

Answer 4

je pouvais le voir bien fonctionner, à condition que vous aviez la possibilité de filtrer ce a besoin d'journaliser et quand il faut être connecté. Un fichier journal (ou une table, tel qu'il est) est inutile si vous ne trouvez pas ce que vous cherchez ou contient des informations inutiles.

Answer 5

Nous avons déjà utilisé la journalisation centralisée de SQL Server, et comme mentionné précédemment, le plus gros problème était qu'une connexion interrompue à la base de données signifiait une interruption de la journalisation. En fait, j'ai fini par ajouter une routine de mise en file d'attente à la journalisation qui tenterait d'abord la base de données et écrirait dans un fichier physique en cas d'échec. Il suffirait d'ajouter du code à cette routine qui, dans un journal réussi sur la base de données, vérifierait si d'autres entrées sont mises en file d'attente localement et les écrirait aussi.J'aime avoir tout dans une base de données, par opposition aux fichiers journaux physiques, mais simplement parce que j'aime l'analyser avec les rapports que j'ai écrits. Nous le faisons dans notre organisation dans de grands volumes avec SQL Server

Answer 6

Dans mon ouverture, écrire à la base de données est meilleur en raison de la capacité de recherche et de filtrage. Les performances de 10 à 50 Mo de données et de ne les conserver que pendant 5 jours n'affectent pas votre application. Suivi de la transaction et les utilisateurs seront très faciles à comparer à la suivre à partir du fichier texte, car vous pouvez filtrer par transaction ou par utilisateur.

Vous mentionnez que les fichiers sont lus rarement. Alors, décidez si cela vaut la peine de consacrer du temps aux efforts de développement pour développer le cadre d'exploitation forestière? Calculez le temps que vous consacrez à la recherche des journaux à partir des fichiers journaux dans une année par rapport au temps nécessaire pour coder et tester. Si la durée de la recherche est de 1 heure ou plus par jour, il est préférable de vider les journaux dans la base de données. Ce qui peut réduire considérablement le temps consacré à la résolution des problèmes. Si vous passez moins d'une heure, vous pouvez utiliser des outils de recherche de texte comme "SRSearch", qui est un excellent outil que j'ai utilisé, recherche à partir de plusieurs fichiers dans un dossier et vous donne les résultats dans de petits extraits (" comme résultat de recherche google "), où vous cliquez pour ouvrir le fichier avec le résultat intéressé. Il existe d'autres outils de recherche de texte disponibles. Si l'environnement est windows, alors vous avez Microsoft LogParser également un bon outil disponible gratuitement où vous pouvez interroger votre fichier comme une base de données si le fichier est écrit dans un format spécifique.

Answer 7

Je pense que la connexion directe à une base de données est généralement une mauvaise idée, et je l'éviterais.

La raison principale est la suivante: un bon journal sera très utile lorsque vous pourrez l'utiliser pour déboguer votre application post-mortem, une fois que l'erreur est déjà survenue et que vous ne pouvez pas la reproduire. Pour être en mesure de le faire, vous devez vous assurer que la journalisation elle-même est fiable. Et pour rendre tout système fiable, un bon début est de le garder simple. Donc, avoir un simple fichier basé sur le journal avec juste quelques lignes de code (ouvrir un fichier, ajouter une ligne, fermer un fichier ou le garder ouvert, répéter ...) sera généralement plus fiable et utile à l'avenir, quand vous en avez vraiment besoin pour travailler. D'autre part, la connexion réussie à un serveur SQL nécessitera que beaucoup plus de composants fonctionnent correctement, et il y aura beaucoup plus de situations d'erreur possibles où vous ne pourrez pas enregistrer les informations dont vous avez besoin, simplement parce que l'infrastructure de journal elle-même ne fonctionnera pas. Et quelque chose de pire: un échec dans la procédure de log (comme une corruption de base de données ou un blocage) affectera probablement les performances de l'application, et vous aurez alors une situation où un composant secondaire empêche l'application de l'exécution de sa fonction principale.

Si vous avez besoin de beaucoup d'analyse des journaux et que vous n'êtes pas à l'aise avec les outils textuels comme grep, conservez les journaux dans des fichiers texte et importez-les régulièrement dans une base de données SQL. Si le SQL échoue, vous ne perdrez aucune information de journal et cela n'affectera même pas la capacité de l'application à fonctionner. Ensuite, vous pouvez faire toutes les analyses de données dans la base de données. Je pense que ce sont les principales raisons pour lesquelles je ne fais pas de journalisation dans une base de données, bien que je l'aie fait par le passé. J'espère que cela aide.

Answer 8

Vous pouvez vous connecter à un format de texte délimité par des virgules ou des tabulations, ou activer l'exportation de vos journaux au format CSV. Lorsque vous avez besoin de lire à partir d'un journal, exportez votre fichier CSV vers une table sur votre serveur SQL, vous pouvez alors interroger avec des instructions SQL standard. Pour automatiser le processus, vous pouvez utiliser SQL Integration Services.

Answer 9

Étant donné que vos journaux sont rarement lus, je les écrirais sur fichier (meilleure performance et fiabilité). Ensuite, si et seulement si vous avez besoin de les lire, j'importerais le fichier journal dans une base de données (meilleure analyse).

Ce faisant, vous obtenez les avantages des deux méthodes.

Answer 10

Voici quelques avantages supplémentaires et les inconvénients et la raison pour laquelle je préfère les fichiers journaux au lieu des bases de données:

1. L'espace est pas pas cher lors de l'utilisation de VPS. Récupérer de l'espace sur des systèmes de bases de données en direct est souvent un gros problème et vous devrez peut-être arrêter les services tout en récupérant de l'espace. Si vos logs sont si importants que vous devez les garder pendant des années (comme nous le faisons), alors c'est un vrai problème. Rappelez-vous que la plupart des bases de données ne récupèrent pas d'espace lorsque vous supprimez des données car elles réutilisent simplement l'espace - pas beaucoup d'aide si vous manquez d'espace. Si vous accédez fréquemment aux journaux et que vous devez extraire des rapports quotidiens d'une base de données contenant une énorme table de journaux et des millions et des millions d'enregistrements, vous impacterez les performances de vos services de base de données.

2. Les fichiers journaux peuvent être créés et les anciens journaux peuvent être archivés quotidiennement. Selon le type de journaux, des quantités massives d'espace peuvent être récupérées en archivant les journaux. Nous économisons environ 6 fois l'espace lorsque nous compressons nos bûches et dans la plupart des cas, vous économiserez probablement beaucoup plus.

3. Des fichiers journaux individuels plus petits peuvent être compressés et transférés facilement sans impact sur le serveur. Auparavant, nous avions des journaux allant de 100 Go de données dans une base de données. Déplacer de telles bases de données entre les serveurs devient un problème majeur, notamment en raison du fait que vous devez fermer le serveur de base de données en même temps. Ce que je dis, c'est que la maintenance devient une vraie douleur le jour où vous devez commencer à déplacer de grandes bases de données.

4. L'écriture dans les fichiers journaux est en général beaucoup plus rapide que l'écriture dans la base de données. Ne sous-estimez pas la vitesse de votre fichier d'E/S du système d'exploitation.

5. Les fichiers journaux ne sont bons que si vous ne structurez pas correctement vos journaux. Vous devrez peut-être utiliser des outils supplémentaires et vous devrez peut-être développer les vôtres pour les traiter, mais au final cela en vaudra la peine.

Answer 11

J'ai lu toutes les réponses et elles sont géniales. Mais dans une entreprise, j'ai travaillé en raison de plusieurs restrictions et d'audit, il était obligatoire de se connecter à une base de données. Quoi qu'il en soit, nous avions plusieurs moyens de nous connecter et la solution consistait à installer un pipeline où nos programmeurs pouvaient se connecter au pipeline et se connecter à la base de données, au fichier, à la console ou même transférer le journal à un port. Ce pipeline n'interrompt pas le processus normal et le fait de conserver un fichier journal en même temps que vous vous connectez à la base de données vous garantit rarement une perte de ligne. Je vous suggère de rechercher plus loin log4net que c'est génial pour cela.

http://logging.apache.org/log4net/