Using OpenSearch API to send your logs

Send your logs to the platform with the OpenSearch API.

Last updated 13th June, 2022


OpenSearch is the star component of our platform, making it possible to use OpenSearch indexes to store your documents. The OpenSearch indexes are quite flexible, but they are not part of the log pipeline. If you want to also use the Websocket live-tail, or the Alerting system or the Cold Storage feature, and have automatic retention management, then you will need to use the log pipeline. Thanks to our OpenSearch log endpoint, it shall enable you to send logs using the HTTP OpenSearch API. Moreover, the endpoint supports also OpenSearch Ingest, meaning you can use advanced processing on your logs before they are sent in the pipeline. There is no additional cost for this feature, all you need is a stream.

OpenSearch endpoint

The OpenSearch endpoint is a dedicated index where you can send a JSON document. The port used is the 9200, the same HTTP port used for all other OpenSearch API of Logs Data Platform. The only field needed are the X-OVH-TOKEN and an extra field (any custom field). Don't hesitate to go to the Quick Start documentation if you are not familiar with this notion. This document will be transformed into a valid GELF log and any missing field will be filled automatically. In order to respect the GELF convention, you can also use all the GELF format reserved fields. Here is one example of the minimal message you can send:

$ curl -H 'Content-Type: application/json' -u '<user>:<password>' -XPOST https://<ldp-cluster> -d '{ "X-OVH-TOKEN" : "7f00cc33-1a7a-4464-830f-91be90dcc880" , "test_field" : "OVHcloud"}'

Replace the <user>, <password> and <ldp-cluster> with your Logs Data Platform username, password and cluster. You can also use tokens in place of your credentials. Sending this payload will result in this log:


The system automatically put the timestamp at the date when the log was received and add the field test_field to the log message. Source was set to unknown and the message to -. Note that the payload follow the JSON specification (and not the GELF one). The system will still recognize any reserved field used by the GELF specification. Here is another example:

$ curl -H 'Content-Type: application/json' -u '<user>:<password>' -XPOST https://<ldp-cluster> -d '{ "X-OVH-TOKEN" : "7f00cc33-1a7a-4464-830f-91be90dcc880" , "test_field" : "OVHcloud" , "short_message" : "Hello OS input", "host" : "OVHcloud_doc" }'

This will create the following log:


The system used the reserved fields associated with GELF to create the message and the source fields.

Logs Data Platform will also detect any typed field in the original data and convert them accordingly to our field naming convention. This last example illustrates it:

$ curl -H 'Content-Type: application/json' -u '<user>:<password>' -XPOST https://<ldp-cluster> -d '{ "X-OVH-TOKEN" : "7f00cc33-1a7a-4464-830f-91be90dcc880" , "test_field" : "OVHcloud" , "short_message" : "Hello OS input", "host" : "OVHcloud_doc", "numeric_field" : 43.5  }'

The numeric field numeric_field will be detected as a number and will be suffixed to follow our naming conventions.


The OpenSearch input will also flatten any sub-object or array sent through it and supports also ingest pipelines, they are used for example with Filebeat integrations

Use case: Vector

Vector is a fast and lightweigth log forwarder written in Rust. This software is quite similar to Logstash or Fluent Bit. It takes logs from a source, apply a transformation on them and send them in a format compatible with the configured output module.

The vector integrations are numerous with more than 20 sources supported, more than 25 transforms and 30 sinks supported. It supports OpenSearch as a sink thanks to its Elasticsearch compability. We will use the simplest configuration to make it work from a journald source to our OpenSearch endpoint. Don't hesitate to check the documentation to explore all the possibilities.

data_dir = "/var/lib/vector" # optional, must be allowed in read-write

type = "journald" # required

#This VRL transorm add the token
type = "remap"
inputs = ["journald"]
source = '''
."X-OVH-TOKEN" = "<stream-token>"

type = "elasticsearch" # required
inputs = ["token"] # required
mode = "bulk"
compression = "gzip" # optional, default is none
healthcheck = true # required
endpoint = "https://<<ldp-cluster>>" # required
bulk.index = "ldp-logs" # required
auth.strategy = "basic"
auth.user = "<username>"
auth.password = "<password>"

Here is the explanation of this configuration.

The source part of the TOML configuration file configure the journald source. By default this source will use the /var/lib/vector directory to store its data. You can configure this directory with the global option data_dir.

The transform configuration part relates to the remap transform. This transform named here token has for unique goal to add the token stream value. It takes logs from the inputs named journald and add a X-OVH-TOKEN value. This token value can be found on the ... stream menu on the stream page in the Logs Data Platform manager. Replace with the token value of your stream.

The final part is the Elasticsearch sink. It takes data from the previous inputs token and setup several config points:

  • gzip is supported on our endpoint, so it's activated with the compression configuration.
  • healthcheck are also supported and allow you to be sure that the platform is alive and well
  • the endpoint configuration must be replaced with your assigned cluster
  • the bulk.index must be set to "ldp-logs", our special OpenSearch logs index
  • the auth.strategy must be set to "basic".
  • auth.user and auth.password must be set to the username of the Logs Data Platform account and its associated password. Note that you can use tokens in place of your credentials.

Once configured and launched you will immediately see this type of logs in Graylog:


The logs from journald arrived fully parsed and ready to be explored. Use differents sources and transforms to send your application logs to Logs Data Platform.

Go further

Cette documentation vous a-t-elle été utile ?

N’hésitez pas à nous proposer des suggestions d’amélioration afin de faire évoluer cette documentation.

Images, contenu, structure… N’hésitez pas à nous dire pourquoi afin de la faire évoluer ensemble !

Vos demandes d’assistance ne seront pas traitées par ce formulaire. Pour cela, utilisez le formulaire "Créer un ticket" .

Merci beaucoup pour votre aide ! Vos retours seront étudiés au plus vite par nos équipes..

Ces guides pourraient également vous intéresser...

OVHcloud Community

Accedez à votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres d'OVHcloud Community.

Echanger sur OVHcloud Community

Conformément à la Directive 2006/112/CE modifiée, à partir du 01/01/2015, les prix TTC sont susceptibles de varier selon le pays de résidence du client
(par défaut les prix TTC affichés incluent la TVA française en vigueur).