Skip to main content
Forge exports newline-delimited JSON to a Sumo Logic HTTP Logs and Metrics Source. It uses the same versioned security_event.v1 records, event scope, content controls, delivery ledger, and replay as Security Exports. Every category in the current export schema is supported, including optional identity activity.

​
Connect Sumo Logic

  1. In Sumo Logic, open Data Management → Data Collection → Collection. Create or select a Hosted Collector and add an HTTP Logs & Metrics source.
  2. Name the source Forge security events and choose a source category such as forge/security. Forge preserves the source’s name, category, host, and fields; it does not override them with HTTP metadata headers.
  3. Under Advanced Options for Logs, disable Multiline Processing and One Message Per Request. Each physical line is one JSON event; embedded newlines in prompt or tool content are JSON-escaped.
  4. Configure timestamp extraction from occurred_at (UTC ISO 8601). This avoids selecting another nested timestamp. Check the detected timestamp using the test event before enabling continuous delivery.
  5. Save the source and copy its Presigned URL. Select this option rather than Auth Header. The URL includes its ingest credential.
  6. In Forge, open Integrations → SIEM and exports → Sumo Logic. Paste the full presigned URL into HTTP Source URL, choose scope and content detail, and save.
  7. Use Test, find the event in Sumo Logic Live Tail or Log Search, then activate the destination.
Forge encrypts the complete URL as an organization-scoped managed secret. The URL is masked in the form and is not returned by the API or included in delivery attempts or audit configuration. Leave the URL blank when editing to keep the current credential; paste a newly generated URL to rotate it. After saving a changed destination, test it again before resuming delivery. TLS certificate validation is required. Production deployments also reject private-network destinations. Requests do not follow redirects. Use a dedicated source for Forge and regenerate its presigned URL if it is exposed. See Sumo Logic’s HTTP source setup and log upload contract.

​
Find the test event

Replace the source category if you chose a different one:
Check that one exported JSON object appears as one message, forge_schema is security_event.v1, the occurrence time is correct, and the selected fields are present. A successful HTTP response proves request acceptance; Live Tail and Log Search establish what Sumo Logic actually received and indexed. Processing rules can filter accepted messages, and search visibility may be delayed.

​
Cloud SIEM

Log Search ingestion and Cloud SIEM normalization are separate steps. This integration does not install a Sumo Logic parser, log mapper, or detection rules. Do not assume that forwarding JSON alone produces normalized SIEM records. For a Cloud SIEM-enabled organization:
  1. Create a custom JSON parser for the Forge v1 envelope and the log mappings appropriate to the event categories you export. Use representative test messages in Sumo Logic’s Parser Editor and verify the mapped record type.
  2. Configure the HTTP source’s Forward to SIEM option and its _parser field with the path copied from that parser. Attach this configuration to the dedicated source so it applies to test, live, and replay events alike.
  3. Preserve event_id, source_event_id, organization_id, category, action, outcome, and occurred_at in your parser/mapping. Map actor, device, and target fields according to the applicable record type; optional fields vary by category and detail policy.
  4. Confirm that test events appear as normalized Cloud SIEM records. Inspect parser/mapping failures before enabling rules or relying on the stream.
Follow Sumo Logic’s ingestion best practices and schema and log mapping guides.

​
Delivery and replay

The versioned envelope schema applies to every line. Forge batches retained source records and sends requests no larger than 1,000,000 uncompressed bytes. An event larger than the receiver limit cannot be sent; inspect failed attempts and dead letters and deliberately review content detail before retrying. Forge does not silently truncate it to meet the receiver limit. HTTP 408, 429, 5xx, and network failures are retryable. Other non-success HTTP responses require remediation. Failed delivery does not advance the category’s live cursor. Retry exhaustion or a permanent rejection produces an unhealthy destination and a dead letter. Correct the source or credential, test, and resume it; the shared worker recovers the failed batch and resolves its dead letter. Delivery is at least once. A lost response, worker crash, or partially accepted multi-request batch can cause accepted events to be sent again. Successful ledger batches are suppressed during normal delivery. Replay intentionally sends the same destination-scoped event_id again without rewinding the live cursor. Deduplicate consumers and searches by event_id, for example:
Retained source data and durable cursors provide buffering; outbound payloads are not retained indefinitely. The default replay lookback is 90 days, but actual source retention can be shorter. Replay cannot recreate expired event bodies. The destination page shows recent attempts, delivered/skipped counts, cursors, unresolved failures, and replay results. The shared security-export alert rules cover Sumo Logic too. Operators must enable the authenticated telemetry-worker metrics listener, load the rules, and route alerts independently of the failing SIEM destination; see Security Exports.

​
Verification without a Sumo Logic account

Sumo Logic publishes a receiver mock for local collection tests. The Kubernetes collection uses this mock, and the Logstash plugin has its own HTTP receiver tests; the Fluentd plugin and OpenTelemetry exporter provide additional wire-format references. The OpenTelemetry exporter uses newline-separated JSON log records and the HTTP Source’s legacy application/x-www-form-urlencoded content type, which Forge also uses. The body contains raw JSON lines, not URL-encoded form fields. For a repeatable local receiver, run the pinned vendor image:
Place a TLS reverse proxy in front of this loopback receiver and trust its test CA in the local Forge worker. Configure a task-local URL with the /receiver/v1/http/<test-code> path through Forge’s UI, then exercise Test, activation, and replay. Leave certificate verification enabled. Read http://127.0.0.1:19300/logs/count to confirm reception; the mock does not validate Sumo cloud credentials. Inject 429/401 responses at the proxy to verify cursor blocking and recovery without changing the vendor mock. The receiver mock checks the collection boundary. It is not the Sumo Logic cloud search or SIEM engine and cannot establish cloud indexing, timestamp extraction, parser normalization, or rule behavior. An installed Sumo collector also forwards data to the cloud; it does not provide a local Log Search or Cloud SIEM frontend. For a dedicated cloud source, supply SUMO_LOGIC_HTTP_SOURCE_URL through the secret environment and run the gated ingest check:
Then find the printed synthetic event_id in Log Search and verify its Cloud SIEM record separately. The check sends no production records. Do not put the presigned URL in shell history, issue comments, recordings, or screenshots.