Meetup Elasticsearch Paris #8 PSA

Elasticsearch, Logstash, Kibana et Marvel : Un écosystème très riche

Transcript

1. Log Processing ElasticSearch Meetup ElasticSearch France QUERY FILTERING Lundi 7 juillet 2014 For the first time Alexandre Fricker Architecte Infrastructure BigData : gestion des Logs … For 6 month Architecte Infrastructure Sauvegarde … For 15 years Ingénieur en Informatique … For 27 years Passionné d’Informatique, Geek … For 37 years Human on Earth … For almost 50 years Light / Dark Elasticsearch, Logstash , Kibana et Marvel : Un écosystème très riche
2. Log Processing ElasticSearch Pourquoi des Logs QUERY FILTERING refreshed from time to time Depuis l’origine de l’informatique, l’exécution d’un programme s’est toujours accompagnée de la génération de fichier trace sous forme tout d’abord d’un télétype qui imprimait sur papier le suivi de toutes les actions qui se déroulaient sur l’ordinateur mono-tâche. Les Ordinateurs ont alors évolué devenant multitâches puis multisessions. Les traces d’exécution se sont alors spécialisées : • Les traces systèmes qui suivent le déroulement et les alertes des différents composants logiciels et matériels aussi appelé syslog. • Les traces de sécurité qui suivent les actions de chaque utilisateurs sur un système utmp et wtmp qui effectue ce que l’on appelle du logging. • Les traces applicatives, qui pour chaque programme, suivant le choix des développeurs, consignent le déroulement de son programme, logiciel ou progiciel. Dans les entreprises ces différents logs sont la responsabilité de différentes équipes : • Administrateurs systèmes. • Equipe responsable de la sécurité informatique. • Equipe d’exploitation de l’application. Ces différents logs sont exploités dans différents contextes : • Surveillance proactive par le suivi des warning • Détection d’incidents • Analyse des causes d’un incident. Mais peuvent aussi être détournés : • Pour générer de la communication entre progiciel, • Faire de la métrologie, • Mesurer la qualité de service. Light / Dark From a long time ago
3. Log Processing Pourquoi des Logs QUERY FILTERING refreshed from time to time From a long time ago Depuis l’origine de l’informatique, l’exécution d’un programme s’est toujours accompagnée de la génération de fichier trace sous forme tout d’abord d’un télétype qui imprimait sur papier le suivi de toutes les actions qui se déroulaient sur l’ordinateur mono-tâche. Les Ordinateurs ont alors évolué devenant multitâches puis multisessions. Les traces d’exécution se sont alors spécialisées : • Les traces systèmes qui suivent le déroulement et les alertes des différents composants logiciels et matériels aussi appelé syslog. • Les traces de sécurité qui suivent les actions de chaque utilisateurs sur un système utmp et wtmp qui effectue ce que l’on appelle du logging. • Les traces applicatives, qui pour chaque programme, suivant le choix des développeurs, consignent le déroulement de son programme, logiciel ou progiciel. Dans les entreprises ces différents logs sont la responsabilité de différentes équipes : • Administrateurs systèmes. • Equipe responsable de la sécurité informatique. • Equipe d’exploitation de l’application. Ces différents logs sont exploités dans différents contextes : • Surveillance proactive par le suivi des warning • Détection d’incidents • Analyse des causes d’un incident. Mais peuvent aussi être détournés : • Pour générer de la communication entre progiciel, • Faire de la métrologie, • Mesurer la qualité de service. Light / Dark
4. Log Processing Trop de log tue les logs… ou l’admin QUERY FILTERING refreshed from time to time From long ago Aujourd’hui, nous vivons une complexification à outrance des infrastructures : Le serveur physique héberge un ou plusieurs serveurs logiques par la méthode du partitionnement. Chaque serveur logique peut contenir plusieurs serveurs virtuels, chacun avec son propre système d’exploitation. Chaque serveur virtuel héberge de nombreux logiciels qui peuvent s’exécuter dans une jvm (machine virtuelle Java) dédiée. Chacune de ces couches matérielles ou logicielles possède ses propres logs. De plus, une seule application peut maintenant faire appel à de multiples couches applicatives et en même temps être répartie sur des dizaines de serveurs. Dans ce cas le responsable d’une application a la mission quasi impossible de maintenir cet ensemble en état de marche dans cette tour de Babel, car en plus chaque couche applicative et chaque type de matériel aura son propre format de log et son propre mode d’horodatage. De là intervient le besoin d’un outil ou plutôt d’un ensemble d’outils permettant à terme : De suivre les logs De naviguer dans les logs De rechercher … De suivre des comportements De prédire des évènements De lutter contre des comportements Mais cela c’est le rôle de la SIEM (Security Information and Event Mangement) et de progiciel tel SPLUNK, IBM/QRadar et HP ARCSIGHT ESM. Mais pour le reste il existe des solutions payantes et d’autres gratuites ou presque, et même mieux open source. L’une de ces solutions open source est l’écosystème ELK : • ElasticSearch, • Logstash, • Kibana Light / Dark
5. Log Processing ElasticSearch Architecture QUERY FILTERING refreshed from time to time From long ago 1) D’abord Il faut récupérer et envoyer la log : pour les équipements connectés sur le réseau il faut d’abord les centraliser via un listener Syslog comme syslog-ng (pour les serveurs Linux, Solaris et Windows on peut utiliser directement Logstash) puis il faut encapsuler la donnée avant de l’expédier, une structure Json (c’est le format des documents Java) élémentaire est alors constituée : timestamp, host, path, type et le message proprement dit, c’est la fonction de Shipper. { "message": "Apr 14 05:09:13 xxxxxx raslogd: 2014/04/21-05:00:53, [SEC-1203], 36583,, INFO, xxxxxx, Login information: Login successful via TELNET/SSH/RSH. IP Addr: xxx.yyy.zzz.ttt", "@timestamp": "2014-04-14T03:09:14.087Z", "type": "brocade", "host": “yyyyyy", "path": "/var/log/remote.log", } 2) Ensuite il faut résister à la pression, stocker et distribuer le travail, c’est le rôle de Redis (il est utilisé comme centre de tri, mais en fait c’est une base de données clé/valeur) ou RabbitMQ, c’est le rôle de Broker. Light / Dark
6. Log Processing ElasticSearch Architecture QUERY FILTERING refreshed from time to time From long ago Light / Dark 3) Il faut après enrichir et uniformiser (notamment pour leur horodatage) les logs collectés c’est le rôle de Logstash et son univers de modules extensible et personnalisable et notamment son acolyte Grok, c’est la fonction d’Indexer. { "message": "Apr 14 05:09:13 xxxxxx raslogd: 2014/04/21-05:00:53, [SEC-1203], 36583,, INFO, xxxxxx, Login information: Login successful via TELNET/SSH/RSH. IP Addr: xxx.yyy.zzz.ttt", "@timestamp": "2014-04-14T03:09:14.087Z", "type": "brocade", "host": “yyyyyy", "path": "/var/log/remote.log", "clust": "prod", "idx": "aoss", "NHOST": “xxxxxx", "NPROCESS": "raslogd", "MESSCAT": "SEC-1203", "MESSID": "36583", "SWseverity": "INFO", "SWHOST": “xxxxxx", "SWMESS": "Login information: Login successful via TELNET/SSH/RSH. IP Addr: xxx.yyy.zzz.ttt", "TIMESTAMP": "2014-04-14T05:09:13.000+02:00", "EVT_TIMESTAMP": "2014-04-21T05:00:53.000+02:00", "DOMAINE": "inetpsa", "TYPEDOMAINE": "com" }
7. Log Processing ElasticSearch Architecture QUERY FILTERING refreshed from time to time From long ago Light / Dark 4) Il faut un bibliothécaire qui indexe, stocke, distribue, sécurise, recherche et suit la croissance des logs aussi souple et rapide que possible, il s’agit d’une base de données in memory qui en plus fait de l’indexation full texte : ElasticSearch, c’est la fonction de Search & Storage. Pour réaliser toutes ces fonctions Elasticsearch regroupe ces données sous formes d’index quotidiens, qu’il découpe en shard pour donner de la performance en lecture et écriture, et en réplicat afin de lui donner robustesse et proximité. Par ailleurs il peut fonctionner soit comme un serveur unique, soit en cluster applicatif avec croissance du nombre de nœuds à chaud, soit comme un service dans le Cloud. 5) Il faut des modules d’interrogation en mode ligne (Elasticsearch) ou d’interrogation avec un GUI souple et personnalisable Kibana, c’est la fonction de Web Interface EVT_TIMESTAMP NHOST SWseverity MESSCAT SWMESS 2014-04-21T05:00:53.000+02:00 xxxxxx INFO SEC-1203 Login information: Login successful via TELNET/SSH/RSH. IP Addr: xxx.yyy.zzz.ttt
8. Log Processing ElasticSearch Architecture QUERY FILTERING refreshed from time to time From long ago Light / Dark 6) Il faut une console de supervision et d’administration, il existe depuis plusieurs années de nombreux modules pour ce rôle, je n’en garderai que 3 : ElasticsearchHQ (pour l’administration du cluster Elasticsearch) et Paramedic (pour la surveillance et le monitoring jusqu’au plus bas niveau du Shard) avant de parler du dernier né cette année, qui est développé par la même équipe et qui s’appuie sur les mêmes composants : arrivé en début d’année, le merveilleux, le surprenant Marvel (pour un monitoring historisé jusqu’au plus fin détail). Marvel Bilan : Avec tout cela on a tout pour suivre les logs mais aussi pour construire l’essentiel d’une application personnalisable par l’utilisateur sans développement ou presque.
9. Log Processing ElasticSearch Modules et services complémentaires QUERY FILTERING refreshed from time to time From long ago Light / Dark Enfin un dernier module dont je n’ai pas encore parlé car il n’est disponible dans sa version GA que depuis le 27/05/2014, ES for Hadoop qui donne à ElasticSearch l’accès au stockage Hadoop en plus d’EC2 et Amazon mais aussi les recherches en temps réel aux différents composant Hadoop : (Map/Reduce, Hive, Pig et Cascading) Il existe déjà 3 services d’indexation ElasticSearch dans le Cloud : Bonsai.io : qui propose un service avec facturation au mois en fonction du volume et type de stockage choisi. Qbox.io : qui propose un service avec facturation à l’heure ou au mois en fonction de la capacité RAM, du volume et type de stockage choisi. Found.no : qui propose un service à l’heure ou au mois en fonction du nombre de Datacenter, du volume et type de stockage choisi.
10. Log Processing ElasticSearch Architecture PSA QUERY FILTERING refreshed from time to time From long ago Architecture technique à PSA 4 clusters: Test, Preprod, Prod, Mon Light / Dark
11. Log Processing ElasticSearch Pilote à PSA QUERY FILTERING refreshed from time to time From long ago Focus sur un pilote SPCD : ITWEB Code retour Commande http Localisation client web Traitement des zones isolées par mise en place d’un broker Redis dans la zone SGP Light / Dark
12. Log Processing ElasticSearch Pilote à PSA QUERY FILTERING refreshed from time to time From long ago Focus sur un pilote AOSS: Log switch SAN, routeur SAN, appliance SVC, baie Netapp Suivi gràce au listener syslog de logstash A permis de révéler un audit sécurité en cours Une page par type de données Développement d’un Web de gestion des alertes prévu Light / Dark
13. Log Processing ElasticSearch Pilote à PSA QUERY FILTERING refreshed from time to time From long ago Focus sur un pilote SPCD : Customer@ Exploitation vie courante Suivi incident Mesure qualité de service Light / Dark
14. Log Processing ElasticSearch Pilote à PSA QUERY FILTERING refreshed from time to time From long ago Focus sur un pilote SIFA: PMM Il s’agit du développement niche initial en prod depuis 1 ou 2 ans Gestion des log directement dans Elasticsearch en JSON en intégré plus de fichiers à plat. Ce qui permet de consulter les log en multilingue. Pilote : Centralisation des log pour isolation des serveurs en production même pendant l’analyse par étude et indus Light / Dark
15. Log Processing ElasticSearch Pilote à PSA QUERY FILTERING refreshed from time to time From long ago Focus sur un pilote SIPP: PLM Point d’accès unique des log de 35 serveurs et 6 couches applicatives 13 à 31 M de log par jours Enrichissement des logs en cours A permis d’éviter le développement d’un outil spécifique de centralisation et de gestion des log. Light / Dark
16. Log Processing ElasticSearch Lettre n° 3.14159265359 QUERY FILTERING refreshed from time to time From long ago Bilan A l’origine un pilote prévu, aujourd’hui 5 fournissent des données et 3 autres vont être mis en place Sans oublier le propre traitement des log de Logstash, Redis, Elasticsearch, Curator et Apache pour Kibana et HQ Négatif Stabilité pas parfaite de Logstash : nécessité de garantir la transmission de l’intégralité des messages. Doc logstash très light Scalabilité d’Elasticsearch à étalonner aujourd’hui 45 M de log par Nœud me parait faible (au moins 40 B sur Splunk) Absence d’export SVG ou PNG de Kibana Absence agrégation données dans Kibana, annoncée dans Kibana 4 en beta fin 2014 Light / Dark Positif Prise en compte d’un nouveau pilote en 2 heures pour une indexation full texte seule Sous 2 jours pour un enrichissement complet par Logstash et grok et une utilisation autonome dans kibana Cloning évenement dans logstash pour envoie vers test, preprod et prod Logstash + grok couteau suisse très riche.
17. Log Processing ElasticSearch Lettre n° 1.61803398875 QUERY FILTERING refreshed from time to time From long ago Lettre au Père Noël Pour atteindre la perfection Light / Dark Logstash Une documentation de la qualité de celle d’Elasticsearch Interface Kibana like pour reconnaissance format log avec grok: Grofana ou Logana Relecture fichier de conf sans arrêt relance type kill -1 Elasticsearch Application des alias lors de la création des index Kibana Inclusion graph avec couleur comme filter et épaisseur comme count Inclusion graph type gestion de planning Marvel Gestion de plusieurs clusters Elasticsearch avec statut et sélection Surveillance des process Logstash, Elasticsearch et web Surveillance de Redis, RabbitMQ … : du broker mis en place dans l’architecture Elasticsearch