Log Delivery and Storage

Upcoming release — Zylon 1.58These docs are published ahead of release so you can prepare your API integrations. The release image is not yet available. For installations running 1.57, use the 1.57 documentation.

Overview

Zylon supports internal log storage and external log delivery through syslog and HTTP.

Syslog delivery is intended for SIEM applications and log collectors that accept syslog or CEF events.
HTTP delivery is intended for structured ingestion endpoints, cloud log destinations, and customer-managed collection pipelines.
Delivery is asynchronous.
With failurePolicy: "drop", delivery is designed to stay off the critical request path when queues are full.
Delivered events can be filtered by action patterns and organization IDs.
Stored logs stay in the customer’s Zylon deployment unless external log delivery through syslog or HTTP is enabled.

For CLI-managed installations, edit /etc/zylon/zylon-conf.yaml and run sudo zylon-cli sync to apply changes. For installations managed directly with Helm, use the same keys in your Zylon Helm values YAML. The chart maps these values to backend runtime settings internally. For governance, auditability, EU AI Act traceability support, evidence preservation, and retention guidance, see Auditability & AI Governance: Logging, Evidence, and SIEM Delivery. For manual log retrieval, see Backoffice API: Logging.

Send logs to your SIEM

For a custom SIEM with an HTTPS JSON ingestion endpoint, start with HTTP delivery below. If your collector accepts syslog or CEF, use the syslog configuration instead. Internal storage (logging.storage.enabled) is enabled by default. External syslog and HTTP delivery are disabled by default. Enabling storage alone does not send events to your SIEM. Delivery forwards newly emitted events; it does not automatically replay stored history. Use the Backoffice Logging API to retrieve historical records.

1. Prepare your collector

Create an HTTPS endpoint reachable from the Zylon backend that accepts POST requests with JSON log records. Return an HTTP 2xx response after accepting a request. If your endpoint requires bearer authentication, prepare its ingestion token. The HTTP payload uses the schema marker zylon.canonical_json.v1. A single-event request contains a JSON object; multi-event batches contain a JSON array. The example below sets maxEvents: 1 so you can validate one record at a time. To use the default batch size of 25 later, make sure your collector also accepts arrays. The HTTP envelope contains schema, severity, outcome, actor, and log. Map log.event, log.action, log.id, and log.start_timestamp to your SIEM fields. These fields are nested under log, rather than at the top level. Deduplicate retries using log.id.

Delivery metadata and actor identifiers

Field	Values and meaning
`severity`	`low`, `medium`, `high`, `critical`. Assigned from the event action, family, and outcome. The current 1.58 mappings use `low`, `medium`, and `high`; `critical` is also a schema value.
`outcome`	`success` or `failure` for the original event, not the collector delivery. A non-null `log.error` or a security event status code of `400` or higher produces `failure`; otherwise it is `success`.
`actor`	Always contains `actor_type`, `actor_id`, and `actor_display`. An unidentified actor uses literal values rather than omitted fields.

Actor selection uses the first matching row:

`actor.actor_type`	Selected when	`actor.actor_id`
`api_token`	`log.token_id` is present.	The token ID.
`user`	No token ID; `log.account_id` is present.	`log.ws_member_id` when present, otherwise `log.account_id`.
`system`	No token or account ID; `log.system_event` is `true`.	Literal `system`.
`unknown`	None of the preceding conditions match.	Literal `unknown`.

For token/user actors, actor_display is the nonblank log.account_email, falling back to the selected actor ID. System/unknown actors use their literal value for display too. A workspace-member ID or email alone does not select user; token/account identity takes precedence over system_event.Use log.account_id for account correlation and log.ws_member_id for workspace-member correlation, when available. A user actor ID can identify either record type; do not treat it as an account ID in every event. actor_display is a display label, not a stable join key.If an action has no specific severity mapping, successful Backoffice events default to medium and other successful events to low; failed Backoffice events default to high and other failures to medium. An unknown actor does not imply an unknown outcome or change severity.

Example HTTP event (selected fields)

{
  "schema": "zylon.canonical_json.v1",
  "severity": "low",
  "outcome": "success",
  "actor": {
    "actor_type": "user",
    "actor_id": "01985a4d-3c21-7000-8003-0e10dd81d901",
    "actor_display": "operator@example.com"
  },
  "log": {
    "id": "01985a4d-3c21-7000-8003-0e10dd81d902",
    "event": "zylon.workspace",
    "action": "ws.project.create",
    "request_id": "example-request",
    "start_timestamp": "2026-10-14T10:00:00Z",
    "end_timestamp": "2026-10-14T10:00:00Z"
  }
}

Validate your parser with a received test event. Optional fields can be absent, and action is not present on every event. With batching enabled, accept both a single object and an array, depending on the number of events ready to send.

Gateway chat request-message and response capture (features.audit.enabled) is enabled by default. Forwarded records can contain that captured chat content. Review Audit Log configuration before enabling delivery. The API’s include parameter does not filter forwarded records.

2. Configure Zylon

Merge this example into /etc/zylon/zylon-conf.yaml, preserving your existing settings. Replace the URL and token with your collector’s values; the token belongs to your SIEM, not to the Zylon Backoffice API. If your collector does not require bearer authentication, omit the auth block.

logging:
  storage:
    enabled: true
  delivery:
    http:
      enabled: true
      format: "canonical_json"
      endpoint:
        url: "https://siem.example.com/ingest/zylon"
        method: "POST"
      auth:
        type: "bearer"
        token: "replace-with-siem-ingestion-token"
      delivery:
        batch:
          maxEvents: 1

Leave action and organization filters empty for the first test so they do not exclude the event you generate. Keep the queue, retry, and failure-policy defaults unless your collector needs different behavior. See HTTP delivery for the complete reference.

3. Apply the configuration

sudo zylon-cli sync

For deployments managed directly with Helm, apply the values through your normal Helm deployment process. See Configuration Overview for the CLI workflow.

4. Verify a new event

After applying the configuration, create a test project in the Workspace. Inspect the incoming request at your collector and confirm the schema marker zylon.canonical_json.v1 and log.action: "ws.project.create" are present. Then confirm the record appears in your SIEM’s search or event view. If the event does not arrive, check backend delivery warnings, endpoint reachability, collector responses, authentication, and filters. HTTP 4xx responses are not retried; fix the collector URL, authentication, headers, or parser before repeating the test. Use Troubleshooting below for other symptoms.

The default failurePolicy: "drop" can drop events when the delivery queue is full. External delivery has no disk-backed spool. Keep internal storage enabled for investigation and verify your collector’s retention separately.

5. Choose internal and SIEM retention

Stored-log cleanup is disabled by default: logs are not automatically deleted after 180 days. To enable scheduled deletion, use Log-only cleanup. Configure retention for copies in your SIEM separately.

At a glance

Channel	Enable with	Format options	Best for
Internal storage	`logging.storage.enabled: true`	Stored structured Zylon log records	Backoffice review and manual API retrieval
Syslog	`logging.delivery.syslog.enabled: true`	`rfc5424_json`, `cef`	SIEM applications, syslog collectors, and CEF collectors
HTTP	`logging.delivery.http.enabled: true`	`canonical_json`	HTTP collectors, ingestion gateways, and cloud log destinations

Syslog and HTTP delivery can be enabled at the same time. When both are enabled, Zylon dispatches matching logs to both destinations. Filters, failure policy, queue, and batch settings are configured separately for each delivery method but follow the same behavior.

Before you configure delivery

Confirm the collector endpoint is reachable from the Zylon backend.
Confirm host or URL and port.
Select transport and format.
Decide TLS certificate verification behavior.
Configure collector-side input, index, parser, or ingestion route.
Understand retention requirements in both Zylon and downstream systems.
Review filters so required audit events are not excluded.

Choose a delivery channel

Requirement	Recommended channel
Existing SIEM or syslog collector input	Syslog
Collector accepts RFC 5424 style syslog messages	Syslog with `rfc5424_json`
Collector accepts CEF events	Syslog with `cef`
Custom HTTP ingestion gateway	HTTP with `canonical_json`
Vendor-specific pipeline transformation	HTTP with downstream mapping

Storage and retention

Internal log storage is controlled under logging.storage.

Storage keys

Key	Default	Values	Description
`enabled`	`true`	`true`, `false`	Enables internal structured log persistence.

Retention keys

Internal log cleanup is controlled by the cleanup scheduler under zylonBackend.scheduler.cleanup. Scheduler settings:

Key	Default	Values	Description
`enabled`	`false`	`true`, `false`	Enables the cleanup scheduler.
`cron`	`0 3 * * *`	cron expression	Cleanup schedule. Shared with hard delete cleanup.
`minimumIntervalMinutes`	`1440`	integer minutes	Helm default minimum interval accepted for the cron schedule. A more frequent cron is rejected unless this setting is reduced.
`timezone`	`UTC`	time zone	Time zone used by the cleanup schedule. Shared with hard delete cleanup. If the runtime setting is omitted outside Helm, the backend uses the server JVM time zone.

Under logging:

Key	Default	Values	Description
`enabled`	`false`	`true`, `false`	Enables stored log cleanup.
`deleteAfterDays`	`180`	positive integer days	Permanently deletes stored logs persisted before the retention cutoff.

External collectors such as SIEM platforms, syslog receivers, HTTP collectors, and data lakes have independent retention settings.

Stored log cleanup is off by default. The 180 day value applies only after both the cleanup scheduler and stored log cleanup are enabled.

Log retention cleanup uses the same cleanup cron and timezone settings as hard delete cleanup. Review Hard delete cron configuration before changing the shared cleanup schedule.

Configure cleanup for stored logs only

Merge this example into your configuration only when you want to enable internal log deletion. It schedules daily checks at 03:00 UTC with a 180-day retention window:

zylonBackend:
  scheduler:
    cleanup:
      enabled: true
      cron: "0 3 * * *"
      timezone: "UTC"
      minimumIntervalMinutes: 1440
      workspace:
        enabled: false
      logging:
        enabled: true
        deleteAfterDays: 180

Both cleanup.enabled and cleanup.logging.enabled must be true. Setting workspace.enabled: false keeps Workspace hard deletion disabled in this example; the Helm default is true, so review this flag before enabling the shared scheduler. Preserve your existing Workspace cleanup policy if you already use it. After applying the configuration with sudo zylon-cli sync, each scheduled run permanently deletes records persisted more than 180 days earlier, including their related log details. Age uses the stored record’s created_at timestamp, assigned when new logs are persisted. Historical records migrated from older versions may use their event start time. Eligible records remain until a successful cleanup run. Cleanup applies across all organizations and log families; external delivery filters do not limit deletion. To stop log cleanup, set zylonBackend.scheduler.cleanup.logging.enabled: false. Disabling logging.storage.enabled stops new persistence; it does not erase existing records. Cleanup does not delete copies already sent to your SIEM or change its retention policy.

Use a positive whole number for cleanup.logging.deleteAfterDays. 0 does not mean unlimited retention: it makes existing logs eligible for deletion. Negative values can also delete recent records. Disable cleanup with its enabled flag instead.

Syslog delivery

Syslog delivery sends formatted log records to a socket collector over TCP, TLS, or UDP. Use rfc5424_json for structured syslog pipelines. Use cef when the collector has a native CEF input.

Format	Description	Use when
`rfc5424_json`	RFC 5424 syslog with a JSON envelope in the message body. The schema value is `zylon.rfc5424_json.v1`.	You want structured syslog events for SIEM/search pipelines.
`cef`	Raw CEF event format. The CEF extension includes a raw structured record under `cs1`.	Your collector has a native CEF input.

Transport	Behavior
`tls`	Persistent TLS socket. Supports certificate verification and custom CA file.
`tcp`	Persistent TCP socket without TLS.
`udp`	Datagram delivery. One event is sent per datagram; stream framing is ignored.

UDP is best-effort. It does not use stream framing and does not retry the current batch on write failure.

Supported syslog matrix

Backend tests confirm both syslog formats with tcp, tls, and udp.

Format	Transport	Framing	Notes
`rfc5424_json`	`tls`	`newline` or `octet_counting`	Recommended secure path for structured syslog collectors.
`rfc5424_json`	`tcp`	`newline` or `octet_counting`	Persistent socket path without TLS.
`rfc5424_json`	`udp`	Datagram	One datagram per event.
`cef`	`tcp`	`newline` or `octet_counting`	Raw CEF over TCP.
`cef`	`tls`	`newline` or `octet_counting`	Raw CEF over TLS.
`cef`	`udp`	Datagram	One datagram per event.

Syslog keys

Under logging.delivery.syslog:

Key	Default	Values	Description
`enabled`	`false`	`true`, `false`	Enables syslog delivery.
`format`	`rfc5424_json`	`rfc5424_json`, `cef`	Syslog payload format.
`endpoint.host`	empty	hostname or IP	Required collector host.
`endpoint.port`	`6514`	valid TCP/UDP port	Collector port.
`endpoint.transport`	`tls`	`tls`, `tcp`, `udp`	Socket transport.
`endpoint.framing`	`newline`	`newline`, `octet_counting`	Stream framing for TCP/TLS. Ignored for UDP.

Optional syslog keys

Optional filter, delivery, queue, batch, and TLS settings are configured under their matching nested blocks in logging.delivery.syslog.Under filters:

Key	Default	Values	Description
`includeActionPatterns`	`[]`	wildcard list	If non-empty, only matching action names are delivered.
`excludeActionPatterns`	`[]`	wildcard list	Matching action names are excluded before include filters are evaluated.
`includeOrgIds`	`[]`	organization UUID list	If non-empty, only logs for matching organization IDs are delivered.

Under delivery:

Key	Default	Values	Description
`timeoutSeconds`	`10`	positive integer	Socket connect/write timeout.
`failurePolicy`	`drop`	`drop`, `block`	Queue behavior when the async queue is full.

Under delivery.reconnect:

Key	Default	Values	Description
`enabled`	`true`	`true`, `false`	Enables reconnect after connect or write failure.
`backoffSeconds`	`5`	non-negative integer	Backoff before reconnect after failure.

Under delivery.queue:

Key	Default	Values	Description
`maxEvents`	`10000`	positive integer	Async delivery queue capacity.

Under delivery.batch:

Key	Default	Values	Description
`maxEvents`	`25`	positive integer	Maximum events per batch. Forced to `1` for UDP.
`maxDelayMillis`	`250`	positive integer	Maximum time to wait before flushing a partial batch.
`drainTimeoutMillis`	`1000`	positive integer	Shutdown drain timeout for queued batch entries.

Under tls:

Key	Default	Values	Description
`verifyCertificate`	`false`	`true`, `false`	Enables TLS certificate and hostname verification.
`caCrt`	empty	PEM certificate data	Inline CA certificate data. If set and `caFile` is empty, the chart mounts it for the backend.
`caFile`	empty	readable file path	Custom CA bundle used when certificate verification is enabled.

Syslog full example

logging:
  storage:
    enabled: true
  delivery:
    syslog:
      enabled: true
      format: "rfc5424_json"
      endpoint:
        host: "syslog.example.com"
        port: 6514
        transport: "tls"
        framing: "octet_counting"
      filters:
        includeActionPatterns:
          - "ws.*"
          - "backoffice.*"
        excludeActionPatterns:
          - "ws.user.enable"
        includeOrgIds:
          - "01985a4d-3c21-7000-8003-0e10dd81d901"
      delivery:
        timeoutSeconds: 10
        failurePolicy: "drop"
        reconnect:
          enabled: true
          backoffSeconds: 5
        queue:
          maxEvents: 10000
        batch:
          maxEvents: 25
          maxDelayMillis: 250
          drainTimeoutMillis: 1000
      tls:
        verifyCertificate: true
        caFile: "/etc/zylon/certs/syslog-ca.pem"

The full example limits delivery to matching Workspace and Backoffice actions in one organization. Remove or revise those filters if you also need security events or gateway events without an action or organization ID.

Syslog simplified example

logging:
  delivery:
    syslog:
      enabled: true
      format: "rfc5424_json"
      endpoint:
        host: "syslog.example.com"
        port: 6514
        transport: "tls"

HTTP delivery

HTTP delivery sends structured JSON records to an HTTP collector. Use it for ingestion gateways, data lakes, or pipelines that transform Zylon’s canonical payload downstream. The supported HTTP format is canonical_json. The schema value is zylon.canonical_json.v1. HTTP supports POST, optional bearer authentication, static headers using Header=Value or Header: Value, retries for network errors and HTTP 5xx responses, and no retry for HTTP 4xx client errors. Vendor-specific transformations should happen at the collector or ingestion layer.

HTTP keys

Under logging.delivery.http:

Key	Default	Values	Description
`enabled`	`false`	`true`, `false`	Enables HTTP delivery.
`format`	`canonical_json`	`canonical_json`	HTTP payload format.
`endpoint.url`	empty	URL	Required when HTTP delivery is enabled.
`endpoint.method`	`POST`	`POST`	HTTP method.
`headers`	`[]`	YAML list, up to 5 entries	Static outbound headers. Supports `Header=Value` and `Header: Value`.

Optional HTTP keys

Optional authentication, filter, delivery, queue, and batch settings are configured under their matching nested blocks in logging.delivery.http.Under auth:

Key	Default	Values	Description
`type`	`none`	`none`, `bearer`	Authentication mode.
`token`	empty	string	Required when `type` is `bearer`. Sent as `Authorization: Bearer <token>`.

Under filters:

Key	Default	Values	Description
`includeActionPatterns`	`[]`	wildcard list	If non-empty, only matching action names are delivered.
`excludeActionPatterns`	`[]`	wildcard list	Matching action names are excluded before include filters are evaluated.
`includeOrgIds`	`[]`	organization UUID list	If non-empty, only logs for matching organization IDs are delivered.

Under delivery:

Key	Default	Values	Description
`timeoutSeconds`	`10`	positive integer	HTTP connect, read, and write timeout.
`failurePolicy`	`drop`	`drop`, `block`	Queue behavior when the async queue is full.

Under delivery.retry:

Key	Default	Values	Description
`enabled`	`true`	`true`, `false`	Enables HTTP retry.
`maxAttempts`	`3`	positive integer	Total request attempts, including the initial attempt, when retry is enabled.
`backoffSeconds`	`3`	non-negative integer	Sleep between retry attempts.

Under delivery.queue:

Key	Default	Values	Description
`maxEvents`	`10000`	positive integer	Async delivery queue capacity.

Under delivery.batch:

Key	Default	Values	Description
`maxEvents`	`25`	positive integer	Maximum events per HTTP request. Multi-event batches are sent as a JSON array.
`maxDelayMillis`	`250`	positive integer	Maximum time to wait before flushing a partial batch.
`drainTimeoutMillis`	`1000`	positive integer	Shutdown drain timeout for queued batch entries.

HTTP full example

logging:
  delivery:
    http:
      enabled: true
      format: "canonical_json"
      endpoint:
        url: "https://collector.example.com/logs"
        method: "POST"
      auth:
        type: "bearer"
        token: "replace-me"
      headers:
        - "X-Collector-Token=replace-me"
        - "X-Customer: default"
      filters:
        includeActionPatterns: []
        excludeActionPatterns: []
        includeOrgIds: []
      delivery:
        timeoutSeconds: 10
        failurePolicy: "drop"
        retry:
          enabled: true
          maxAttempts: 3
          backoffSeconds: 3
        queue:
          maxEvents: 10000
        batch:
          maxEvents: 25
          maxDelayMillis: 250
          drainTimeoutMillis: 1000

HTTP simplified example

logging:
  delivery:
    http:
      enabled: true
      format: "canonical_json"
      endpoint:
        url: "https://collector.example.com/logs"
        method: "POST"

Filtering delivered events

Syslog and HTTP delivery use the same filter behavior under filters.

Key	Default	Values	Description
`includeActionPatterns`	`[]`	wildcard list	If non-empty, only matching action names are delivered; logs without an action are excluded. `*` matches any number of characters. Matching is case-sensitive and covers the full action string.
`excludeActionPatterns`	`[]`	wildcard list	Matching action names are excluded before include filters are evaluated.
`includeOrgIds`	`[]`	organization UUID list	If non-empty, only logs for matching organization IDs are delivered. Logs without `organization_id` are not delivered.

Evaluation order:

Exclude action patterns.
Include action patterns.
Included organization IDs.

Delivery behavior

The delivery pipeline is:

Zylon emits a structured log event.
Delivery filters decide whether to deliver it externally.
The event is normalized with severity, outcome, and actor metadata.
The event is formatted as syslog, CEF, or canonical JSON.
The formatted payload is placed on the async delivery queue.
The delivery worker sends the event to the configured destination.
Reconnect or retry behavior applies when delivery fails.

Operational controls

Keep all Zylon backend nodes synchronized to a trusted time source such as NTP. The Helm chart sets the cleanup scheduler timezone to UTC by default; if the runtime setting is omitted outside Helm, the backend uses the server JVM time zone. Log records should be reviewed in UTC for cross-system forensic correlation. Treat changes to logging.storage, logging.delivery, filters, retention, and collector destinations as auditable deployment changes. Capture approvals and diffs in GitOps, change management, Kubernetes audit logs, or the infrastructure audit system used by the customer. Delivered payload schemas use markers such as zylon.rfc5424_json.v1 and zylon.canonical_json.v1. SIEM parsers should route by schema marker and validate parser compatibility during upgrades.

Failure policies

Policy	Behavior	Use when
`drop`	Drops events when the async queue is full and avoids blocking request threads.	Recommended default for most production deployments.
`block`	Applies backpressure when the queue is full.	Use only when delivery completeness is more important than request latency.

failurePolicy: "block" can slow requests when the delivery queue is full. Use it only after sizing queues and confirming collector availability.

These policies control queue backpressure only. block does not guarantee delivery: failed batches can still be discarded after non-retryable responses or exhausted retries. Disk-backed external delivery spooling and automatic replay from internal storage are not implemented.

Queue and batching

Setting	Description
`maxEvents`	Maximum events that can wait in the async delivery queue, or maximum events per delivery batch when set under `batch`. Larger queues absorb bursts but use more memory; larger batches can improve throughput but can increase delay.
`maxDelayMillis`	Maximum time before a partial batch is flushed. Smaller values reduce latency.
`drainTimeoutMillis`	Time allowed to drain queued batch entries during shutdown.

For syslog over UDP, the maxEvents value under delivery.batch is forced to 1, because one datagram carries one event. For HTTP, multi-event batches are delivered as a JSON array.

Queue and batching settings already have production defaults. If your HTTP destination, SIEM, or log collector does not require specific values, leave the defaults unchanged. Customize them only when your environment needs different throughput, latency, or burst handling.

Reconnect and retry

Syslog reconnect

TCP and TLS syslog delivery lazily opens a socket, reuses it, and retries the current batch once on a fresh connection after write failure. If retry fails, the reconnect backoff window applies.

Setting	Description
`enabled`	Enables reconnect after socket failure. If disabled, future reconnect attempts stop after the first failure until process restart or appender reset.
`backoffSeconds`	Time before another connect attempt after failure.

HTTP retry

HTTP delivery reuses one HTTP client and retries failed requests according to retry settings.

Setting	Description
`enabled`	Enables retry after retryable failures.
`maxAttempts`	Maximum attempts for one delivery.
`backoffSeconds`	Sleep between attempts.

HTTP retries network exceptions and HTTP 5xx responses. HTTP 4xx responses, including 429, are not retried. After a non-retryable failure or exhausted retries, the failed batch is discarded and a delivery warning is logged; it is not automatically recovered from internal storage.

TLS configuration

Setting	Description
`verifyCertificate`	Enables TLS certificate verification and hostname verification for syslog TLS.
`caFile`	Path to a readable CA file used to trust a private collector CA when verification is enabled.

Local or lab deployments may disable certificate verification. Production deployments should enable certificate verification when the collector has a trusted certificate path. Use caFile under tls when the collector uses a private CA.

Local validation

Enable one delivery channel.
Apply configuration.
Trigger an API action that emits a log, such as project creation or API token creation.
Query the collector.
Confirm the expected event, action, log.id, and actor fields appear.
Check backend logs for delivery warnings.

Validation queries depend on your collector. Use whichever search or inspection tool your destination provides, then confirm one of these payload markers appears:

zylon.rfc5424_json.v1 for RFC 5424 JSON syslog payloads.
CEF:0|Zylon for CEF payloads.
zylon.canonical_json.v1 for HTTP payloads.
A known action such as ws.project.create.

For reconnect testing, stop the collector, trigger events, restart the collector, then confirm new events arrive after the reconnect backoff.

Troubleshooting

Symptom	What to check
No events arrive	`logging.delivery.http.enabled` or `logging.delivery.syslog.enabled`, nested `endpoint` settings, collector reachability, filters, and backend logs. Apply changes with `sudo zylon-cli sync` on CLI-managed installations.
Syslog startup fails	Missing host, invalid port, unsupported format/transport/framing, or unreadable CA file.
TLS connection fails	Certificate verification, CA file, collector certificate, and hostname.
CEF events are not parsed	`format: "cef"`, collector input type, and port.
Requests slow down	`failurePolicy: "block"`, queue size, collector throughput, and backend logs.
Missing events during bursts	Queue size, batch settings, collector throughput, and whether `failurePolicy: "drop"` is acceptable.
Events do not reconnect after outage	Reconnect enabled setting, backoff setting, and backend logs.
HTTP delivery fails	`endpoint.url`, `endpoint.method`, collector bearer token, static headers, retry settings, and backend logs. Confirm the collector accepts JSON arrays for multi-event batches, or set `delivery.batch.maxEvents: 1`.
HTTP keeps failing without retry	Collector HTTP `4xx` responses. Fix auth, URL, headers, or collector route.
Retention is shorter than expected	Log cleanup settings, DB retention/backup policy, and downstream collector retention.

Recommended production defaults

For syslog and SIEM:

Prefer TLS where supported.
Prefer rfc5424_json for structured syslog ingestion unless the collector requires CEF.
Use octet_counting or newline according to the collector input.
Enable certificate verification in production where possible.
Keep failurePolicy: "drop" unless strict delivery completeness is more important than request latency.
Keep queue and batch defaults unless your destination requires different throughput, latency, or burst handling.
Keep stored log retention at or above 180 days unless legal, security, and operations teams approve a shorter period.

For HTTP:

Use canonical_json.
Keep vendor-specific transformations at the ingestion layer.
Use bearer authentication and static headers when required by the collector.
Tune retry settings for the collector’s availability profile.
Confirm downstream retention in the customer-controlled collector.

​Overview

​Send logs to your SIEM

​1. Prepare your collector

​2. Configure Zylon

​3. Apply the configuration

​4. Verify a new event

​5. Choose internal and SIEM retention

​At a glance

​Before you configure delivery

​Choose a delivery channel

​Storage and retention

​Storage keys

​Retention keys

​Configure cleanup for stored logs only

​Syslog delivery

​Supported syslog matrix

​Syslog keys

​Syslog full example

​Syslog simplified example

​HTTP delivery

​HTTP keys

​HTTP full example

​HTTP simplified example

​Filtering delivered events

​Delivery behavior

​Operational controls

​Failure policies

​Queue and batching

​Reconnect and retry

​Syslog reconnect

​HTTP retry

​TLS configuration

​Local validation

​Troubleshooting

​Recommended production defaults

Overview

Send logs to your SIEM

1. Prepare your collector

2. Configure Zylon

3. Apply the configuration

4. Verify a new event

5. Choose internal and SIEM retention

At a glance

Before you configure delivery

Choose a delivery channel

Storage and retention

Storage keys

Retention keys

Configure cleanup for stored logs only

Syslog delivery

Supported syslog matrix

Syslog keys

Syslog full example

Syslog simplified example

HTTP delivery

HTTP keys

HTTP full example

HTTP simplified example

Filtering delivered events

Delivery behavior

Operational controls

Failure policies

Queue and batching

Reconnect and retry

Syslog reconnect

HTTP retry

TLS configuration

Local validation

Troubleshooting

Recommended production defaults