Logpoint

SIEM Platform

Synopsis

The Logpoint target forwards events, formatted as JSON, to Logpoint SIEM over syslog. It handles transport framing (UDP, TCP, or TLS) — the event payload is expected to already be in JSON format when it reaches the target.

Schema

- name: <string>
  description: <string>
  type: logpoint
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    address: <string>
    port: <numeric>
    protocol: <string>
    hostname: <string>
    priority: <numeric>
    template: <string>
    max_message_size: <numeric>
    application_name: <string>
    tls:
      status: <boolean>
      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:

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

Connection

Field	Required	Default	Description
address	Y	-	Logpoint syslog collector IP or hostname. Resolved at dial time
port	N	514	Remote receiver port. 514 for tcp/udp, often 6514 for tls. Valid range 1–65535
protocol	N	tcp	Transport protocol: tcp, udp, or tls

note

In the GUI, the Port field is prefilled with 514 and switches to 6514 — the IANA syslog-tls port — as soon as protocol is set to tls or TLS Encryption is enabled. It switches back if TLS is turned off. A port you type yourself is never changed, and leaving it blank keeps the server-side default. This runs in the create wizard only: a saved target keeps its stored port when its transport changes. The prefill is a console convenience — the configuration default remains 514 regardless of transport.

Framing

Field	Required	Default	Description
hostname	N	this host's name	Hostname written into the syslog header
priority	N	13	Syslog PRI value (facility×8 + severity). Valid range 0–191; 13 = user.notice
template	N	`<{{.Priority}}>{{.BSDTimestamp}} {{.Hostname}} {{.Message}}`	BSD (RFC 3164) syslog header template. Set to `{{.Message}}` to send the raw payload with no header
max_message_size	N	0	Maximum framed line length in bytes. 0 sends the full event
application_name	N	product name	Syslog tag / app-name. Only rendered when template references `{{.AppName}}` — the default template does not use it

TLS

Field	Required	Default	Description
tls.status	N	false	Enable TLS. Must be true for any other tls field to take effect, including with protocol: tls
tls.verify	N	true	Verify the server certificate
tls.server_name	N	-	SNI / expected server hostname
tls.ca_name	N	-	Custom CA to trust. Empty uses the OS trust store
tls.cert_name	N*	-	Client certificate for mutual TLS
tls.key_name	N*	-	Client key for mutual TLS
tls.passphrase	N	-	Passphrase for an encrypted client key
tls.min_tls_version	N	tls1.2	Minimum negotiated TLS version
tls.max_tls_version	N	tls1.3	Maximum 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.

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

Field	Required	Default	Description
field_format	N	-	Optional target-side normalization format applied before delivery. Typically left empty, since the payload already arrives in JSON from upstream processing. See applicable Normalization section

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

This target is transport-only: it does not build the JSON payload itself. It expects each event to already be a complete JSON record when it reaches the target, and applies syslog framing and delivery on top of that payload. There is no batching — each event is a single, complete delivery to the Logpoint syslog collector.

The JSON payload is delivered as top-level structured JSON, as long as it carries no top-level string message field. An event that does carry one is sent as that string alone, so the pipeline that renders the payload should leave no such field. See the Troubleshooting section below.

Template Variables

The following variables are available in template:

Variable	Description
{{.Year}}	Current year (4-digit)
{{.Month}}	Current month (2-digit)
{{.Day}}	Current day (2-digit)
{{.Priority}}	Syslog PRI value
{{.Timestamp}}	Current time, RFC3339
{{.BSDTimestamp}}	Current time, RFC3164 (Jan _2 15:04:05)
{{.Hostname}}	Syslog-header hostname
{{.AppName}}	Application name (application_name)
{{.PID}}	Process ID
{{.Message}}	The JSON payload

If template fails to render, the target falls back to sending the raw, sanitized payload with no header.

Framing and Transport

Embedded carriage returns and line feeds in the payload are neutralized before framing, so one event cannot forge a second line on the wire. On a TCP or TLS stream, exactly one trailing newline delimits each event (RFC 6587 non-transparent framing); this is harmless on UDP. No size limit applies by default (max_message_size: 0); set a cap when the transport is UDP and the receiver enforces a lower datagram limit.

TLS

Set tls.status: true to enable TLS. The flag also controls whether the rest of the tls block is read, so it is required even with protocol: tls. Without it, protocol: tls still encrypts the connection, but with defaults only: the receiver certificate is verified against the host trust store, the name checked is the host part of address, and tls.verify, tls.ca_name, tls.server_name, tls.cert_name and tls.key_name are all skipped. Setting tls.status: true also selects TLS whatever protocol says. A client certificate is optional, but supplying tls.cert_name without tls.key_name, or the other way round, fails configuration validation. tls.verify defaults to true.

note

The target does not perform JSON rendering or field mapping — it only frames and delivers the payload it receives. Format the event as JSON before it reaches this target.

Examples

Basic Configuration

Sending JSON events to a Logpoint syslog collector over TCP...

targets: - name: logpoint type: logpoint properties: address: "10.0.0.54"

Secure TLS

Delivering over an encrypted TLS connection with server verification...

targets: - name: logpoint-tls type: logpoint properties: address: "logpoint.example.com" port: 6514 protocol: tls tls: status: true verify: true

Capped UDP

Capping message size for a UDP receiver with a limited datagram size...

targets: - name: logpoint-udp type: logpoint properties: address: "10.0.0.54" protocol: udp max_message_size: 8192

Troubleshooting

The logpoint target delivers over syslog in exactly the same way as the arcsight target, and it reports the same errors for the same causes. Use the ArcSight troubleshooting section for the full list of errors, causes and fixes. Everything there applies here, with logpoint in place of arcsight. See Target Delivery Errors for how Director logs and retries target failures.

The entries you are most likely to need:

• A refused connection, an i/o timeout, or no such host while the target initializes.
• Certificate and handshake failures when the transport is TLS.
• failed to create per-worker siem syslog client: ... when the receiver runs out of connection slots.
• target broken: write ... after a quiet period, when the receiver closes an idle connection.
• message too long on udp, when one framed line is larger than a single datagram.
• A ValidateConfig failure, when address, port, priority, protocol or the client certificate pair is wrong.
• A healthy target with nothing arriving at the receiver.

Log lines and the connection status carry this target's own 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.

What differs for Logpoint

Only the payload you send, and what the receiver expects of it.

• The payload is structured JSON, not CEF. The ArcSight target sends CEF. This one frames and delivers the JSON document your pipeline renders, one event per line. Give it a collector on the Logpoint side that reads JSON over syslog. A collector configured for another format typically accepts the connection and then drops or mis-parses the events, and Director reports nothing.
• An event carrying a top-level string message field is sent as that string alone. The rest of the JSON document is discarded, so the collector receives plain text where it expects structured JSON. The pipelines that render the Logpoint payload typically leave no such field. If events arrive at Logpoint as plain text, check the payload your pipeline produces for a top-level message field, and remove or rename it.
• The TLS settings do nothing unless tls.status is true. Setting protocol: tls on its own encrypts the connection with defaults only. It does not enable tls.verify, tls.ca_name, tls.server_name or a client certificate. Read the entry on tls.status in the ArcSight troubleshooting section for the symptoms and the fix.

note

Set tls.status: true whenever any field in the tls block is meant to apply, including with protocol: tls.