Alternatives à Splunk?
Je suis assez impressionné par Splunk , en particulier la version 4. Jolis graphiques, alertes (Enterprise uniquement) et recherche rapide et précise. C'est un excellent produit.
Cependant, le coût est beaucoup trop élevé pour être pris en compte pour une utilisation complète de la production pour notre entreprise. Tout ce dont nous avons vraiment besoin, c'est de pouvoir indexer différents journaux dans un emplacement central et de faire des recherches raisonnables à ce sujet. Avoir des alertes basées sur une recherche enregistrée est également très agréable. Nous n'allons pas vraiment au-delà de cela.
En fait, notre plus grande utilisation a été le déploiement de nouvelles applications. Tout est enregistré via log4net dans le journal des événements sous Windows ou un fichier texte sous Linux. Splunk, il est assez facile de rechercher rapidement parmi ceux-ci pour s'assurer que toutes les parties de l'application fonctionnent bien - cela nous a fait gagner beaucoup de temps par rapport à la recherche de sources de journalisation individuelles.
Quelles alternatives existent sur ce marché? J'ai l'impression que les prix de Splunk sont si élevés parce qu'ils ont de loin le meilleur produit, et ils le savent. Nous voulons que le serveur fonctionne sur Windows.
Je serais ouvert à un modèle divisé, utilisant un produit pour les journaux généraux (collecte via syslog/Snare), et un produit dédié pour nos applications personnalisées (comme Log4Net Dashboard ).
Est-ce que l'utilisation d'un simple serveur syslog tel que Kiwi, envoyé à SQL Server (peut-être avec le texte intégral activé) fonctionnerait-il?
J'espère que le coût devrait être bien inférieur à 5 chiffres, USD. (Et oui, je sais, nous sommes bon marché. Nous sommes une startup avec peu d'argent, et BizSpark s'occupe de toutes nos licences MS.)
Edit: je dois ajouter que nous avons environ 10 serveurs physiques, 20 machines virtuelles et quelques pare-feu et commutateurs. 90% est Windows.
Remarque: Tout cela concerne Linux et les logiciels libres , car c'est ce que j'utilise principalement, mais ça devrait aller avec un client syslog sur Windows pour envoyer les journaux à un serveur syslog Linux.
Connexion à un serveur SQL: Avec seulement 30 machines, tout devrait bien fonctionner avec à peu près n'importe quel syslog centralisé et un backend SQL. J'utilise syslog-ng et MySQL sur Linux pour cela.
Les jolis frontends pour le graphisme sont le principal problème - Il semble qu'il y ait beaucoup de front-end piratés qui récupèrent les éléments des journaux et montrer combien de hits, alertes, etc. mais je n'ai rien trouvé d'intégration et de propre. Certes, c'est la principale chose que vous recherchez ... (Si je trouve quelque chose de bien, je mettrai à jour cette section!)
Alerte : j'utilise SEC sur un serveur Linux pour trouver de mauvaises choses qui se produisent dans les journaux et m'alerter via différentes méthodes. Il est incroyablement flexible et pas aussi cliquable que Splunk. Il y a n joli tutoriel ici qui guide à travers de nombreuses fonctionnalités possibles.
J'utilise également Nagios pour les graphiques de diverses statistiques et certaines alertes que je ne reçois pas des journaux (comme lorsque les services sont en panne, etc.). Cela peut être facilement personnalisé pour ajouter des graphiques de tout ce que vous aimez. J'ai ajouté des graphiques d'éléments tels que le nombre de visites effectuées sur un serveur http, en faisant en sorte que l'agent utilise le plugin check_logfiles pour compter le nombre de visites dans les journaux (il enregistre la position qu'il se lève) à pour chaque période de contrôle).
Dans l'ensemble, cela dépend du coût de votre temps pour le configurer , car il existe de nombreuses options que vous pouvez utiliser mais elles ne sont pas aussi intégrées comme Splunk et nécessitera probablement plus d'efforts pour faire ce que vous voulez. Les graphiques Nagios sont simples à configurer, mais ne vous donnent pas de données historiques avant d'ajouter le graphique, alors qu'avec Splunk (et probablement d'autres frontaux), vous pouvez regarder en arrière les journaux et les graphiques précédents pensé à regarder d'eux.
Notez également que le format de base de données SQL et l'indexation auront un effet énorme sur la vitesse des requêtes, de sorte que votre idée d'indexation de texte intégral augmentera considérablement la vitesse des recherches. Je ne sais pas si MySQL ou PostgreSQL fera quelque chose de similaire.
Edit: MySQL fera une indexation plein texte, mais niquement sur les tables MyISAM avant MySQL 5.6. Dans 5.6 Le support a été ajouté pour InnoDB.
Edit: Postgresql peut faire une recherche plein texte bien sûr: http://www.postgresql.org/docs/9.0/static/textsearch.html
Plus destiné à * nix qu'à windows, mais octopussy supporte windows, et semble viser le même genre de chose que splunk.
Pour un syslog centralisé avec de nombreuses fonctionnalités intéressantes, je ne peux pas m'empêcher de recommander rsyslog assez. C'est un serveur syslog open source qui peut fonctionner avec bonheur comme un remplacement pour le syslogd régulier que vous connaissez et aimez. C'est maintenant le démon syslog de choix pour Ubuntu et je pense que Red Hat et Fedora pourraient également suivre cette voie. J'ai trouvé que c'était beaucoup plus facile d'être opérationnel et de faire ce que vous voulez que syslog-ng soit.
Actuellement dans notre boutique, nous avons deux serveurs rsyslog centraux (un dans chaque site) qui reçoivent des journaux pour des centaines de serveurs. J'ai des alertes automatiques par e-mail chaque fois que quelque chose dans syslog déclenche une alerte ou plus (avec quelques ajustements bien sûr, certaines applications sont un peu alarmistes). Je pourrais probablement faire un peu plus d'intelligence comme l'obliger à envoyer des trucs à Nagios ou autres, mais cela nous couvre suffisamment pour nos besoins pour l'instant.
Tout cela va aussi dans une base de données mysql (il y a aussi un support pour Oracle ou postgresql si c'est comme ça que vous roulez).
Il y a aussi un web frontend et un agent Windows pour envoyer les journaux Eventlog au serveur rsyslog également. Le frontend web n'est évidemment pas aussi lisse que splunk mais il fait le travail pour 0 $.
Je suis en train d'essayer un certain nombre de solutions de surveillance - mais je veux principalement surveiller les fenêtres. La plupart des systèmes sont adaptés à la surveillance SNMP qui parvient à extraire une quantité remarquable d'informations sans agents.
Voici quelques-uns des systèmes que j'ai essayés jusqu'à présent:
Nagios - Open source. Un cochon à configurer mais très coté et semble très flexible. Il semble être essentiellement un enregistreur de compteur et ne permet pas l'exécution de script à distance et ne peut donc pas être utilisé pour détecter des problèmes de configuration, ala MS system center ou Kaseya. Sans agent, mais est essentiellement inutile sans l'outil NSclient installé sur chaque client.
Cacti - Outil graphique joli et simple basé sur l'extraction des statistiques snmp. Sans agent.
OpsView - Basé sur Nagios mais plus facile à configurer et a un meilleur frontal.
HypericHQ - Facile à installer et à exécuter sous Windows. La version de base est gratuite et fait beaucoup. Il existe une entreprise commerciale HypericHQ. L'agent doit être installé sur chaque client.
Zabbix - Un autre bel outil de surveillance. C'est plus facile à utiliser que les nagios. Possède un agent que vous pouvez installer sur Windows et sur les ordinateurs clients. Je n'ai exploré celui-ci qu'un peu jusqu'à présent.
Zenoss - Open source. J'ai été très impressionné par le professionnalisme du Zenoss. C'est un moniteur basé sur SNMP et dispose de nombreuses extensions pour permettre la surveillance des proliants HP, des services Windows, du serveur MS SQL, de MySQL. Les extensions fonctionnent toutes via SNMP, donc rien ne doit être installé sur les machines clientes. Je n'ai pas encore tout exploré et il semble y avoir beaucoup de fonctionnalités que je n'ai pas encore exploitées. Il est basé sur Zope, donc à moins que vous ne soyez à jour sur les installations de Zope, je vous recommande de télécharger la version pré-préparée VM - cela fonctionne comme un rêve dès la sortie de la boîte.
Sur le plan commercial, vous pouvez jeter un œil à quelques outils:
Kaseya - coûte environ 6k par an pour 250 nœuds, si je me souviens bien, mais c'est un superbe outil et dispose d'une communauté d'utilisateurs très active. Il est destiné au marché msp et permet de surveiller les systèmes de plusieurs sociétés. Il peut être utilisé en interne sans problème.
GFI Hounddog - plus simple que Kaseya mais très bon marché pour le moment. Vaut vraiment le coup d'oeil.
Il existe un certain nombre de solutions vendues en tant que systèmes MSP, mais qui sont essentiellement des moniteurs + administrateur distant combinés.
Ian
Je suis d'accord que Splunk est génial. Pour les petits environnements à dominante Linux, cependant, vous voudrez peut-être regarder quelque chose comme epylog .
Nous l'avons utilisé dans l'un des endroits où je travaillais, et c'était super pour ce que nous voulions.
Je ne sais pas dans quelle mesure il gérerait les messages syslog Windows envoyés à un collecteur syslog Linux, mais cela pourrait valoir la peine.
Jetez un oeil à http://www.codeplex.com/polymon
Son open source, utilise SQL Server au niveau du backend et possède une interface utilisateur sophistiquée
Juste un lien vers ma réponse ailleurs où:
Splunk est incroyablement cher: quelles sont les alternatives?
Modifier (nouveaux projets):
Quelque chose comme GFI EventsManager pourrait faire l'affaire pour environ 4k $.
- Analyse des journaux d'événements, y compris les interruptions SNMP, les journaux d'événements Windows, les journaux W3C et Syslog
- Alertes en temps réel, alertes de pièges SNMPv2 incluses
- Afficher les rapports sur les informations de sécurité clés en cours
- Journalisation centralisée des événements
- Supprimez le "bruit" ou les événements triviaux qui constituent un large ratio de tous les événements de sécurité
- Surveillance et alertes en temps réel 24 x 7 x 365 jours
- Surveillez graphiquement l'état de GFI EventsManager et de votre réseau via le moniteur d'état intégré
- Prise en charge des environnements virtuels
Si vous recherchez un remplacement SysLog, vous pouvez également envisager un remplacement commercial syslog/rsyslog comme LogLogic, http://loglogic.com . Nous (c'est là où je travaille) avons un ensemble complet d'appliances de journalisation, de stockage et de rapports. Essentiellement, sa capacité à collecter 100 000 messages par seconde, à les endiguer et à les indexer pour que des recherches puissent être effectuées.
Avez-vous essayé php-syslog-ng? http://code.google.com/p/php-syslog-ng/
Si vous cherchez une alternative beaucoup plus abordable à Splunk - essayez LogZilla ( http://www.logzilla.pro ). Il évolue aussi bien ou mieux que Splunk (vous pouvez rechercher plus de 300 m de journaux en environ 1-2 secondes) et représente facilement 1/10 du coût. Ils ont une démo en cours d'exécution sur http://demo.logzilla.pro
J'ai posté le fil de dupe: Splunk est incroyablement cher: quelles sont les alternatives?
xpolog et toutes les solutions commerciales sérieuses sont BIG $ (même si moins que splunk, la plupart sont facilement à 5 chiffres!)
Sooooo, ce que nous avons finalement fait (parce que le splunk était trop $):
1) Nous voulions un simple syslog vers sql db pipeline
2) Nous avons essayé kiwi syslog. Cela a très bien fonctionné pendant une semaine, a cessé de fonctionner et le support kiwi n'a pas pu le réparer. Nous avons donc abandonné le kiwi
3) Nous avons essayé winsyslog. Un vieux chien d'une application, nous ne voulions pas l'apprendre.
4) Nous avons utilisé cette application .net gratuite: http://www.aonaware.com/syslog.htm
Voila. Nous avons des messages syslog dans notre base de données.
Nous sommes très heureux. 0 $ dépensé, quelques heures, mais pas trop.
Nous utilisons Splunk ici, et je suis un peu choqué par le prix qu'ils vous ont dit. La ventilation de base qui nous a été donnée est d'environ 1 000 $ US pour 1 Go de données. C'est coûteux, mais super puissant et très rapide à développer. En fonction de vos sources de données et de ce que vous voulez en faire, certains scripts python et Perl pourraient vous donner beaucoup de données similaires. La grande différence sera le temps et apprendre à vraiment utiliser le langue pour le traitement de texte. Vous ne pourrez pas non plus obtenir des informations IP en temps réel (des trucs comme syslog), mais vous pouvez résoudre ce problème en obtenant un syslogger et en sortant les informations dans un fichier texte. Désolé, je ne peux pas vous orienter vers solution spécifique; ce que nous ne pouvons pas utiliser splunk pour nous utilisons des scripts python, Perl et bash pour.
Vous pouvez essayer Logscape à partir de Liquidlabs - très similaire à Splunk mais possède également quelques fonctionnalités différentes .... http://www.liquidlabs-cloud.com/products/logscape.html
J'ai fait le backend SQL lors d'un travail précédent (c'était MySQL d'ailleurs), complet avec des scripts, Drupal interface avec custom PHP scripts, les travaux) .
Honnêtement, cela prenait beaucoup trop d'heures de travail et n'était toujours pas Splunk.
Actuellement, je teste plutôt Splunk. Oui, ce n'est pas gratuit, mais en regardant la situation dans son ensemble, cela pourrait en fait être moins cher.
ELSA - Recherche et archivage des journaux d'entreprise
Caractéristiques principales:
- Recherche en texte intégral sur n'importe quel mot dans un message ou un champ analysé.
- Regroupez par domaine et produisez des rapports basés sur les résultats.
- Planifiez des recherches.
- Alerte sur les résultats de recherche sur les nouveaux journaux.
- Enregistrer les recherches, envoyer les résultats de recherche par e-mail.
- Créez des tickets d'incident basés sur les résultats de la recherche (avec plugin).
- Système de plugin complet pour les résultats.
- Exportez les résultats en permalien ou en Excel, PDF, CSV et HTML.
- Intégration LDAP complète pour les autorisations.
- Statistiques pour les requêtes par utilisateur et taille et nombre de journaux.
- Architecture entièrement distribuée, peut gérer n nœuds avec toutes les requêtes exécutées en parallèle.
- Archive compressée avec un rapport supérieur à 10: 1.
Détails de performance:
Pour spécifier un système, par ordre d'importance: taille du disque, RAM, vitesse du disque, nombre de CPU. Le facteur de performance primordial est l'indexeur et le démon de recherche de Sphinx, donc référez-vous à sphinxsearch.com pour les documents. Mes statistiques données proviennent de gros systèmes (16 CPU, 144 Go de RAM, 12 TB HD), mais vous obtiendrez les mêmes performances sur un système avec 4 CPU, 8 Go de RAM et tout autre taille HD alors que les choses évoluent de manière linéaire. Le système a d'abord fonctionné sur des lames IBM avec 4 Go RAM et slow SAN et exécutés à peu près au même rythme, mais 4 GB le coupe un peu près.
Détails des performances et liste des fonctionnalités principales, plus une description de l'architecture: http://ossectools.blogspot.com/2011/03/fighting-apt-with-open-source-software.html
Code: https://code.google.com/p/enterprise-log-search-and-archive/
VM: http://ossectools.blogspot.com/2011/07/elsa-vmware-appliance-available.html
Détails concernant le projet: http://ossectools.blogspot.com/2011/03/comprehensive-log-collection.html