Alternatives à Splunk?

Je suis assez impressionné par Splunk , en particulier la version 4. Jolis graphes, alerte (entreprise uniquement), et recherche rapide et précise. C'est un très bon produit.

Cependant, le coût est bien trop élevé pour que notre société puisse l'utiliser à plein rendement. Tout ce dont nous avons besoin, c’est d’être capable d’indexer différents journaux dans un emplacement central et d’effectuer une recherche raisonnable à ce sujet. Avoir des alertes basées sur une recherche sauvegardée est également très agréable. Nous n'allons pas vraiment au-delà de cela.

En fait, notre utilisation la plus importante a été le déploiement de nouvelles applications. Tout est enregistré via log4net dans le journal des événements sous Windows ou dans un fichier texte sous Linux. Avec Splunk, il est assez facile de rechercher rapidement parmi ces éléments pour s'assurer que toutes les parties de l'application fonctionnent correctement. 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 le sentiment 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 sous Windows.

Je serais ouvert à un modèle fractionné, utilisant un produit pour les journaux généraux (collectés via syslog / Snare) et un produit dédié pour nos applications personnalisées (comme Log4Net Dashboard ).

L'utilisation d'un serveur Syslog simple, tel que Kiwi, envoyé à SQL Server (éventuellement avec Fulltext activé) fonctionnerait-elle?

J'espère que le coût devrait être bien inférieur à 5 chiffres, en dollars américains. (Et oui, je sais, nous sommes bon marché. Nous sommes une start-up 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 , comme c’est ce que j’utilise le plus souvent, mais vous devriez pouvoir utiliser un client Syslog sous Windows pour envoyer les journaux à un serveur Linux Syslog.

Se connecter à un serveur SQL: avec environ 30 machines, vous devriez pouvoir utiliser à peu près n'importe quel système centralisé semblable à syslog et un backend SQL. J'utilise syslog-ng et MySQL sous Linux pour cette chose même.

Le problème principal réside dans les jolies interfaces graphiques. Il semble qu'il existe de nombreux frontaux piratés qui vont récupérer des éléments dans les journaux et indiquer le nombre de hits, d'alertes, etc., mais je n'ai rien trouvé d'intégré et de propre. Certes, c’est la principale chose que vous recherchez ... (Si je trouve quelque chose de bon, je mettrai à jour cette section!)

Alerte : J'utilise SEC sur un serveur Linux pour détecter les incidents qui se produisent dans les journaux et m'avertir de différentes manières. C'est incroyablement flexible et pas aussi facile que Splunk. Il y a un bon tutoriel ici qui vous guide à travers un grand nombre de fonctionnalités possibles.

J'utilise également Nagios pour les graphiques de diverses statistiques et certaines alertes que je ne reçois pas dans les journaux (comme lorsque les services sont en panne, etc.). Cela peut être facilement personnalisé pour ajouter des graphiques de tout ce que vous voulez. J'ai ajouté des graphiques d'éléments tels que le nombre d' accès à un serveur http, en demandant à l'agent d'utiliser le plug- in check_logfiles pour compter le nombre d' accès dans les journaux (il enregistre la position obtenue pour chaque période de contrôle).

Globalement, cela dépend du temps que cela vous coûtera , car il existe de nombreuses options que vous pouvez utiliser mais qui ne sont pas aussi intégrées que Splunk et nécessiteront probablement plus d’efforts pour faire ce que vous voulez. Les graphiques de Nagios sont faciles à configurer mais ne vous donnent pas de données historiques avant de les ajouter, alors qu'avec Splunk (et vraisemblablement d’autres interfaces), vous pouvez revenir sur les journaux passés et sur les graphiques que vous venez de pensé à regarder d'eux.

Notez également que le format et l'indexation de la base de données SQL auront un impact considérable sur la vitesse des requêtes. Votre idée de l'indexation en texte intégral augmentera donc considérablement la vitesse des recherches. Je ne sais pas si MySQL ou PostgreSQL va faire quelque chose de similaire.

Edit : MySQL indexera le texte intégral, mais uniquement sur les tables MyISAM antérieures à MySQL 5.6. En 5.6, le support pour InnoDB a été ajouté .

Edit : Postgresql peut bien sûr effectuer une recherche en texte intégral: http://www.postgresql.org/docs/9.0/static/textsearch.html

Plus axé sur * nix que windows, mais octopussy supporte les fenêtres et semble viser le même genre de chose que splunk.

Je suis en train d'essayer plusieurs solutions de surveillance, mais je veux surtout surveiller les fenêtres. La plupart des systèmes sont adaptés à la surveillance SNMP, ce qui permet d'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 qui semble très flexible. Il semble s'agir essentiellement d'un compteur et ne permet pas l'exécution de script à distance et ne peut donc pas être utilisé pour résoudre des problèmes de configuration, ni dans le centre système MS, ni dans Kaseya. Sans agent, mais est essentiellement inutile sans l'outil NSclient installé sur chaque client.

Cacti - Outil graphique simple et direct basé sur l'extraction de statistiques snmp. Sans agent.

OpsView - Basé sur Nagios mais plus facile à configurer et doté d’un meilleur frontal.

HypericHQ - Facile à utiliser 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 outil de surveillance intéressant. C'est plus facile à utiliser que nagios. A un agent que vous pouvez installer sur Windows et les ordinateurs clients. Je n'ai que peu exploré celui-ci jusqu'à présent.

Zenoss - Open source. J'ai été très impressionné par le professionnalisme de Zenoss. Il s’agit d’un moniteur basé sur SNMP et de nombreuses extensions permettant de surveiller les utilisateurs HP, les services Windows, le serveur ms sql et mysql. Les extensions fonctionnent toutes via SNMP, de sorte que rien ne doit être installé sur les ordinateurs clients. 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 maîtrisiez parfaitement les installations de Zope, je vous recommande de télécharger le VM pré-préparé - il fonctionne comme un rêve tout droit sorti de la boîte.

Sur le plan commercial, vous pouvez jeter un coup d'œil à quelques outils:

Kaseya coûte environ 6 000 euros par an pour 250 nœuds, si je me souviens bien, mais est un outil superbe et une communauté d'utilisateurs très active. Il est destiné au marché des MSP et permet de surveiller plusieurs systèmes d’entreprise. Il peut être utilisé en interne sans problèmes.

GFI Hounddog - plus simple que Kaseya mais très bon marché pour le moment. Ça vaut vraiment le coup d'oeil.

Il existe un certain nombre de solutions vendues en tant que systèmes MSP mais qui sont essentiellement combinées moniteurs et administrateurs distants.

Ian

Pour la journalisation centralisée avec de nombreuses fonctionnalités, je ne peux que vous recommander suffisamment rsyslog . C’est un serveur syslog open source qui peut fonctionner avec bonheur en remplacement direct du syslogd que vous connaissez et aimez. C'est maintenant le démon de choix syslog pour Ubuntu et je pense que Red Hat et Fedora pourraient également s'engager dans cette voie. J'ai trouvé qu'il était beaucoup plus facile de démarrer et de faire ce que vous voulez comme syslog-ng.

Actuellement, dans notre boutique, nous avons deux serveurs centraux rsyslog (un sur chaque site) qui reçoivent les journaux de centaines de serveurs. J'ai des alertes automatiques par e-mail chaque fois que quelque chose dans syslog déclenche une alerte ou une alerte supérieure (avec quelques modifications, bien sûr, certaines applications sont un peu alarmistes). Je pourrais probablement faire un peu plus intelligent comme le faire envoyer des choses à Nagios ou autres, mais cela nous couvre suffisamment pour nos besoins pour le moment.

Tout cela va également dans une base de données mysql (il y a aussi un support pour Oracle ou postgresql si c'est comme ça).

Il existe également une interface Web et un agent Windows pour l'envoi de journaux Eventlog au serveur rsyslog. L’interface Web n’est évidemment pas aussi élégante que le splunk, mais le travail est fait pour 0 $.

Consultez le site http://www.codeplex.com/polymon

Son source ouverte, utilise SQL Server en arrière-plan et possède une interface utilisateur élégante

Je suis d'accord que Splunk est génial. Toutefois, pour les petits environnements à dominante Linux, vous voudrez peut-être regarder quelque chose comme epylog .

Nous l'avons utilisé à l'un des endroits où je travaillais, et c'était très bien pour ce que nous voulions.

Vous ne savez pas à quel point il gérera les messages Windows syslog envoyés à un collecteur syslog Linux, mais cela peut valoir le coup.

Il suffit de faire un lien vers ma réponse ailleurs où:

Splunk est incroyablement cher: quelles sont les alternatives?

Modifier (nouveaux projets):

Les projets LogStash et Graylog2 semblent très intéressants

Voici quelques vidéos: une deux .

Quelque chose comme GFI EventsManager pourrait faire l'affaire pour environ 4 000 dollars.

• 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 SNMPv2 incluses
• Afficher les rapports sur les informations de sécurité clés en cours
• Enregistrement centralisé des événements
• Supprimez les événements «parasites» ou triviaux qui constituent un ratio élevé de tous les événements de sécurité.
• Surveillance et alerte en temps réel 24 heures sur 24, 7 jours sur 7, 365 jours par an
• Surveillez graphiquement le statut de GFI EventsManager et de votre réseau via le moniteur de statut intégré
• Prise en charge des environnements virtuels

Si vous recherchez un remplacement SysLog, vous pouvez également envisager un remplacement commercial de syslog / rsyslog tel que LogLogic, http://loglogic.com . Nous (c'est là où je travaille), nous avons un ensemble complet d'applicatifs de journalisation, de stockage et de reporting. Pour l’essentiel, c’est la capacité de collecter 100 000 messages par seconde, de plaies et de les indexer afin que des recherches puissent être effectuées.

Vous pouvez essayer logscape à partir de liquidlabs - très similaire à splunk mais qui présente é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 en passant), avec des scripts, une interface Drupal avec des scripts PHP personnalisés, les travaux.

Honnêtement, cela a pris beaucoup trop d’heures d’heures et ce n’était toujours pas Splunk.

Actuellement, je teste Splunk à la place. Ouais, ce n'est pas gratuit, mais si on regarde la situation dans son ensemble, cela pourrait être moins cher.

Avez-vous essayé php-syslog-ng? http://code.google.com/p/php-syslog-ng/

J'ai posté le fil de discussion: 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 ont facilement 5 chiffres!)

Sooooo, ce que nous avons finalement fait (parce que splunk était trop cher):

1) Nous voulions un syslog simple vers un pipeline SQL db

2) Nous avons essayé le kiwi syslog. Cela a bien fonctionné pendant une semaine, a cessé de fonctionner et le support du kiwi n'a pas pu le réparer. Nous avons donc laissé tomber 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 les prix qu'ils vous ont dit. La ventilation de base qui nous a été fournie se situait autour de 1 000 USD par 1 Go de données. Son coûteux, mais super puissant et très rapide à développer avec. En fonction de vos sources de données et de ce que vous souhaitez en faire, certains scripts python et perl peuvent vous fournir beaucoup de données similaires. La grande différence sera le temps, et apprendre à vraiment utiliser la langue pour le traitement de texte. Vous ne pouvez pas non plus obtenir d'informations IP en temps réel (des éléments tels que syslog), mais vous pouvez résoudre ce problème en obtenant un syslogger et en les exportant dans un fichier texte. Désolé, je ne peux pas vous orienter vers une solution spécifique; ce que nous ne pouvons pas utiliser splunk car nous utilisons les scripts python, perl et bash.

ELSA - Enterprise Log Search et Archive

Caractéristiques principales:

• Recherche en texte intégral sur n'importe quel mot d'un message ou d'un champ analysé.
• Regroupez-les par champ et créez des rapports basés sur les résultats.
• Planifier des recherches.
• Alerte sur les résultats de recherche sur les nouveaux journaux.
• Sauvegarder les recherches, envoyer par email les résultats de recherche sauvegardés.
• Créez des tickets d'incident basés sur les résultats de la recherche (avec plugin).
• Système complet de plugin pour des résultats.
• Exporter les résultats sous forme de lien permanent ou dans Excel, PDF, CSV et HTML.
• Intégration LDAP complète pour les autorisations.
• Statistiques pour les requêtes par utilisateur et la taille et le nombre de journaux.
• Architecture entièrement distribuée, peut gérer n nœuds avec toutes les requêtes s'exécutant en parallèle.
• Archive compressée avec un rapport supérieur à 10: 1.

Détails de la 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. Consultez donc sphinxsearch.com pour les documents. Mes statistiques proviennent de gros systèmes (16 CPU, 144 Go de RAM, 12 To HD), mais vous obtiendrez les mêmes performances que sur un système doté de 4 CPU, 8 Go de RAM et de tout disque dur de taille HD. Le système fonctionnait pour la première fois sur des serveurs IBM avec 4 Go de RAM et des disques SAN lents et fonctionnait à peu près au même débit, mais 4 Go le coupaient un peu plus près.

Détails des performances et liste des fonctionnalités principales, avec 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

Si vous recherchez une alternative beaucoup plus économique que Splunk, essayez LogZilla ( http://www.logzilla.pro ). Il s'adapte 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 à http://demo.logzilla.pro