Skip to main content

OVHcloud Logs Data Platform

SIEM Platform

Synopsis​

The OVHcloud target forwards events, formatted as GELF, to the OVHcloud Logs Data Platform GELF input over TLS, TCP, UDP, or HTTPS. It adds the stream's write token to each document and handles GELF wire framing for the chosen transport — the event payload is expected to already be a complete GELF JSON document when it reaches the target.

Schema​

- name: <string>
  description: <string>
  type: ovhcloud
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    address: <string>
    token: <string>
    port: <numeric>
    protocol: <string>
    max_message_size: <numeric>
    url: <string>
    timeout: <numeric>
    tls:
      verify: <boolean>
      server_name: <string>
      ca_name: <string>
      cert_name: <string>
      key_name: <string>
      passphrase: <string>
      min_tls_version: <string>
      max_tls_version: <string>
    field_format: <string>
    debug:
      status: <boolean>
      dont_send_logs: <boolean>

Configuration​

The following fields are used to define the target:

FieldRequiredDefaultDescription
nameYTarget name
descriptionN-Optional description
typeYMust be ovhcloud
pipelinesN-Optional post-processor pipelines
statusNtrueEnable/disable the target

Connection​

FieldRequiredDefaultDescription
addressY*-OVHcloud Logs Data Platform GELF endpoint, for example gra1.logs.ovh.com. Required for the tls, tcp, and udp transports
tokenY-Write token of the Logs Data Platform stream that receives the events. Added to each GELF document as the _X-OVH-TOKEN field. See Authentication
portN12202 / 2202OVHcloud Logs Data Platform GELF input port. Defaults to 12202, the GELF+TLS input, when protocol is tls, and to 2202, the plain GELF input, when it is tcp or udp. https keeps 12201
protocolNtlsTransport: tls (recommended) | tcp | udp (chunked) | https
max_message_sizeN8192UDP only: payload bytes per chunk before GELF chunking. 0 sends a single datagram. Ignored for tls/tcp/https
urlN*built as scheme://address:port/gelfhttps only: explicit endpoint override
timeoutN30Connection/write timeout in seconds. Bounds the stream dial and write deadline for tls/tcp/udp, and the HTTP client timeout for https

* = Conditionally required. address is required for tls, tcp, and udp; for https, either address (with port) or an explicit url must be supplied.

TLS​

FieldRequiredDefaultDescription
tls.verifyNtrueVerify the server certificate
tls.server_nameN-SNI / expected server hostname
tls.ca_nameN-Custom CA to trust. Empty uses the OS trust store
tls.cert_nameN*-Client certificate for mutual TLS
tls.key_nameN*-Client key for mutual TLS
tls.passphraseN-Passphrase for an encrypted client key
tls.min_tls_versionNtls1.2Minimum negotiated TLS version
tls.max_tls_versionNtls1.3Maximum negotiated TLS version

* = Conditionally optional. tls.cert_name and tls.key_name must be supplied together to enable mutual TLS; supplying only one fails configuration validation. There is no tls.status field — TLS is engaged by setting protocol: tls or protocol: https.

note

TLS material fields (cert_name, key_name, ca_name, client_ca_name) accept any of the following:

  • File name — resolved relative to the service root directory. Nested paths such as certs/prod/server.pem are supported.
  • Absolute path — honored only if it resolves inside the service root. Any path that escapes the root is refused.
  • Inline PEM content — used verbatim when the value contains -----BEGIN.
  • Environment variable — ${ENV_VAR}.
  • Vault reference — $secret{id=...} or $secret{store=...,ref=...}.

Processing​

FieldRequiredDefaultDescription
field_formatN-Optional target-side normalization format applied before delivery. Typically left empty when the paired content pack is in the route, since the payload then already arrives as GELF. Without the pack, this is the only normalization applied, and gelf produces a valid GELF document. See applicable Normalization section

Scheduling​

See Scheduling and Pool Behavior for interval and cron fields shared by all targets.

Debug Options​

FieldRequiredDefaultDescription
debug.statusNfalseEnable debug logging
debug.dont_send_logsNfalseProcess logs but don't send to target (testing)

Details​

This target is transport-only: it does not render GELF itself. It expects each event to already be a complete GELF JSON document when it reaches the target, and applies wire framing and delivery on top of that payload. There is no batching — each event is a single, complete delivery to the OVHcloud Logs Data Platform GELF input.

TLS by Default​

Unlike the generic GELF target, this target defaults protocol to tls and port to 12202, and tls.verify defaults to true. OVHcloud Logs Data Platform also accepts plain GELF on port 2202, over TCP and over UDP, and the target defaults to that port for tcp and udp. Those transports send the events and the stream token unencrypted, so keep tls unless you have a reason not to.

OVHcloud's other inputs listen on neighbouring ports, so a port copied from another product lands on the wrong one. In particular, OVHcloud's TCP/TLS input on 12201 is LTSV, not GELF. The 12201 that https falls back to is only the target's own default for building the URL, not an OVHcloud GELF input, so set url or port yourself when you use https.

Authentication​

OVHcloud LDP routes each message to a log stream by that stream's write token, and discards a message that carries none. Copy the token from the stream in the OVHcloud Control Panel and set it as token. Like any other target secret, it can be written as a plain value or as a secret reference.

The target adds the token to every document it sends as the _X-OVH-TOKEN GELF field, placed first in the document:

{"_X-OVH-TOKEN":"<token>","version":"1.1","host":"fw01","short_message":"..."}
  • Over tls, tcp, and udp, the field is the only place the token travels, which is what the GELF input reads.
  • Over https, the target also sends it as the X-OVH-TOKEN request header.
  • An event that already carries a _X-OVH-TOKEN field keeps its own value. A pipeline can therefore set the field per event to route events to different streams, and token then applies to the events it leaves without one.
  • An event that is not a JSON object is sent unchanged, without a token. This happens when neither the content pack nor field_format renders the event as GELF, and the platform rejects such an event anyway.

Transports​

  • GELF-TLS (default): the document is written null-delimited over a TLS-wrapped stream.
  • GELF-TCP: the same null-delimited framing, without TLS.
  • GELF-UDP: the document is sent as one datagram, or split into GELF-chunked datagrams (2-byte magic 0x1e 0x0f, 8-byte message ID, sequence number, sequence count) when it exceeds max_message_size. A document that would need more than 128 chunks fails — use tls or tcp for events that large.
  • GELF-HTTPS: the document is POSTed as the request body to the GELF HTTPS input.

Endpoint Resolution (HTTPS)​

An explicit url always wins. Otherwise the endpoint is built as https://address:port/gelf.

note

The target does not perform GELF rendering or field mapping — it adds the stream token, frames, and delivers the payload it receives. Format the event as GELF before it reaches this target.

Examples​

Secure TLS​

Sending GELF events to the OVHcloud Logs Data Platform over TLS...

targets:
  - name: ovhcloud
    type: ovhcloud
    properties:
      address: "gra1.logs.ovh.com"
      token: "<stream write token>"
      port: 12202
      tls:
        verify: true

Custom Timeout​

Widening the connection and write timeout for a slower network path...

targets:
  - name: ovhcloud-timeout
    type: ovhcloud
    properties:
      address: "gra1.logs.ovh.com"
      token: "<stream write token>"
      timeout: 60

Troubleshooting​

This target behaves the same way as the graylog target and reports the same errors for the same causes: connections that fail when the sender workers start, certificate and TLS problems, configuration reasons that repeat in the retry loop, size limits over UDP, and a target that stays healthy while nothing arrives. Use the Graylog troubleshooting section for the full list of errors, causes and fixes. See Target Delivery Errors for how Director logs and retries target failures.

Where to look:

  • Director logs. Target errors are tagged with the target name and carry "Section":"SenderPool". The part after Reason: or after the last colon is the actual cause.
  • The target's connection status in the web interface. It shows the same reason as the log line.

The examples on the Graylog page are written with that target's name, so match on the cause text rather than on the name.

What differs for OVHcloud​

The transport defaults are not the same. This target starts from protocol: tls on port 12202, and uses 2202 for tcp and udp. The Graylog target starts from protocol: tcp on port 12201, and the examples in its troubleshooting section use those values. On OVHcloud, 12201 is the LTSV input.

[Error] [director] [target-<target id>] [ovhcloud] Sender worker 0 ThreadSafeInit on reinit failed for "ovhcloud": failed to create per-worker gelf connection: dial tcp gra1.logs.ovh.com:12201: connect: connection refused

The port in that line is the one this target dialed, so read it against your own protocol before you look at the network. A 12201 here means port was copied from a Graylog configuration: on OVHcloud that is the LTSV input, and GELF is on 12202 with tls or 2202 with tcp and udp. Check the host in the same line as well. It has to be the endpoint of the data center your stream belongs to, and it has to resolve from the Director host.

note

The tcp and udp transports reach OVHcloud's plain GELF input on 2202. They carry the stream token in the clear, so keep protocol: tls unless you have a specific reason not to.

Repeated resets on a plain stream transport point at the port. With protocol: tcp, writes that keep failing like the one below typically mean the connection reached an input that is not plain GELF: the TLS input on 12202, or another format's input such as LTSV on 12201.

[Error] [director] [target-<target id>] [ovhcloud] Sender worker 2 execute() failed for natsobj:/vm-pipeline-payloads/sender.ovhcloud.<id>: target broken: write tcp ...->gra1.logs.ovh.com:12201: write: connection reset by peer

write: broken pipe carries the same meaning. A single line after a restart is expected, because the target reconnects once by itself and writes again. It is the repetition that points at the port. Use port: 2202 with tcp, or set protocol: tls and port: 12202.

warning

The same mismatch can also produce no error at all. The first write on each fresh connection is buffered before the endpoint closes it, the next write fails, the target reconnects, and the retry appears to succeed. Every event is counted as sent and none arrive.

A wrong or missing stream token loses events without an error. The platform reads the _X-OVH-TOKEN field to choose the stream. An event whose token belongs to no stream, or to a stream other than the one you are watching, is typically accepted on the connection and then discarded or routed elsewhere by the platform, so the target stays healthy, the events-out counter climbs, and the stream stays empty.

Check the platform side first. Open the stream's own statistics and confirm whether anything is arriving at all. Then check, in order:

  1. token is the write token of that stream, copied again from the OVHcloud Control Panel. A token copied with a leading or trailing space does not match.
  2. No pipeline before this target sets its own _X-OVH-TOKEN field. An event's own field wins over token.
  3. The event reaches the target as a GELF document. A plain syslog line, which is what arrives when neither the content pack nor field_format renders the event as GELF, is sent without a token.