Synadia Cloud

Managed NATS Message Queue

Synopsis

The Synadia Cloud target publishes log messages to Synadia's managed NATS JetStream service with enterprise features including global distribution, automatic scaling, and managed infrastructure. It takes the same settings as the generic NATS target, pointed at a Synadia Cloud endpoint.

Schema

- name: <string>
  description: <string>
  type: synadia
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    url: <string>
    subject: <string>
    username: <string>
    password: <string>
    timeout: <integer>
    batch_size: <integer>
    max_retries: <integer>
    retry_delay: <integer>
    tls:
      status: <boolean>
      verify: <boolean>
      cert_name: <string>
      key_name: <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:

Field	Required	Default	Description
name	Y		Target name
description	N	-	Optional description
type	Y		Must be synadia
pipelines	N	-	Optional post-processor pipelines
status	N	true	Enable/disable the target

Connection

Field	Required	Default	Description
url	Y	-	Synadia Cloud NATS URL (e.g., nats://connect.ngs.global:4222)
subject	Y	-	NATS subject name for message publishing
username	N	-	User name of a user in your Synadia Cloud account. Set it together with password
password	N	-	Password of that user. NKey seeds, user JWTs and credentials files are not accepted here
timeout	N	30	Connection timeout in seconds

Batch Configuration

Field	Required	Default	Description
batch_size	N	1000	Number of messages to batch before publishing (minimum 1)
max_retries	N	3	Maximum retry attempts for failed publish operations
retry_delay	N	1	Delay between retry attempts in seconds

Processing

Field	Required	Default	Description
field_format	N	-	Data normalization format. See applicable Normalization section

TLS Configuration

Field	Required	Default	Description
tls.status	N	false	Enable TLS encryption

TLS material is resolved through the shared client builder, so these keys mean the same thing on every target that uses it. They are nested under a tls: block.

Field	Required	Default	Description
tls.verify	N	true	Verify the server certificate. On by default — set it to false only to accept an untrusted certificate, and only where you control the network path
tls.server_name	N	-	SNI hostname override for the handshake. Use it when the certificate's name does not match the address you connect to
tls.ca_name	N	-	CA bundle used to verify the server certificate. When unset the host trust store is used; when set it replaces the host trust store rather than adding to it
tls.cert_name	N*	-	Client certificate, for mutual TLS
tls.key_name	N*	-	Client private key, for mutual TLS
tls.passphrase	N	-	Passphrase for an encrypted client private key
tls.min_tls_version	N	tls1.2	Lowest protocol version accepted (tls1.0, tls1.1, tls1.2, tls1.3)
tls.max_tls_version	N	tls1.3	Highest protocol version accepted (tls1.0, tls1.1, tls1.2, tls1.3)

* cert_name and key_name are individually optional but must be supplied together — a certificate without its key, or a key without its certificate, is a configuration error.

Scheduling

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

Debug Options

Field	Required	Default	Description
debug.status	N	false	Enable debug logging
debug.dont_send_logs	N	false	Process logs but don't send to target (testing)

Details

The Synadia Cloud target publishes log messages through JetStream, the NATS persistence layer. It behaves in every respect like the generic NATS target (type: nats), and the synadia type is provided for organizational clarity when connecting to Synadia's managed NATS service.

Authentication is by user name and password. Create a user with a password in your Synadia Cloud account, then set username and password to that pair. Set both, because with only one of them set no credential is sent and the connection is attempted anonymously. A token can be carried in url instead, written as nats://TOKEN@connect.ngs.global:4222. A credential carried that way is not echoed back: the destination recorded in the target's statistics has it removed, and reads nats://connect.ngs.global:4222/<subject>.

warning

An NKey seed, a user JWT and a credentials file cannot be used. Pasting an NKey seed into password sends it as a plain password, and the service answers nats: Authorization Violation.

The global endpoint nats://connect.ngs.global:4222 routes to the nearest regional cluster. Regional endpoints are available in the Synadia Cloud console for latency-sensitive deployments.

Messages are accumulated in batches and published to NATS JetStream subjects. JetStream must be enabled on the Synadia Cloud account. Each message is published with per-event retry logic up to max_retries attempts, waiting retry_delay seconds between attempts.

warning

Both tls.cert_name and tls.key_name must be provided together when using client certificate authentication. Providing only one will result in a configuration error.

warning

Ensure the Synadia Cloud account has publish permissions for the configured subjects. Permission denials cause publish failures.

Examples

Basic Configuration

Sending logs to Synadia Cloud using username/password authentication...

targets: - name: synadia-logs type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "logs.production" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}"

High-Volume Configuration

Optimizing for high-volume telemetry ingestion with larger batches...

targets: - name: synadia-high-volume type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "metrics.streaming" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}" batch_size: 1000 max_retries: 3 retry_delay: 1

With TLS Encryption

Enabling TLS encryption for secure data transmission...

targets: - name: synadia-secure type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "security.logs" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}" tls: status: true verify: true min_tls_version: tls1.2 max_tls_version: tls1.3

Multi-Subject Publishing

Publishing different event types to separate subjects...

targets: - name: synadia-security type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "logs.security" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}" - name: synadia-application type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "logs.application" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}"

With Normalization

Applying ECS normalization before publishing to Synadia Cloud...

targets: - name: synadia-normalized type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "logs.normalized" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}" field_format: ECS

Production Configuration

Production-ready configuration with user name and password authentication, TLS encryption, and batch optimization...

targets: - name: synadia-production type: synadia properties: url: "nats://connect.ngs.global:4222" subject: "production.telemetry" username: "${SYNADIA_USERNAME}" password: "${SYNADIA_PASSWORD}" timeout: 30 batch_size: 1000 max_retries: 3 retry_delay: 2 field_format: ASIM tls: status: true verify: true min_tls_version: tls1.2

Troubleshooting

The synadia target connects and publishes in exactly the same way as the nats target, over the same connection and the same JetStream publish path, so it reports the same errors for the same causes: authorization failures when the connection is made, publish failures when no stream covers the subject or the user may not publish to it, the size limits on a record, and the long flush that hides all of them. Each error is listed with its cause and its fix on NATS. Log lines and the connection status carry this target's name, so match on the cause text, which is the part after Reason: or after the last colon, rather than on the target name in the examples there. See Target Delivery Errors for how Director logs and retries target failures.

What differs for Synadia Cloud

Three properties of the service decide how a target for it is configured.

• Only a user name and a password are sent. Create a user with a password in your Synadia Cloud account, and put those two values in username and password. Set both: when only one of them is set, nothing is sent as a credential, the connection is attempted anonymously, and the service refuses it in the same way as a wrong password. A token can be carried in url instead, written as nats://TOKEN@connect.ngs.global:4222, and is stripped from the destination shown in the target's statistics.

• TLS is negotiated by the service. The endpoint requires TLS, so the connection is encrypted whether or not tls.status is set. What tls.status: true adds is your own settings: while it stays at its default of false, tls.verify, tls.ca_name, tls.server_name and the version range are ignored, and the host trust store is used on its own. Set it to true whenever it matters to you which certificate is accepted.

• JetStream depends on your account plan. Every record is published through JetStream, so a subject that no stream covers, or an account without JetStream, fails with nats: no response from stream. Nothing on the service side answers, so no explanation comes back with the error. Confirm in the Synadia Cloud console that the account has JetStream, and that the subjects of a stream cover subject.

warning

An NKey seed, a user JWT and a credentials file are not accepted in username or password. A seed pasted into password is sent as a plain password, and the service answers nats: Authorization Violation.

The limits on your account

Two account limits reach you as a connection or publish error rather than as anything that names the account.

• Each target holds one connection of its own. When the account has no free connection slot left, the connection fails with a reason that typically says the maximum number of active account connections has been exceeded. Count your targets against the limit on your plan.

• Stream storage is bounded by the plan as well. A publish into a full account is answered with nats: resource limits exceeded for account, or with nats: insufficient storage resources available. Raise the limit or drain the stream. Nothing is dropped meanwhile, and the batch is redelivered until it is accepted.