Elasticsearch / ELK

Elasticsearch seul est un moteur d'indexation et de recherche full-text. Sa vraie valeur opérationnelle se révèle dans la stack ELK complète : Elasticsearch (indexation et requêtage) + Logstash ou Filebeat (collecte et transformation) + Kibana (visualisation, dashboards, alerting). Pour une PME, deux cas d'usage principaux où Elasticsearch joue un rôle différent : en recherche applicative, il sert d'index de lecture rapide à côté de votre base SQL transactionnelle ; en observabilité (logs, métriques, événements de sécurité), il devient le stockage primaire alimenté par les agents de collecte, avec Kibana comme interface unique de requêtage et de visualisation.

• →PostgreSQL full-text seulPour la recherche simple sur catalogue modéré : pas besoin d'un index séparé tant que les requêtes restent basiquesVoir la page
• →Meilisearch / TypesenseMoteurs de recherche modernes plus légers, alternative crédible pour les besoins de recherche pure sans pipeline d'observabilité
• →AlgoliaRecherche en SaaS, excellente UX : coût qui grimpe vite avec le volume
• →OpenSearchFork open source d'Elasticsearch sous licence Apache, défendable pour les nouveaux projets
• →Loki + GrafanaPour la centralisation de logs uniquement : plus léger qu'ELK, intégration native Prometheus, mais sans la puissance de recherche d'Elasticsearch

1. 01

   Pour la recherche applicative : PostgreSQL en source de vérité, Elasticsearch en index de lecture alimenté par change-data-capture (Debezium) ou ingestion applicative

2. 02

   Pour l'observabilité : pipeline Filebeat (collecte), Logstash (transformation), Elasticsearch (stockage primaire), Kibana (dashboards et alerting)

3. 03

   Cluster minimal 3 nœuds en production : pas de single-node, haute disponibilité non négociable

4. 04

   Choix entre Elasticsearch (SSPL) ou OpenSearch (Apache 2.0) selon votre sensibilité licence

5. 05

   Index dimensionnés et templates de mapping définis avant ingestion massive : éviter le mapping explosion

6. 06

   Rétention des indices automatisée (ILM) pour maîtriser le stockage, sinon la facture s'envole

• Pour la recherche applicative : Elasticsearch ou PostgreSQL full-text ?

  Complémentaires dans la grande majorité des cas, pas opposés. PostgreSQL reste source de vérité avec ses garanties transactionnelles, ses contraintes et ses relations. Elasticsearch vient en index de lecture, alimenté depuis Postgres, optimisé pour les requêtes complexes : recherche full-text avancée, facettes, agrégations en temps réel. Pour de la recherche simple, keyword matching sur un catalogue modéré, PostgreSQL full-text suffit largement et évite l'overhead d'un cluster séparé. Le passage à Elasticsearch se justifie quand vos besoins de recherche dépassent ce que SQL peut faire efficacement. À noter que pour l'observabilité (logs, SIEM, événements), la question ne se pose pas : Elasticsearch est lui-même la source primaire.
• Pourquoi parler de la stack ELK et pas juste d'Elasticsearch ?

  Parce qu'Elasticsearch seul est un moteur sans interface ni pipeline d'ingestion. Il ne sert à rien isolément. La valeur opérationnelle vient de la stack complète : Filebeat ou Logstash pour collecter et transformer les données (logs, événements, données métier), Elasticsearch pour indexer et requêter, Kibana pour visualiser, créer des dashboards et configurer des alertes. Déployer Elasticsearch sans pipeline ni visualisation, c'est passer à côté de l'essentiel.
• Combien coûte une stack ELK auto-hébergée ?

  Pour une PME avec quelques serveurs à monitorer ou un catalogue moyen, comptez un cluster Elasticsearch sur 3 VPS de 8-16 Go de RAM chacun, soit 80-200 €/mois d'hébergement. La mise en place initiale (cluster + pipeline Filebeat/Logstash + Kibana + alerting) demande 4 à 10 jours selon la complexité. Elastic Cloud (offre managée) commence vers 100 €/mois mais grimpe vite avec le volume.
• Elasticsearch ou OpenSearch ?

  Depuis le changement de licence Elasticsearch en 2021 (passage à SSPL non-open-source au sens OSI), OpenSearch est le fork maintenu par Amazon avec une licence Apache 2.0 pure. Compatibilité très large mais divergence croissante. Pour les nouveaux projets sans dépendance forte à des fonctionnalités Elastic récentes, OpenSearch est le choix défendable. Pour des projets existants en production sur Elasticsearch, la migration n'est pas urgente.
• Et la sécurité de la stack ELK ?

  Critique. Beaucoup d'incidents médiatisés sont liés à des clusters Elasticsearch exposés sans authentification sur Internet. Les bonnes pratiques essentielles : authentification activée (gratuite depuis 2020), TLS sur tous les nœuds, accès Kibana et admin restreints au réseau interne ou VPN, sauvegardes régulières des snapshots, rotation des indices. Bien déployée, la stack ELK est sécurisée ; mal déployée, c'est une exposition directe de toutes vos données et de tous vos logs.