Skip to main content

Sumo Logic

SIEM Platform

Synopsis​

The Sumo Logic target forwards events to a Sumo Logic Cloud SIEM HTTP Source collector over HTTPS. It handles batching and delivery — the event payload is expected to already be a complete JSON document in Sumo Logic's schema when it reaches the target.

Schema​

- name: <string>
  description: <string>
  type: sumologic
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    url: <string>
    batch_size: <integer>
    timeout: <integer>
    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 sumologic
pipelinesN-Optional post-processor pipelines
statusNtrueEnable/disable the target

Connection​

FieldRequiredDefaultDescription
urlY-Sumo Logic HTTP Source collector URL. The collector token is embedded in the URL, e.g. `https://<endpoint>.collection.sumologic.com/receiver/v1/http/<UNIQUE_CODE>`. There is no separate auth header
max_bytesN1048576 (1 MB)Maximum size of a single request body or batch, in bytes
note

max_bytes caps the size of a single request body or batch. It behaves differently from max_size on the file-writing targets, and the difference is easy to get wrong:

  • An explicit max_bytes: 0 IS honoured and removes the ceiling on targets that have no ceiling of their own. The value is read with Int64, which returns what you wrote — unlike max_size, which is read with MustInt64 and silently substitutes its default for a zero. Where a target has a fixed ceiling of its own, its page says so and a zero is clamped to that ceiling instead.
  • A negative value is rejected at configuration time with max_bytes must not be negative.

The ceiling is validated when the target is built and enforced again on every batch, so a value the receiving service will refuse fails early rather than per request.

Batch Configuration​

FieldRequiredDefaultDescription
batch_sizeN1000Maximum events per POST, serialized as newline-delimited JSON
timeoutN30HTTP client timeout, in seconds

Processing​

FieldRequiredDefaultDescription
field_formatN-Optional target-side normalization format applied before delivery. Typically left empty, since the payload already arrives in Sumo Logic's JSON schema 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 Sumo Logic's log schema itself. It expects each event to already be a complete JSON document when it reaches the target, buffers events in memory, and delivers them as one HTTP POST — newline-delimited JSON, one document per line — once batch_size is reached or during finalization.

Endpoint and Authentication​

The url is the Sumo Logic HTTP Source collector URL; the collector access token is embedded directly in the URL path, so no separate authentication header is sent. Configuration validation rejects a target with no url.

Batching and Retry​

Events buffer until batch_size is reached, then POST as a single request. A failed POST does not retry the batch internally: the buffer is cleared unconditionally after Finalize, and delivery failure is surfaced to the sender pool, which handles redelivery through the JetStream layer. Retaining the batch locally in addition to that redelivery would duplicate events at the destination. Error responses include up to the first 1 MB of the response body for troubleshooting.

note

The target does not render Sumo Logic's JSON schema — it only batches and delivers the payload it receives. Format the event as Sumo Logic-compatible JSON before it reaches this target.

Examples​

Basic Configuration​

Sending JSON events to a Sumo Logic HTTP Source collector...

targets:
  - name: sumologic
    type: sumologic
    properties:
      url: "https://endpoint1.collection.sumologic.com/receiver/v1/http/UNIQUE_CODE"

Secret-Based URL​

Keeping the collector URL, which embeds the access token, out of the config file...

targets:
  - name: sumologic-secure
    type: sumologic
    properties:
      url: "${SUMOLOGIC_HTTP_SOURCE_URL}"
      batch_size: 500
      timeout: 45

High-Volume Configuration​

Increasing the batch size for high-volume ingestion...

targets:
  - name: sumologic-high-volume
    type: sumologic
    properties:
      url: "${SUMOLOGIC_HTTP_SOURCE_URL}"
      batch_size: 5000
      timeout: 30

Troubleshooting​

The sumologic target behaves the same way as the datadog target and reports the same errors for the same causes: a refused credential, a wrong or unreachable endpoint, certificate failures, rejected bodies, oversized records, throttling, and the silent failures that leave the target looking healthy. Use the Troubleshooting section of the Datadog target for the full list of errors, causes and fixes, and Target Delivery Errors for how Director logs and retries target failures.

Read those entries with this target's type in place of datadog. A refusal from the collector is logged as sumologic api returned status <code>: followed by the response body, up to its first 1 MB.

What differs​

  • The credential lives in url. The collector's unique code is part of the path and no authentication header is sent, so there is no api_key setting. A value left over from another target type is accepted by the configuration and then ignored, with nothing logged. A refused request is therefore always a problem with the URL itself, most often a collector URL that lost characters when it was pasted.

  • A failed request exposes that credential. A DNS, connection, proxy, TLS or timeout error puts the whole collector URL, unique code included, into the log line and into the target's connection status. See Log lines and connection status can contain the full endpoint URL on the Datadog page for how to treat those logs, and when to rotate the collector.

  • max_bytes defaults to 1048576 (1 MB), a fifth of the Datadog default, because the collector typically accepts 1 MB per request. A single event that passes on the other two targets can be refused here as oversized, and an oversized record is one of the two errors that lose data.

  • The body is newline-delimited JSON, one document per line. An event whose own text contains a raw newline is split into two documents at the receiver, so make sure the pipeline emits single-line JSON.

  • A missing url is reported as sumologic target requires url (the HTTP Source collector URL), not as a missing key.

warning

A log line or connection status that shows this target's url carries a working ingestion credential. Remove it before sharing the line, and if it has already been shared, create a new HTTP Source, point url at it, and delete the old one.