Objectif

Ce guide vous aidera à comprendre ce qu'est Logs Data Platform, à quoi cette solution sert et quel est le rôle de chacun de ses composants.

Introduction

Bienvenue dans Logs Data Platform

Logs Data Platform est une plateforme qui vous permet de gérer vos logs. Elle ingère les logs générés par votre infrastructure et vos applications, les stocke, les affiche dans des tableaux de bord en temps réel et permet aux utilisateurs d'effectuer des requêtes complexes.

Logs Data Platform peut également être utilisée comme une puissante plateforme d'indexation pour tout type de document. Ce cas d'usage distinct est toutefois traité dans un autre guide.

Pour faire fonctionner Logs Data Platform, OVHcloud s'appuie sur divers logiciels open source tels qu'OpenSearch, Logstash, Flowgger, etc., afin de vous apporter de nombreuses fonctionnalités et de garantir l'interopérabilité avec la plupart des logiciels du marché.

L'objectif de cette documentation est :

• de vous donner une vue d'ensemble de l'architecture de Logs Data Platform.
• de vous présenter les concepts fondamentaux et le vocabulaire clé.
• de décrire la manière dont Logs Data Platform ingère, stocke et expose vos logs.

Après avoir lu cette documentation, vous pouvez consulter le guide Démarrage rapide afin de configurer votre service et d'envoyer vos premiers logs vers Logs Data Platform.

Le cycle de vie des logs

Le cycle de vie des logs peut être divisé en 4 phases :

• Génération : les logs sont générés par les applications, par les systèmes sur lesquels elles s'exécutent, ou même par vos services cloud. Dans la plupart des cas, ils sont stockés localement dans des fichiers. Vous pouvez décider d'en envoyer une partie ou la totalité vers Logs Data Platform, soit à l'aide d'un SDK approprié directement dans votre code, soit à l'aide d'un logiciel de transfert de logs tel que Rsyslog, Logstash, etc. Un logiciel de transfert de logs est un logiciel qui collecte les logs depuis différentes sources (des fichiers locaux, mais potentiellement aussi des systèmes distants), les transforme éventuellement et les transfère vers un système distant ou les stocke localement.

• Ingestion : les logs sont réceptionnés par les agents d'ingestion de Logs Data Platform, appelés inputs. Ceux-ci vérifient la validité de la source et le formatage des logs (en suivant ces recommandations), et peuvent ajouter, modifier ou supprimer des champs dans vos logs avant de les transférer vers le stockage.

• Stockage : après l'ingestion, vos logs sont stockés dans Logs Data Platform. Ils peuvent être stockés sous deux formes non exclusives : sous forme de données indexées exposées via des API et d'autres outils, ou sous forme de données archivées.

• Consommation : il existe de nombreuses façons d'exploiter vos logs. Sur Logs Data Platform, les utilisateurs peuvent afficher les logs en temps réel, construire des tableaux de bord, élaborer des requêtes complexes et les exécuter (via l'interface ou l'API), et même définir des alarmes.

Concepts clés de Logs Data Platform

Avant de vous donner plus de détails sur la manière dont Logs Data Platform traite chacune de ces phases, vous devez comprendre comment la répartition des ressources est gérée, ainsi que quelques autres concepts clés.

• Compte OVHcloud : le compte OVHcloud est le niveau de cloisonnement le plus élevé ; il n'est pas spécifique à Logs Data Platform.

• Service Logs Data Platform : un service Logs Data Platform est le niveau de cloisonnement le plus élevé spécifique à Logs Data Platform. Chaque service Logs Data Platform est associé à un compte OVHcloud, comme tout autre service OVHcloud.
  Dans la suite de ce guide et des autres, et sauf mention contraire, le mot service désignera un service Logs Data Platform. Différents services associés au même compte OVHcloud sont traités exactement comme s'ils étaient associés à des comptes OVHcloud différents. C'est au niveau du compte que vous gérerez les groupes d'utilisateurs, les permissions, les souscriptions aux options (comme les tableaux de bord, les inputs dédiés, etc.) et que vous créerez les flux (voir le point suivant).
  Un service Logs Data Platform possède un identifiant unique de la forme ldp-[a-z]^2-[0-9]^5, par exemple ldp-xy-98765. Les droits d'accès à ce service et aux ressources associées décrites ci-dessous sont entièrement configurables avec l'IAM OVHcloud.

• Flux : un flux Logs Data Platform est une partition logique de logs que vous créez et que vous utiliserez lors de l'ingestion, du stockage, de la visualisation ou de l'interrogation de vos logs.
  C'est à la granularité du flux que vous configurerez de nombreux éléments, tels que la durée de rétention, les politiques d'archivage, les droits d'accès, ou encore l'activation de l'option WebSocket en temps réel.
  Un flux est associé à un jeton unique que vous utiliserez lorsque vous enverrez vos logs.
  Il n'existe aucune limite au nombre de logs qu'un flux peut stocker. Les requêtes et les tableaux de bord peuvent être construits sur plusieurs flux à l'aide de Graylog (voir ci-dessous) ou d'un alias (voir également ci-dessous).

• Index : un index Logs Data Platform est, pour le dire simplement, un index OpenSearch.
  Alors que Logs Data Platform gère les index OpenSearch de manière transparente pour vous lors du traitement des logs, disposer de votre propre index est utile lorsque vous souhaitez interagir directement avec OpenSearch.
  Les cas d'usage possibles pour disposer de votre propre index vont de l'indexation d'autres éléments que des logs à l'enrichissement de vos logs lors de l'ingestion avec des données contenues dans un format de base de données. L'utilisation des index ne sera pas davantage abordée dans ce guide, par souci de clarté et de concision.

• Alias : un alias Logs Data Platform est un index OpenSearch virtuel qui est associé à une combinaison d'index ou de flux réels. Il permet d'assurer la compatibilité avec les logiciels qui s'intègrent à OpenSearch et qui nécessitent donc un index dans leur configuration, tels qu'ElastAlert, OpenSearch Dashboards ou Grafana, sans que vous ayez à gérer votre propre index.

Ingestion

La première question que vous vous poserez est la suivante : « Comment envoyer mes logs vers Logs Data Platform ? »

Pour ce faire, vous devrez configurer votre SDK ou votre logiciel de collecte de logs afin qu'il transfère vos logs vers l'un de nos agents d'ingestion, appelés inputs. Vous pouvez utiliser deux types d'inputs dans Logs Data Platform.

Inputs mutualisés

Par défaut, Logs Data Platform expose des inputs capables d'ingérer vos logs dans différents formats (Gelf, LTSV, RFC 5424, Cap'n'Proto et Beats). Pour les utiliser, vous devrez configurer votre SDK ou votre logiciel afin de cibler un endpoint attribué à votre service Logs Data Platform avec un port spécifique, en fonction du format de logs que vous utilisez et selon que vous les envoyez en UDP, TCP ou TCP/TLS (chiffré sur le réseau), puis ajouter à vos logs un champ personnalisé correspondant au jeton du flux vers lequel vous souhaitez les envoyer.

Nos inputs feront correspondre le jeton avec le flux cible, vérifieront la validité de certains champs et convertiront vos logs au format Gelf avant de les stocker sur notre plateforme.

Inputs dédiés

Si votre cas d'usage l'exige, vous avez également la possibilité de déployer des inputs dédiés managés. Plusieurs raisons peuvent le justifier :

• Pour des raisons de sécurité, vous souhaitez mieux contrôler quelles adresses IP peuvent envoyer des logs sur votre plateforme.
• Vous souhaitez personnaliser votre input afin de transformer les logs selon vos propres règles avant leur envoi vers la plateforme.

Les inputs dédiés présentent les propriétés suivantes :

• Vous pouvez choisir le logiciel exécuté entre Logstash et Flowgger, en fonction de vos besoins et de celui que vous maîtrisez le mieux.
• Ils sont automatiquement configurés pour envoyer les logs qu'ils reçoivent vers un flux choisi et renseignent automatiquement le champ de jeton OVHcloud à votre place.
• Vous pouvez choisir combien d'instances d'input vous déployez [AUTOSCALING À VENIR].
• Vous pouvez choisir le port sur lequel ils écoutent et autoriser les adresses IP habilitées à envoyer des logs.

API OpenSearch

Si vous préférez utiliser directement l'API OpenSearch pour envoyer vos logs vers Logs Data Platform, vous pouvez également le faire en suivant ce guide.

Notez que vous n'avez pas besoin d'un index ni d'un alias pour utiliser l'API OpenSearch de cette manière : il vous suffit de suivre le guide afin de configurer correctement votre logiciel.

Stockage

Il existe deux façons non exclusives de stocker vos logs dans Logs Data Platform : indexé et archivé. Le stockage se configure par flux.

Stockage indexé

Le stockage indexé est la façon « naturelle » de stocker vos logs. C'est le mode de stockage à privilégier si vous souhaitez pouvoir interroger vos logs ou construire des tableaux de bord ; il est généralement utilisé pour les logs opérationnels auxquels vous devez accéder facilement ou sur lesquels vous souhaitez configurer des alertes. Lorsque vous configurez un flux pour indexer vos logs, vous pouvez régler 2 paramètres supplémentaires :

• Rétention : vous pouvez choisir de conserver vos logs indexés pendant 14 jours, 1 mois, 3 mois ou 1 an. Passé cette durée de rétention, ils sont automatiquement supprimés du stockage indexé. Vous devez être vigilant lors de la configuration de cette durée de rétention : elle ne peut plus être modifiée (ni augmentée, ni réduite) une fois définie.

• Limite : si vous souhaitez vous assurer de ne pas dépasser une certaine limite de stockage (et donc de facturation), vous pouvez configurer une limite sur le volume de logs (en Go) indexés dans un flux. Dans ce cas, le flux cessera d'ingérer de nouveaux logs dès que cette limite sera atteinte. Lorsque des logs sont naturellement supprimés parce qu'ils atteignent la durée de rétention, ou lorsque vous modifiez la configuration de votre flux, celui-ci peut de nouveau accepter les logs entrants. Vous serez notifié lorsque certains seuils seront atteints — 80, 90 et 100 % — afin d'avoir le temps de réagir si vous avez fixé la limite trop bas.

• Activation du WebSocket : vous pouvez choisir d'activer ou non l'exposition de vos logs en temps réel via un WebSocket. L'utilisation de ce WebSocket sera abordée dans une partie ultérieure de ce guide.

Stockage archivé

Le stockage archivé est là pour vous permettre de conserver vos logs très longtemps à moindre coût, généralement pour des raisons d'audit ou des raisons légales. Ce coût très faible a toutefois une contrepartie : vous ne pourrez pas interroger ni visualiser les logs archivés. Ils seront stockés sous forme d'archives compressées que vous pourrez télécharger sur demande. Vous pouvez configurer les options suivantes lors de l'activation de l'archivage pour un flux :

• Algorithme de compression : vous pouvez choisir l'algorithme de compression utilisé et donc le format sous lequel l'archive sera mise à votre disposition.
• Rétention : vous pouvez choisir la durée pendant laquelle nous conservons les archives à votre disposition : 1, 2, 5 ou 10 ans.
• Chiffrement : vous pouvez choisir de chiffrer ou non les archives et, le cas échéant, avec quelle clé les chiffrer.

Élasticité et immuabilité

Logs Data Platform gère toute la montée en charge pour vous. Il n'existe donc pas de limitation théorique au volume de logs que vous pouvez stocker dans un flux. De plus, les logs stockés dans les flux ne peuvent pas être supprimés ni altérés individuellement, sauf en supprimant l'intégralité du flux. Une fois qu'un log est indexé dans un flux, il reste inchangé et interrogeable pendant toute la durée de rétention configurée.

Requêtes et visualisation

Maintenant que vous avez vu comment vos logs sont ingérés et stockés, voyons comment vous pouvez les exploiter.

Graylog

Logs Data Platform est fournie avec une plateforme Graylog managée à laquelle vous pouvez accéder à votre convenance avec les identifiants de votre service Logs Data Platform. Si vous ne le connaissez pas, Graylog est une interface web qui vous permet d'interroger vos logs et de construire des tableaux de bord afin d'obtenir une représentation graphique de vos logs. L'API Graylog est également exposée.

API OpenSearch

De nombreux logiciels interagissent directement avec l'API OpenSearch. L'API OpenSearch est disponible derrière le port 9200 du cluster qui vous est attribué. Étant donné que la plupart des appels à l'API OpenSearch nécessitent un index en paramètre, vous devez utiliser un alias correspondant à un ensemble de flux et d'index de votre service Logs Data Platform, ou directement un index si vous avez souscrit à cette option.

OpenSearch Dashboards (alternative à Kibana)

Si Graylog ne répond pas tout à fait à votre usage mais que vous ne souhaitez pas gérer votre propre logiciel, une instance dédiée optionnelle d'OpenSearch Dashboards peut être déployée à votre convenance et managée par OVHcloud. OpenSearch Dashboards est un fork du célèbre projet Kibana, conçu pour s'intégrer à OpenSearch plutôt qu'à ElasticSearch.

Comme OpenSearch Dashboards interagit directement avec l'API OpenSearch, vous devrez configurer vos OpenSearch Dashboards pour accéder à vos index et/ou flux, soit directement avec un index, soit via un alias, selon ce que vous souhaitez faire.

Grafana managé

Si Logs Data Platform ne propose pas de Grafana managé au sein de la plateforme, OVHcloud Public Cloud dispose d'une offre Grafana managé parfaitement adaptée pour s'intégrer directement à l'API OpenSearch exposée par Logs Data Platform. Bien qu'elle ne soit pas préconfigurée pour s'intégrer à votre plateforme d'emblée, la configuration est très simple à réaliser en suivant ce guide.

WebSocket et LDP-tail

Si vous avez activé l'exposition WebSocket pour un flux, vous pouvez vous connecter directement à un web socket afin de visualiser en temps réel les logs qui arrivent sur votre plateforme. En complément, nous avons développé un outil léger et performant nommé LDP-tail qui peut vous aider à tirer le meilleur parti de cette fonctionnalité.

LDP-tail est un outil en ligne de commande développé par OVHcloud, capable de se connecter au web socket correspondant à un flux, mais offrant également des capacités avancées de formatage et de filtrage, qui vous aident à mieux exploiter la fonctionnalité de web socket. Vous pouvez découvrir comment en tirer le meilleur parti dans ce guide.

Alertes

En suivant ce guide, vous pouvez configurer des alertes sur vos flux afin d'être averti lorsque certaines conditions sont réunies concernant le volume de logs correspondant à des critères que vous définissez. Lorsqu'elles se déclenchent, ces alertes vous envoient un e-mail à l'adresse configurée.

Récapitulatif

Pour vous aider à visualiser les informations de ce guide, l'image ci-dessous résume ce que chaque composant de Logs Data Platform vous apporte :

Aller plus loin

Après avoir lu cette documentation, vous devriez être familier de la plupart des concepts utilisés dans Logs Data Platform. Lorsque vous vous sentirez prêt à travailler avec Logs Data Platform, rendez-vous sur le guide de démarrage rapide afin de configurer votre service, créer un premier flux, envoyer vos premiers logs vers Logs Data Platform et les voir apparaître dans Graylog !