L'écriture de fichiers journaux de serveur dans une base de données est-elle une bonne idée?

Question

Après avoir lu un article sur le sujet publié par O ' Reilly , je voulais demander à Stack Overflow de donner son avis.

Answer 1

Ecrivez localement sur le disque, puis effectuez une insertion par lots dans la base de données périodiquement (par exemple, au moment du basculement du journal). Faites-le dans un processus distinct peu prioritaire. Plus efficace et plus robuste ...

(Assurez-vous que votre table de journal de base de données contient une colonne indiquant "de quelle machine l'événement de journal provient", soit très utile!)

Answer 2

Je dirais non, étant donné qu'un pourcentage assez élevé d'erreurs de serveur impliquent des problèmes de communication avec des bases de données. Si la base de données se trouvait sur un autre ordinateur, la connectivité réseau constituerait une autre source d’erreurs qui ne pourraient pas être consignées.

Si je devais enregistrer les erreurs de serveur dans une base de données, il serait essentiel de disposer d'un journal de sauvegarde écrit localement (dans un journal des événements, un fichier ou autre) au cas où la base de données serait inaccessible.

Answer 3

Connectez-vous à la base de données si vous le pouvez et si cela ne ralentit pas votre base de données:)

Il est beaucoup plus rapide de trouver quoi que ce soit dans la base de données, puis dans les fichiers journaux. Surtout si vous pensez à l’avenir ce dont vous aurez besoin. La connexion à la base de données vous permet d’interroger la table de journal comme suit:

select * from logs
where log_name = 'wcf' and log_level = 'error'

puis après avoir trouvé l'erreur, vous pouvez voir le chemin complet qui a conduit à cette erreur

select * from logs
where contextId = 'what you get from previous select' order by timestamp

Comment obtiendrez-vous ces informations si vous les enregistrez dans des fichiers texte?

Modifier: Comme JonSkeet a suggéré que cette réponse serait meilleure si j'affirmais qu'il fallait envisager de rendre la journalisation en base de données asynchrone. Alors je le dis :) je n'en avais tout simplement pas besoin. Par exemple, comment procéder, vous pouvez cocher la case "Ultra Fast ASP.NET". par Richard Kiessig.

Answer 4

Si la base de données est une base de données de production, il s’agit d’une idée horrible. Vous aurez des problèmes de sauvegarde, de réplication et de récupération. Comme plus de stockage pour la base de données elle-même, les répliques, le cas échéant, et les sauvegardes. Plus de temps pour configurer et restaurer la réplication, plus de temps pour vérifier les sauvegardes, plus de temps pour récupérer la base de données à partir de sauvegardes.

Answer 5

Ce n'est probablement pas une mauvaise idée si vous voulez que les journaux soient dans une base de données, mais je dirais de ne pas suivre les conseils de l'article si vous avez beaucoup d'entrées dans le fichier journal. Le problème principal est que j'ai vu que les systèmes de fichiers rencontraient des problèmes pour suivre les journaux provenant d'un site occupé, sans parler d'une base de données. Si vous voulez vraiment faire cela, je voudrais charger les fichiers de log dans la base de données après leur première écriture sur le disque.

Answer 6

Vous pensez à une base de données correctement configurée qui utilise la RAM pour la lecture et l’écriture? Cela est tellement plus rapide que d'écrire sur le disque et ne présenterait pas le goulot d'étranglement d'E / S du disque que vous voyez lorsque vous serviez un grand nombre de clients, ce qui se produit lorsque les threads commencent à se verrouiller car le système d'exploitation leur dit d'attendre les threads en cours d'exécution utilisant toutes les E / S disponibles. poignées.

Je n'ai pas de points de repère pour prouver ces données, bien que ma dernière application fonctionne avec la journalisation de la base de données. Cela aura une sécurité intrinsèque comme mentionné dans l'une de ces réponses. Si la connexion à la base de données ne peut pas être créée, créez une base de données locale (h2 peut-être?) Et écrivez dessus. Ensuite, nous pouvons effectuer une vérification périodique de la connectivité de la base de données afin de rétablir la connexion, vider la base de données locale et la transférer vers la base de données distante.

Ceci peut être effectué en dehors des heures de travail si vous ne possédez pas de site H-A.

Dans le futur, j'espère développer des points de repère pour illustrer mon propos.

Bonne chance!