Public preview
otelcol.receiver.syslog
Public preview: This is a public preview component. Public preview components are subject to breaking changes, and may be replaced with equivalent functionality that cover the same use case. The
stability.level
flag must be set topublic-preview
or below to use the component.
otelcol.receiver.syslog
accepts syslog messages over the network and forwards them as logs to other otelcol.*
components.
It supports syslog protocols RFC5424 and RFC3164 and can receive data over TCP
or UDP
.
Note
otelcol.receiver.syslog
is a wrapper over the upstream OpenTelemetry Collectorsyslog
receiver. Bug reports or feature requests will be redirected to the upstream repository, if necessary.
You can specify multiple otelcol.receiver.syslog
components by giving them different labels.
Usage
otelcol.receiver.syslog "LABEL" {
tcp { ... }
udp { ... }
output {
logs = [...]
}
}
Arguments
The following arguments are supported:
The protocol
argument specifies the syslog format supported by the receiver.
protocol
must be one of rfc5424
or rfc3164
The location
argument specifies a Time Zone identifier. The available locations depend on the local IANA Time Zone database.
Refer to the list of tz database time zones in Wikipedia for a non-comprehensive list.
The non_transparent_framing_trailer
and enable_octet_counting
arguments specify TCP syslog behavior as defined in RFC6587.
These arguments are mutually exclusive.
They can’t be used with a UDP syslog listener configured.
If configured, the non_transparent_framing_trailer
argument must be one of LF
, NUL
.
Blocks
The following blocks are supported inside the definition of
otelcol.receiver.syslog
:
A syslog receiver must have either a udp
or tcp
block configured.
The >
symbol indicates deeper levels of nesting. For example, tcp > tls
refers to a tls
block defined inside a tcp
block.
udp block
The udp
block configures a UDP syslog server.
The following arguments are supported:
The encoding
argument specifies the encoding of the incoming syslog messages.
encoding
must be one of utf-8
, utf-16le
, utf-16be
, ascii
, big5
, or nop
.
Refer to the upstream receiver documentation for more details.
multiline block
The multiline
block configures logic for splitting incoming log entries.
The following arguments are supported:
A multiline
block must contain either line_start_pattern
or line_end_pattern
.
If a multiline
block is not set, log entries will not be split.
async block
The async
block configures concurrent asynchronous readers for a UDP syslog server.
The following arguments are supported:
If async
is not set, a single goroutine will read and process messages synchronously.
tcp block
The tcp
block configures a TCP syslog server.
The following arguments are supported:
The encoding
argument specifies the encoding of the incoming syslog messages.
encoding
must be one of utf-8
, utf-16le
, utf-16be
, ascii
, big5
, nop
.
See the upstream receiver documentation for more details.
The max_log_size
argument has a minimum value of 64KiB
tls block
The tls
block configures TLS settings used for a server. If the tls
block
isn’t provided, TLS won’t be used for connections to the server.
The following arguments are supported:
If reload_interval
is set to "0s"
, the certificate never reloaded.
The following pairs of arguments are mutually exclusive and can’t both be set simultaneously:
ca_pem
andca_file
cert_pem
andcert_file
key_pem
andkey_file
If cipher_suites
is left blank, a safe default list is used.
Refer to the Go Cipher Suites documentation for a list of supported cipher suites.
client_ca_file
sets the ClientCA
and ClientAuth
to RequireAndVerifyClientCert
in the TLSConfig
.
Refer to the Go TLS documentation for more information.
retry on failure block
The retry_on_failure
block configures the retry behavior when the receiver encounters an error downstream in the pipeline.
A backoff algorithm is used to delay the retry upon subsequent failures.
The following arguments are supported:
If max_elapsed_time
is set to 0
data will never be discarded.
debug_metrics block
The debug_metrics
block configures the metrics that this component generates to monitor its state.
The following arguments are supported:
disable_high_cardinality_metrics
is the Grafana Alloy equivalent to the telemetry.disableHighCardinalityMetrics
feature gate in the OpenTelemetry Collector.
It removes attributes that could cause high cardinality metrics.
For example, attributes with IP addresses and port numbers in metrics about HTTP and gRPC connections are removed.
Note
If configured,disable_high_cardinality_metrics
only applies tootelcol.exporter.*
andotelcol.receiver.*
components.
level
is the Alloy equivalent to the telemetry.metrics.level
feature gate in the OpenTelemetry Collector.
Possible values are "none"
, "basic"
, "normal"
and "detailed"
.
output block
The output
block configures a set of components to forward resulting telemetry data to.
The following arguments are supported:
You must specify the output
block, but all its arguments are optional.
By default, telemetry data is dropped.
Configure the metrics
, logs
, and traces
arguments accordingly to send telemetry data to other components.
Exported fields
otelcol.receiver.syslog
does not export any fields.
Component health
otelcol.receiver.syslog
is only reported as unhealthy if given an invalid
configuration.
Debug information
otelcol.receiver.syslog
does not expose any component-specific debug
information.
Debug metrics
otelcol.receiver.syslog
does not expose any component-specific debug metrics.
Example
This example proxies syslog messages from the otelcol.receiver.syslog
receiver to the
otelcol.exporter.syslog
component, and then sends them on to a loki.source.syslog
component
before being logged by a loki.echo
component. This shows how the otelcol
syslog components
can be used to proxy syslog messages before sending them to another destination.
Using the otelcol
syslog components in this way results in the messages being forwarded as sent,
attempting to use the loki.source.syslog
component for a similar proxy use case requires
careful mapping of any structured data fields through the otelcol.processor.transform
component. A
very simple example of that can be found in the otelcol.exporter.syslog
documentation.
Compatible components
otelcol.receiver.syslog
can accept arguments from the following components:
- Components that export OpenTelemetry
otelcol.Consumer
Note
Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.