Skip to main content
Connexion
Démarrer un essai gratuitContacter le service commercial

Elastic Common Schema et OpenTelemetry : l'observabilité et la sécurité en toute indépendance

Par

Elastic Observability and Security Teams

ecs-otel-announcement-1.jpeg

Lors de la conférence KubeCon Europe, on a annoncé qu'Elastic Common Schema (ECS) avait été accepté par OpenTelemetry (OTel) comme contribution au projet. L'objectif ? Faire converger ECS et les conventions sémantiques (SemConv) d'OpenTelemetry dans un seul et même schéma ouvert géré par OpenTelemetry. Dans cette FAQ, vous trouverez des informations sur les avantages qu'apporte Elastic Common Schema à OpenTelemetry, sur la façon dont cette fusion permettra à l'industrie de mettre en place un schéma commun et sur les répercussions en matière d'observabilité et de sécurité.

Sur quoi porte l'annonce ? 

Elastic met son projet open source, Elastic Common Schema (ECS), à la disposition du projet OpenTelemetry de la Cloud Native Computing Foundation (CNCF) pour favoriser la mise en place d'un schéma commun pour les données d'observabilité et de sécurité. Un schéma commun aide à normaliser les données et ainsi, à mieux les analyser, à mieux les visualiser et à les mettre plus facilement en corrélation sur n'importe quelle plateforme d'observabilité ou de sécurité. Grâce à l'adoption d'ECS par OpenTelemetry, la communauté des utilisateurs OTel bénéficie d'un schéma commun mature et éprouvé pour les indicateurs, les logs, les traces, les ressources (hôtes, conteneurs, etc.) et les événements de sécurité. 

Que doivent savoir les utilisateurs Elastic ?

Elastic préservera les investissements de nos utilisateurs dans ECS. L'évolution continue d'ECS dans OpenTelemetry donnera aux utilisateurs d'ECS une direction claire pour adopter ce que nous considérons comme la norme la plus répandue du secteur pour les conventions sémantiques.

Elastic apportera sa contribution et travaillera en étroite collaboration avec la communauté OTel pour fusionner ECS et les conventions sémantiques d'OpenTelemetry de manière appropriée au fil du temps. Elastic continuera à prendre en charge les données utilisateur dans le format ECS actuel, même si le schéma peut évoluer suite à la fusion. Les utilisateurs auront le choix de continuer à ingérer et à utiliser le format ECS actuel ("frozen") ou de migrer vers le nouveau schéma.

Elastic fournira des conseils et des outils pour faciliter la migration des utilisateurs qui opteront pour le nouveau schéma.

Pourquoi fournir ECS à OTel ?

La fusion des conventions sémantiques (SemConv) d'OpenTelemetry et d'Elastic Common Schema permet d'établir un schéma de dénomination commun pour les ressources, les indicateurs, les logs, les traces, les événements de sécurité et les événements d'audit, qui peut être appliqué sur l'ensemble de la base de code, des bibliothèques et des plateformes. La convergence d'ECS et des conventions sémantiques d'OTel apportera de nombreux avantages, parmi lesquels :

  • une harmonisation des efforts autour d'une seule et même norme en vue d'une large adoption par les entreprises/services générant des données d'événement ;
  • une meilleure visibilité et une meilleure analyse de la cause première pour les opérations ;
  • la possibilité pour les fournisseurs et la communauté de se consacrer à l'utilisation de fonctionnalités d'observabilité et de sécurité enrichies, plutôt que d'avoir à gérer des tâches de transformation des données ;
  • la possibilité d'effectuer des analyses transversales sur différents types de signaux, notamment entre la sécurité et l'observabilité ;
  • la démocratisation d'OpenTelemetry, ainsi que l'évolution et la convergence continues des domaines de l'observabilité et de la sécurité.

Pourquoi un schéma commun est-il nécessaire pour les entreprises ?

Trop souvent, les entreprises se retrouvent en difficulté lorsqu'elles cherchent à comprendre quand un problème s'est produit (visibilité) et pourquoi (analyse de la cause première). Cette problématique opérationnelle s'explique par le fait que les données sont cloisonnées et structurées selon des schémas différents. Par conséquent, les entreprises passent beaucoup de temps à transformer (inutilement) les données plutôt qu'à comprendre le problème, analyser la cause première ou optimiser les opérations.

En ayant des données structurées selon un schéma commun, les équipes opérationnelles pourront axer leurs efforts sur l'identification, la résolution et la prévention des problèmes, ainsi que sur la réduction du temps moyen de résolution (MTTR). Elles peuvent aussi réduire les coûts, car elles n'ont pas besoin d'avoir de données en doublon ni d'avoir à les transformer pour les normaliser. 

Pouvez-vous fournir un exemple illustrant un schéma commun ?

Un exemple simple est lorsque l'adresse IP d'un client est envoyée à partir de plusieurs sources qui monitorent ou gèrent les données télémétriques concernant ce client. La plateforme d'observabilité reçoit cette information en plusieurs formats :

src:10.42.42.42
client_ip:10.42.42.42 
apache2.access.remote_ip: 10.42.42.42 
context.user.ip:10.42.42.42 
src_ip:10.42.42.42

Le fait d'avoir différentes représentations de l'adresse IP induit une certaine complexité en ce qui concerne l'analyse des problèmes potentiels, voire même leur identification. Sans sémantique claire ni schéma commun pour les données observées, les solutions d'observabilité peinent à effectuer certaines tâches de manière automatique, comme la mise en corrélation, l'analyse et l'identification des causes premières. C'est pourquoi les équipes opérationnelles (SRE, DevOps, etc.) doivent comprendre ces multiples définitions, savoir comment les trouver, puis normaliser manuellement les données pour les analyser.

Avec un schéma commun, toutes les données entrantes ont un format normalisé. Si nous reprenons l'exemple précédent, chacune des sources identifierait l'adresse IP du client de la même façon :

source.ip:10.42.42.42

Les solutions d'observabilité et de sécurité peuvent désormais s'appuyer sur un schéma de données défini de manière cohérente pour automatiser la mise en corrélation des données et leur analyse. Désormais, les entreprises consacrent leur temps à comprendre le problème, à identifier la cause première et à optimiser les opérations, plutôt qu'à effectuer des transformations inutiles.

Qu'est-ce qu'Elastic Common Schema (ECS) ?

Elastic Common Schema (ECS) est une spécification open source (Apache 2.0) développée avec l'aide de la communauté d'utilisateurs Elastic qui définit un ensemble commun de champs à utiliser lors du stockage de données d'événement dans Elasticsearch. Le but d'ECS est d'inciter les utilisateurs d'Elasticsearch à normaliser leurs données d'événement, afin qu'ils puissent les analyser, les visualiser et les mettre en corrélation plus facilement. ECS constitue la base sur laquelle les solutions Elastic Observability et Elastic Security s'appuient. Il s'agit d'un schéma éprouvé et répandu, qui a évolué et qui s'est développé au fil des ans depuis son lancement en 2019.

Que sont OpenTelemetry et les conventions sémantiques d'OpenTelemetry ?

OpenTelemetry (OTel) est un projet open source qui fournit une suite de spécifications, d'outils, d'API et de kits de développement logiciel servant à générer, collecter, traiter et exporter des données télémétriques (indicateurs, logs et traces), lesquelles permettent de comprendre les performances et les comportements des logiciels. Il s'agit du deuxième projet à avoir la plus forte croissance de l'écosystème de la CNCF.

Les conventions sémantiques (SemConv) d'OpenTelemetry établissent des noms communs pour différents types d'opérations et de données. L'utilisation des SemConv d'OpenTelemetry présente l'avantage de suivre un schéma de dénomination commun qui peut être normalisé sur une base de codes, des bibliothèques et des plateformes pour les utilisateurs finaux d'OTel. Autre avantage non négligeable : le fait de ne dépendre d'aucune sémantique spécifique à un fournisseur. Avec les SemConv d'OpenTelemetry, les utilisateurs de données ne dépendent plus d'un seul fournisseur. Ils peuvent donc passer facilement d'une solution d'observabilité à l'autre (idem pour les solutions de sécurité avec la contribution d'ECS) sans qu'ils aient à adapter leur collecte de données.

Comment la contribution d'ECS aide-t-elle OpenTelemetry ?

Le plus important pour OpenTelemetry est d'accélérer la définition du schéma pour décrire les événements de log et de sécurité. Les personnes ayant apporté leur contribution à ECS ont déjà défini un ensemble de conventions sémantiques de logging unifié et bien accepté, qui peut être adopté dans OTel. ECS sert majoritairement à structurer les logs utilisés dans les cas d'utilisation d'observabilité et de sécurité.

Cette convergence va accélérer l'intégration des logs créés par les fournisseurs et des logs de composants d'OTel (par exemple, les récepteurs et modules de traitement des logs du collecteur OTel). L'objectif est de définir, pour la majorité des types de systèmes populaires, des conventions sémantiques qui ne dépendent pas de fournisseurs, ainsi que de prendre en charge les composants créés par les fournisseurs ou des composants open source (par exemple, logs d'accès HTTP, logs réseau, logs d'accès système/authentification), afin de renforcer la corrélation d'OTel vers ces nouveaux signaux. Les utilisateurs tireront aussi parti d'intégrations de logs prêtes à l'emploi entièrement reconnues par les produits et services d'observabilité et de sécurité compatibles avec OTel. 

La maturité d'ECS pour la sécurité offre une super opportunité d'améliorer l'utilité des données collectées avec OpenTelemetry pour les cas d'utilisation de sécurité. L'incorporation d'ECS permettra aux utilisateurs OTel de structurer les événements de sécurité.

Y aura-t-il des changements au niveau de la licence ECS ?

Non, il n'y aura aucun changement. ECS est proposé sous licence Apache 2.0, tout comme OpenTelemetry.

Est-ce qu'Elastic prend OpenTelemetry aujourd'hui ?

Elastic prend OTel en charge de façon native. Les utilisateurs Elastic peuvent envoyer des données OTel directement à partir d'applications ou via le collecteur OTel dans Elastic APM, qui traite à la fois les SemConv d'OTel et ECS. Avec cette prise en charge native d'OTel, toutes les fonctionnalités d'Elastic APM sont disponibles avec OTel. Consultez la documentation d'Elastic pour en savoir plus sur l'intégration d'OTel.

elastic otel microservices

Où puis-je obtenir plus d'informations concernant ECS et la prise en charge d'OpenTelemetry par Elastic ?

Vous trouverez ci-dessous des informations et de la documentation supplémentaires sur la prise en charge et les intégrations d'OpenTelemetry par Elastic ci-dessous :

Sign up for Elastic Cloud free trial

Spin up a fully loaded deployment on the cloud provider you choose. As the company behind Elasticsearch, we bring our features and support to your Elastic clusters in the cloud.

Start free trial