OpenSearch Index as a Service

Objectif

OpenSearch est l'un des principaux composants de Logs Data Platform, considéré comme l'un des moteurs de recherche et d'analyse les plus puissants. Dès le départ, nous avons proposé la possibilité d'héberger un index OpenSearch Dashboards pour les métadonnées de votre OpenSearch Dashboards. Index As A Service est l'étape suivante. Vous pouvez désormais utiliser un index entièrement libre pour presque n'importe quel usage, qu'il s'agisse de documents complexes, de rapports ou même de logs. Grâce à l'API OpenSearch, vous pourrez utiliser la plupart des outils de l'écosystème OpenSearch.

Prérequis

Voici ce que vous devez savoir pour commencer :

• Vous avez créé un compte Logs Data Platform
• Vous avez accès au port 9200 de votre cluster (rendez-vous sur la page Home du manager pour connaître l'adresse de votre cluster).

En pratique

Premiers pas avec un index OpenSearch

Conventions de nommage des index

Il existe deux façons de créer un index OpenSearch :

• Utiliser le manager Logs Data Platform.
• Utiliser l'API OpenSearch.

Pour créer un index OpenSearch avec le manager Logs Data Platform, vous devez vous rendre sur la page des index et cliquer sur Ajouter un index dans la section des index OpenSearch

Choisissez simplement un suffixe pour votre index. Le nom final suivra cette convention :

<service_name>-i-<suffix>.

Le service name est l'identifiant de votre service Logs Data Platform. Il est différent du nom d'utilisateur utilisé par les utilisateurs non-IAM. Le service name commence par ldp (par exemple ldp-ab-12345). À l'inverse, le nom d'utilisateur commence par logs (par exemple logs-ab-12345). Dans ce guide, nous utiliserons <service_name> ou <username> comme balises pour vous permettre de distinguer les deux usages. Vous trouverez ces deux informations dans le Control Panel Logs Data Platform.

Pour chaque index, vous pouvez spécifier le nombre de shards. Un shard est le composant principal d'un index. Sa capacité de stockage maximale est fixée à 25 Gio (par shard). Un plus grand nombre de shards signifie davantage de volume, davantage de parallélisme dans vos requêtes, et donc davantage de performance. Vous pouvez également, si vous le souhaitez, être notifié lorsque votre index approche de sa taille critique. Une fois votre index créé, vous pouvez l'utiliser immédiatement.

Lorsque vous créez un index via l'API OpenSearch, vous pouvez également spécifier le nombre de shards. Notez que le nombre maximal de shards par index est limité à 16. Les outils compatibles OpenSearch peuvent désormais créer des index sur le cluster, à condition de respecter les conventions de nommage.

Configuration IAM

Si vous avez activé IAM sur votre compte, vous devez d'abord créer une politique et accorder les droits de création à l'utilisateur ou au compte de votre choix. Consultez le guide sur la politique IAM pour LDP.

Les droits relatifs à la gestion des éléments OpenSearch via les API OVHcloud sont :

Les droits relatifs à la gestion des éléments OpenSearch via l'API OpenSearch sont :

Attachez librement ces droits à vos politiques, que vous ayez besoin d'interagir directement avec l'API OpenSearch ou via le manager.

Le préfixe de tous les index ou alias créés est <service_name>. Exemple : ldp-ab-12345-i-my-awesome-index. Pour interagir avec l'API OpenSearch, vous pouvez soit créer des comptes de service et exploiter le workflow OpenID, soit créer des utilisateurs locaux avec leur Personal Access Token via l'API :

Cet appel retournera un bearer token pour un utilisateur local spécifique.

Vous pouvez ensuite utiliser le jeton de votre utilisateur pour créer un index ou écrire des documents dans vos index.

ldp@laptop curl -H 'content-type: application/json' --oauth2-bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -XPUT 'https://gra2.logs.ovh.com:9200/ldp-ab-12345-i-another-index' -d '{ "settings" : {"number_of_shards" : 2}}'

Vous pouvez également utiliser le schéma d'authentification basique avec votre bearer token comme mot de passe, pour les systèmes qui ne prennent pas en charge un bearer token (ou un en-tête Authentication Bearer personnalisé). La seule contrainte est d'utiliser un nom d'utilisateur commençant par le préfixe pat_jwt_. Par exemple :

ldp@laptop curl -H 'content-type: application/json' -u pat_jwt_user_one:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -XPUT 'https://gra2.logs.ovh.com:9200/ldp-ab-12345-i-another-index' -d '{ "settings" : {"number_of_shards" : 2}}'

Ici, dans les deux exemples, l'index créé aura 2 shards et apparaîtra dans votre panneau. Vous pouvez ensuite l'attacher à une politique IAM.

Utilisateurs legacy

Si vous n'avez pas activé IAM sur votre compte (ce mode sera obsolète), le préfixe des index est <username>:.

Voici un exemple avec une commande curl pour l'utilisateur logs-ab-12345 et l'index logs-ab-12345-i-another-index sur le cluster gra2 :

$ curl -u logs-ab-12345:mypassword -XPUT -H 'Content-Type: application/json' 'https://gra2.logs.ovh.com:9200/logs-ab-12345-i-another-index' -d '{ "settings" : {"number_of_shards" : 1}}'

Indexer des données

Les index OpenSearch de Logs Data Platform sont compatibles avec l'API REST OpenSearch. Vous pouvez donc utiliser de simples requêtes HTTP pour indexer et rechercher vos données. L'API est accessible derrière un endpoint https sécurisé, avec authentification obligatoire. Vous pouvez récupérer l'endpoint de l'API sur la page Home de votre service. Voici un exemple simple pour indexer un document avec curl sur le cluster <ldp-cluster>.logs.ovh.com.

$ curl --oauth2-bearer <iam-token-value> -XPUT -H 'Content-Type: application/json' 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>`-i-`<suffix>`/_doc/1' -d '{ "user" : "Oles", "company" : "OVH", "message" : "Hello World !", "post_date" : "1999-11-02T23:01:00" }'

Voici une explication rapide de cette commande :

• La commande HTTP PUT permet de créer ou de modifier un document.
• L'en-tête Content-Type: application/json est obligatoire pour indiquer que les données seront au format JSON.
• L'adresse contient l'endpoint du cluster suivi du nom de votre index
• Le _doc juste après le nom de l'index doit être utilisé comme type du document.
• Le 1 ici est l'ID de votre document, qui peut être n'importe quelle chaîne de caractères.
• Le corps de la requête est un simple document JSON qui sera indexé.

Cette commande retournera un simple corps de réponse indiquant si le document a bien été indexé par tous les shards concernés.

{
   "_id": "1",
   "_index": "`<service_name>-i-<suffix>`",
   "_primary_term": 1,
   "_seq_no": 0,
   "_shards": {
      "failed": 0,
      "successful": 2,
      "total": 2
   },
   "_type": "_doc",
   "_version": 1,
   "result": "created"
}

Rechercher vos données

Il existe plusieurs façons de rechercher vos données, et c'est un domaine dans lequel l'API REST OpenSearch excelle. Vous pouvez soit récupérer directement vos données avec une requête GET, soit les rechercher avec les API de recherche. Pour récupérer le document indexé précédemment, utilisez la requête curl suivante :

$ curl --oauth2-bearer `<iam-token-value>` -XGET 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_doc/1'
{"_id":"1","_index":"`<service_name>-i-<suffix>`","_primary_term":1,"_seq_no":0,"_source":{"company":"OVH","message":"Hello World !","post_date":"1999-11-02T23:01:00","user":"Oles"},"_type":"_doc","_version":1,"found":true}

Pour effectuer une recherche simple, vous pouvez utiliser soit le Query DSL, soit une recherche par URI. Voici un exemple simple avec une recherche par URI :

$ curl --oauth2-bearer `<iam-token-value>` -XGET 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_search?q=user:Oles'
{"_shards":{"failed":0,"skipped":0,"successful":1,"total":1},"hits":{"hits":[{"_id":"1","_index":"`<service_name>-i-<suffix>`","_score":0.2876821,"_source":{"company":"OVH","message":"Hello World !","post_date":"1999-11-02T23:01:00","user":"Oles"},"_type":"_doc"}],"max_score":0.2876821,"total":1},"timed_out":false,"took":31}

Cas d'usage : enrichir les données de logs à la volée

L'exemple suivant montre comment les logs de votre application e-commerce peuvent être envoyés à Logs Data Platform à chaque commande d'un produit. Il consigne la commande du client en utilisant un ID pour le nom du client. Pour des raisons de performance, ou peut-être par choix de conception, l'application ne va pas chercher le nom complet du client ni d'autres informations dans la base de données clients simplement pour produire un log. Vous pouvez ajouter ces informations à la volée grâce à un index OpenSearch et un collecteur Logstash sur Logs Data Platform.

Alimenter un index avec les informations des clients

La première chose à faire est d'indexer quelques informations client. L'extrait ci-dessous correspond à une entrée de l'index client.

{
    "firstName": "Jon",
    "lastName": "Snow",
    "age": 22,
    "address":
    {
        "streetAddress": "21 2nd Street",
        "city": "Winterfell",
        "state": "North",
        "postalCode": "14578",
        "geolocation":
        {
            "lat": 54.369488,
            "long": -5.574768
        }
    },
    "phoneNumber":
    [
        {
          "type": "home",
          "number": "212 555-1234"
        },
        {
          "type": "mobile",
          "number": "102 555-4567"
        }
    ]
}

Pour indexer plusieurs documents à la fois, il est plus efficace d'utiliser l'API bulk. Voici un petit extrait de 3 utilisateurs que vous pouvez utiliser pour tester.

{ "index" : { "_index" : "`<service_name>-i-<suffix>`" } }
{ "userId": "1", "firstName": "Jon","lastName": "Snow", "age": 22, "address": { "streetAddress": "21 2nd Street", "city": "Winterfell", "state": "North", "postalCode": "14578",  "geolocation": { "lat": 54.369488, "long": -5.574768 } }, "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, { "type": "mobile", "number": "102 555-4567" } ] }
{ "index" : { "_index" : "`<service_name>-i-<suffix>`" } }
{ "userId": "2", "firstName": "Cersei","lastName": "Lannister", "age": 43, "address": { "streetAddress": "1 Palace Street", "city": "King's Landing", "state": "The Crownlands", "postalCode": "26863",  "geolocation": { "lat": 42.639758, "long": 18.1094725 } }, "phoneNumber": [ { "type": "home", "number": "212 555-6789" }, { "type": "mobile", "number": "102 555-8901" } ] }
{ "index" : { "_index" : "`<service_name>-i-<suffix>`" } }
{ "userId": "3", "firstName": "Daenerys","lastName": "Targaryen", "age": 22, "address": { "streetAddress": "3 Blackwater Bay Ave", "city": "Dragonstone", "state": "Dragonstone", "postalCode": "75197",  "geolocation": { "lat": 43.300097, "long": -2.261580 } }, "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, { "type": "mobile", "number": "102 555-2345" } ] }

Une requête bulk est une succession d'objets JSON suivant cette structure :

 action_and_meta_data\n
 optional_source\n
 action_and_meta_data\n
 optional_source\n
 ...
 action_and_meta_data\n
 optional_source\n

Vous pouvez, en une seule requête, demander à OpenSearch d'indexer, de mettre à jour ou de supprimer plusieurs documents. Enregistrez le contenu des lignes JSON précédentes dans un fichier nommé bulk et utilisez l'appel suivant pour indexer ces 3 utilisateurs :

$ curl --oauth2-bearer `<iam-token-value>` -XPUT -H 'Content-Type: application/x-ndjson' 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_bulk' --data-binary "@bulk"

Cet appel prendra le contenu du fichier bulk et exécutera chaque opération d'indexation. Notez que vous devez utiliser l'option --data-binary et non -d afin de préserver le saut de ligne après chaque JSON. Vous pouvez vérifier que vos données sont correctement indexées avec l'appel suivant :

$ curl --oauth2-bearer `<iam-token-value>` -XGET 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_search?pretty=true'

Cela vous renverra les documents de votre index :

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "hits" : {
    "total" : 3,
    "max_score" : 1.0,
    "hits" : [ {
      "_index" : "`<service_name>-i-<suffix>`",
      "_type" : "_doc",
      "_id" : "AV3HvbQAz85mIBfrJjkV",
      "_score" : 1.0,
      "_source" : {
        "userId" : "1",
        "firstName" : "Jon",
        "lastName" : "Snow",
        "age" : 22,
        "address" : {
          "streetAddress" : "21 2nd Street",
          "city" : "Winterfell",
          "state" : "North",
          "postalCode" : "14578",
          "geolocation" : {
            "lat" : 54.369488,
            "long" : -5.574768
          }
        },
        "phoneNumber" : [ {
          "type" : "home",
          "number" : "212 555-1234"
        }, {
          "type" : "mobile",
          "number" : "102 555-4567"
        } ]
      }
    }, {
      "_index" : "`<service_name>-i-<suffix>`",
      "_type" : "_doc",
      "_id" : "AV3HvbQAz85mIBfrJjkW",
      "_score" : 1.0,
      "_source" : {
        "userId" : "2",
        "firstName" : "Cersei",
        "lastName" : "Lannister",
        "age" : 43,
        "address" : {
          "streetAddress" : "1 Palace Street",
          "city" : "King's Landing",
          "state" : "The Crownlands",
          "postalCode" : "26863",
          "geolocation" : {
            "lat" : 42.639758,
            "long" : 18.1094725
          }
        },
        "phoneNumber" : [ {
          "type" : "home",
          "number" : "212 555-6789"
        }, {
          "type" : "mobile",
          "number" : "102 555-8901"
        } ]
      }
    }, {
      "_index" : "`<service_name>-i-<suffix>`",
      "_type" : "_doc",
      "_id" : "AV3HvbQAz85mIBfrJjkX",
      "_score" : 1.0,
      "_source" : {
        "userId" : "3",
        "firstName" : "Daenerys",
        "lastName" : "Targaryen",
        "age" : 22,
        "address" : {
          "streetAddress" : "3 Blackwater Bay Ave",
          "city" : "Dragonstone",
          "state" : "Dragonstone",
          "postalCode" : "75197",
          "geolocation" : {
            "lat" : 43.300097,
            "long" : -2.26158
          }
        },
        "phoneNumber" : [ {
          "type" : "home",
          "number" : "212 555-1234"
        }, {
          "type" : "mobile",
          "number" : "102 555-2345"
        } ]
      }
    } ]
  }
}

Maintenant que vous disposez de données, vous pouvez enrichir vos logs avec celles-ci. Pour cela, nous allons utiliser un collecteur Logstash et un plugin elasticsearch (certains outils elasticsearch sont compatibles avec OpenSearch).

Configurer un collecteur Logstash

Si vous ne savez pas comment créer un collecteur Logstash, reportez-vous au guide Logstash. Modifiez la configuration de Logstash. Pour cet exemple, nous utiliserons un input SSL TCP avec le codec GELF. Voici la configuration de l'input.

tcp {
    port => 12202
    type => gelf
    ssl_enable => true
    ssl_verify => false
    ssl_cert => "/etc/ssl/private/server.crt"
    ssl_key => "/etc/ssl/private/server.key"
    ssl_extra_chain_certs => ["/etc/ssl/private/ca.crt"]
    codec => gelf { delimiter => "\x00" }
}

La partie la plus importante de cette configuration est la partie filtre :

opensearch {
    hosts => ["https://gra2.logs.ovh.com:9200"]
    index => "`<service_name>-i-<suffix>`"
    user => "pat_jwt_logstash"
    password => "`<iam-token-value>`"
    enable_sort => false
    query => "userId:%{[userId]}"
    fields  => {
       "firstName" => "firstName"
       "lastName" => "lastName"
       "address" => "address"
    }
}

if "_elasticsearch_lookup_failure" not in [tags] {
     mutate {
        add_field => {
            "address_geolocation" => "%{[address][geolocation][lat]},%{[address][geolocation][long]}"
        }
        remove_field => [ "address" ]
     }
}

La partie filtre est composée de deux plugins, le plugin elasticsearch et le plugin mutate. Le plugin elasticsearch dispose de la configuration suivante :

• hosts : il s'agit de l'adresse de l'API OpenSearch de votre cluster LDP. Notez que nous utilisons ici https.
• index : il s'agit du nom de l'index contenant vos données statiques.
• username : il s'agit du nom d'utilisateur permettant de vous authentifier auprès de l'API. Là encore, nous vous recommandons d'utiliser des jetons à cet effet.
• password : le mot de passe de l'utilisateur.
• enable_sort : ce paramètre indique qu'il n'est pas nécessaire de trier les données pour la requête.
• query : il s'agit de la requête émise. Ici, la requête est une simple recherche par chaîne de caractères recherchant le document dont le champ userId est défini avec la valeur userId trouvée dans l'événement de log. %{[userID]} sera remplacé par la valeur contenue dans le champ userId de l'événement de log.
• fields : c'est ici que s'effectue l'enrichissement. Le champ du document trouvé sera ajouté à l'événement. Le champ du document figure à gauche et le nouveau champ (ou le champ mis à jour) de l'événement figure à droite. Veillez à respecter les conventions de nommage des champs.

Le plugin mutate est là pour vous montrer comment combiner différentes informations de sous-champs en un seul champ de premier niveau. Ici, nous combinons un champ de latitude et un champ de longitude pour créer un champ de géolocalisation, puis nous supprimons le champ address d'origine.

Envoyer et récupérer vos logs

Un moyen simple de tester votre nouvelle configuration Logstash est d'envoyer un log en utilisant echo et openssl. Consultez les exemples ci-dessous :

$ echo -e '{"version":"1.1", "host": "little bird", "short_message": "Warrior from the North", "level":1, "_userId": "2", "_unitType": "Westerosis", "_power_num": 200 }'\0 | openssl s_client -quiet -no_ign_eof -connect `<input-hostname>`:`<port>`
$ echo -e '{"version":"1.1", "host": "little bird", "short_message": "A legendary dragon", "level":1, "_userId": "3", "_unitType": "Dragon", "_power_num": 200000 }'\0 | openssl s_client -quiet -no_ign_eof -connect `<input-hostname>`:`<port>`

Comme vous pouvez le voir, nous indiquons simplement l'userId auquel appartient cette commande. Envoyer ce log à votre input Logstash vous donnera le log final suivant :

Le log a été automatiquement enrichi avec les champs que nous avons déclarés dans notre filtre. Relier les informations d'un index et des logs vous permet de créer des tableaux de bord plus pertinents à partir de ces informations :

Dans ce tableau de bord, vous pouvez voir que le premier widget est un widget « quick values » basé sur les champs firstName des logs que nous avons récupérés.

Superviser la taille de l'index

La taille maximale de votre index est fixe et dépend du nombre de shards. Les shards constituent l'unité de parallélisme dans OpenSearch ; si la performance de recherche est critique, vous devez donc choisir un index avec le plus grand nombre de shards que vous pouvez vous permettre. Grâce aux nœuds haute performance que nous utilisons, nous avons réussi à envoyer des milliers de logs vers Logstash et à tous les enrichir en quelques secondes en utilisant un seul shard.

Notez que vous pouvez surveiller la taille de l'index à l'aide de la requête curl suivante :

$ curl --oauth2-bearer `<iam-token-value>` -XGET -H 'Content-Type: application/json' 'https://<ldp-cluster>.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_stats/store?pretty'

Cette commande vous renverra un document au format suivant :

{
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "failed" : 0
  },
  "_all" : {
    "primaries" : {
      "store" : {
        "size_in_bytes" : 876787361
      }
    },
    "total" : {
      "store" : {
        "size_in_bytes" : 1746852820
      }
    }
  },
  "indices" : {
    "`<service_name>-i-<suffix>`" : {
      "uuid" : "JC0IWkd3QYSBNd4B2bBZGg",
      "primaries" : {
        "store" : {
          "size_in_bytes" : 876787361
        }
      },
      "total" : {
        "store" : {
          "size_in_bytes" : 1746852820
        }
      }
    }
  }
}

La taille en octets utilisée pour calculer votre facturation est celle indiquée sous le chemin suivant : "indices" -> "<service_name>-i-<suffix>" -> "primaries" -> "store" -> "size_in_bytes".

Gestion via l'API OpenSearch

Sur Logs Data Platform, nous permettons aux utilisateurs d'utiliser l'API OpenSearch pour gérer le cycle de vie de leurs index. Vous pouvez créer et supprimer des index directement avec l'API OpenSearch. Vous pouvez aussi créer des alias et les supprimer. Nous prenons même en charge les templates, qui permettent aux utilisateurs de créer automatiquement leur mapping à la création de l'index !

Création et suppression d'index

Pour créer un index sur Logs Data Platform, utilisez l'appel suivant :

$ curl --oauth2-bearer `<iam-token-value>` -XPUT -H 'Content-Type: application/json' 'https://gra2.logs.ovh.com:9200/`<service_name>-i-<suffix>`' -d '{ "settings" : {"number_of_shards" : 1}}'

• L'option -u est suivie de votre nom d'utilisateur LDP, que vous trouverez sur la page Home. Le mot de passe 'mypassword' la suit après le séparateur ':'
• La commande HTTP PUT permet de créer ou de modifier un document.
• L'option -H 'Content-Type: application/json' est l'en-tête obligatoire pour indiquer que les données seront au format json.
• L'adresse contient l'endpoint du cluster suivi du nom de votre index
• Le corps de la requête est un simple document JSON contenant les paramètres de votre index : le nombre de shards (le nombre de réplicas sera automatiquement défini à 1).

Vous devez respecter la convention de nommage de Logs Data Platform <service_name>-i-<suffix> pour créer votre index. Votre service name se trouve sur la page d'accueil du Control Panel Logs Data Platform. Le suffixe peut contenir n'importe quel caractère alphanumérique.

Pour supprimer un index, utilisez l'appel suivant :

$ curl --oauth2-bearer <iam-token-value> -XDELETE -H 'Content-Type: application/json' 'https://gra2.logs.ovh.com:9200/`<service_name>`-i-`<suffix>`'

Ici, nous utilisons la commande HTTP DELETE pour supprimer l'index.

Création et suppression d'alias

Comme pour les index, vous pouvez utiliser les appels API pour supprimer et créer des alias sur vos index. La seule différence concerne la convention de nom de votre alias. Votre alias doit être formaté comme suit : <service_name>-a-<suffix> (ou <username>-a-<suffix> pour les utilisateurs legacy). Voici un exemple d'appel :

$ curl --oauth2-bearer `<iam-token-value>` -XPUT -H 'Content-Type: application/json' 'https://gra2.logs.ovh.com:9200/`<service_name>-i-<suffix>`/_alias/<service_name>-a-`<alias_suffix>`'

Cet appel crée un alias individuel sur un index que vous avez préalablement créé.

Si vous avez besoin de plus d'informations sur les alias, vous pouvez consulter la documentation OpenSearch.

Nous prenons également en charge l'API aliases pour créer des alias :

$ curl --oauth2-bearer `<iam-token-value>` -XPOST "https://gra2.logs.ovh.com:9200/_aliases?pretty" -H 'Content-Type: application/json' -d'
{
    "actions" : [
        { "remove" : { "index" : "`<service_name>`-i-<one-suffix>", "alias" : "`<service_name>-a-<suffix>`" } },
        { "add" : { "index" : "`<service_name>`-i-<other-suffix>", "alias" : "`<service_name>-a-<suffix>`" } },
        { "remove_index": { "index": "`<service_name>`-i-`<one-suffix>`" } }
    ]
}'

Toutes les actions (changement d'alias, création d'alias et suppression d'index) seront effectuées en un seul appel. Tous les index et alias concernés doivent respecter la convention, sinon une erreur sera renvoyée.

Templates

Logs Data Platform prend en charge vos templates personnalisés. Comme pour les index et les alias, le template doit respecter certaines règles pour fonctionner :

• le nom du template doit contenir votre <service_name>. Il peut se trouver n'importe où dans la chaîne du nom.
• Le préfixe des index concernés par le template DOIT commencer par l'un de vos services autorisés, soit <service_name>-i-, le caractère « * » devant se trouver après ce préfixe
• L'alias attaché à votre template doit respecter la convention habituelle : <service_name>-a-<suffix>

Voici un exemple de template pour un service ldp-ab-12345 :

$ curl --oauth2-bearer <iam-token-value> -XPUT -H 'Content-Type: application/json' 'https://gra2.logs.ovh.com:9200/_template/template_for_ldp-ab-12345_indices' -d '
{
	"index_patterns" : [ "ldp-ab-12345-i-debug*","ldp-ab-12345-i-test*"  ],
	"settings": {
		"number_of_shards" : 1
	},
	"aliases" : {
		"ldp-ab-12345-a-all" : {},
		"ldp-ab-12345-a-debug" : { "filter" : { "term" : { "type" : "debug" } } }
	}
}'

Ce template sera appliqué à chaque nouvel index correspondant au pattern d'index.

Manager

Tous les éléments que vous créez via l'API OpenSearch s'afficheront dans votre manager et pourront y être supprimés ou supervisés.

Ici, le premier index a été créé via l'API, sa description a été remplie automatiquement.

Informations complémentaires

Index as a service comporte certaines spécificités sur nos plateformes. Ces informations complémentaires et techniques peuvent vous aider à l'utiliser correctement :

• La réplication est fixée à 1 et ne peut pas être modifiée. Nous garantissons ainsi la haute disponibilité de votre index en cas de panne matérielle.
• La taille maximale de votre index est fixe et dépend du nombre de shards. Si la performance de recherche est critique, vous devez choisir le plus grand nombre de shards que vous pouvez vous permettre.
• L'index_refresh_interval de l'index est fixé à 1 seconde, garantissant des résultats de recherche quasiment en temps réel.
• Vous n'êtes pas autorisé à modifier les paramètres de votre index.
• Vous pouvez créer un alias sur Logs Data Platform et l'attacher à un ou plusieurs index.
• Contrairement aux index, les alias sont en lecture seule : vous ne pouvez pas encore écrire via un alias.
• Si une fonctionnalité vous manque, n'hésitez pas à nous contacter sur le hub communautaire.

Aller plus loin

• Pour bien démarrer : Démarrage rapide
• Documentation : Guides
• Créer un compte : Essayez !
• Hub communautaire : communauté d'utilisateurs