J'ai décidé de réviser cette réponse acceptée car l'état de la technique a considérablement évolué au cours des 18 derniers mois et de bien meilleures alternatives existent.
Nouvelle réponse
MongoDB est un choix médiocre pour une solution de journalisation évolutive. Il y a les raisons habituelles à cela (performances en écriture sous charge par exemple). J'aimerais en proposer une autre, à savoir qu'elle ne résout qu'un seul cas d'utilisation dans une solution de journalisation.
Une solution de journalisation performante doit couvrir au moins les étapes suivantes :
- Collection
- Transports
- Traitement
- Stockage
- Rechercher
- Visualisation
MongoDB en tant que choix ne résout que le cas d'utilisation du stockage (bien qu'un peu mal). Une fois la chaîne complète analysée, il existe des solutions plus appropriées.
@KazukiOhta mentionne quelques options. Ma solution de bout en bout préférée ces jours-ci implique :
- Logstash-Transitaire pour la collecte et le transport
- Logstash et Riemann pour le traitement
- ElasticSearch pour le stockage et les requêtes
- Kibana3 pour la visualisation
L'utilisation sous-jacente d'ElasticSearch pour le stockage des données de journaux utilise la meilleure solution NoSQL actuelle pour le cas d'utilisation de la journalisation et de la recherche. Le fait que Logstash-Forwarder / Logstash / ElasticSearch / Kibana3 soient sous l'égide d'ElasticSearch constitue un argument encore plus convaincant.
Étant donné que Logstash peut également agir comme un proxy Graphite, une chaîne très similaire peut être construite pour le problème associé de collecte et d'analyse des métriques (pas seulement des journaux).
Ancienne réponse
Les collections plafonnées MongoDB sont extrêmement populaires et adaptées à la journalisation, avec l'avantage supplémentaire d'être "sans schéma", ce qui est généralement adapté sémantiquement à la journalisation. Souvent, nous ne savons que bien ce que nous voulons connecter à un projet, ou après que certains problèmes ont été détectés en production. Les bases de données relationnelles ou les schémas stricts ont tendance à être difficiles à modifier dans ces cas, et les tentatives pour les rendre « flexibles » tendent simplement à les rendre « lents » et difficiles à utiliser ou à comprendre.
Mais si vous souhaitez gérer vos journaux dans le noir et que des lasers fonctionnent et donnent l'impression que vous venez de l'espace, il y a toujours Graylog2 qui utilise MongoDB dans le cadre de son infrastructure globale, mais fournit beaucoup plus sur le dessus comme un format commun et extensible, un serveur de collecte de journaux dédié, une architecture distribuée et une interface utilisateur géniale.
