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 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>
    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
portN12202GELF+TLS input port
protocolNtlsTransport: tls (recommended, required by OVHcloud LDP) | 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, since the payload already arrives as GELF from upstream processing. 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.

OVHcloud Requires TLS​

Unlike the generic GELF target, this target defaults protocol to tls and port to 12202, and tls.verify defaults to true. The OVHcloud Logs Data Platform GELF input requires an encrypted connection; the tcp and udp transports remain available for non-default configurations, but tls (or https) is the expected transport.

Authentication​

OVHcloud LDP authenticates ingestion per log stream using an X-OVH-TOKEN value. This target has no token property, does not set the field, and does not check for it. It delivers each document as it receives it, so the token has to be on the event as a GELF field before the event reaches this target. Set it in a pipeline upstream, and confirm that it is still there after GELF normalization.

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 only frames and delivers the payload it receives. Format the event as GELF, with the X-OVH-TOKEN field set, 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"
      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"
      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 page documents protocol: tls with port: 12202, which is the encrypted GELF input. The Graylog target starts from protocol: tcp on port 12201, and the examples in its troubleshooting section use those values.

[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 left at, or copied from, a plain-stream value while the platform expects the encrypted input on 12202. 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 stay configurable, and nothing in the target prevents you from selecting them. The platform expects an encrypted connection, so keep protocol: tls, or https, unless you have a specific reason not to.

Repeated resets on a plain stream transport point at the transport. With protocol: tcp, writes that keep failing like the one below typically mean the platform endpoint accepts encrypted connections only.

[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 transport. 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.

The stream token is not set by this target. The platform authenticates each log stream with a token carried as a GELF field on the event itself, and this target neither adds that field nor checks for it. An event that the platform expects to carry a token therefore arrives without one, unless the field was already set further upstream. Such an event is typically accepted on the connection and then discarded 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 confirm that the field is set by a pipeline that runs before this target, and that it is still on the event after GELF normalization. There is no token property on this target to set instead.