syslog-ng-ctl.1.md

title	weight
The syslog-ng control tool manual page	4900

Name

syslog-ng-ctl — Display message statistics and enable verbose, debug and trace modes

Synopsis

syslog-ng-ctl [command] [options]

Description

{{% alert title="Note" color="info" %}}

The syslog-ng-ctl application is distributed with the {{% param "product.ose" %}} system logging application, and is usually part of the {{% param "product.ose" %}} package.

{{% /alert %}}

The syslog-ng-ctl application is a utility that can be used to:

• enable/disable various {{% param "product.ose" %}} messages for troubleshooting

• display statistics about the processed messages

• handling password-protected private keys

• display the currently running configuration of {{% param "product.ose" %}}

• reload the configuration of {{% param "product.ose" %}}.

Enabling troubleshooting messages

syslog-ng-ctl log-level <level>

Available in {{% param "product.abbrev" %}} 4.0 and later.

Use the syslog-ng-ctl log-level <level> command to display verbose, trace, or debug messages. If you are trying to solve configuration problems, the verbose (and occasionally debug) messages are usually sufficient. Trace messages are needed mostly for finding software errors. After solving the problem, do not forget to return the log level to the default using the syslog-ng-ctl log-level default command.

Use syslog-ng-ctl log-level without any parameters to display the current log level.

If {{% param "product.ose" %}} was started with the --stderr or -e option, the messages will be sent to stderr. If not specified, {{% param "product.ose" %}} will log such messages to its internal source.

If you need to use a non-standard control socket to access syslog-ng, use the syslog-ng-ctl <command> --control=<socket> command to specify the socket to use.

{{< include-headless "chunk/internal-log-levels.md" >}}

Example

syslog-ng-ctl log-level verbose

syslog-ng-ctl query

The {{% param "product.ose" %}} application stores various data, metrics, and statistics in a hash table. Every property has a name and a value. For example:

[syslog-ng]
  |       
  |_[destinations]-[network]-[tcp]->[stats]->{received=12;dropped=2}
  |
  |_[sources]-[sql]-[stats]->{received=501;dropped=0}

You can query the nodes of this tree, and also use filters to select the information you need. A query is actually a path in the tree. You can also use the ? and \* wildcards. For example:

• Select every property: \*

• Select all dropped value from every stats node: \*.stats.dropped

The nodes and properties available in the tree depend on your {{% param "product.ose" %}} configuration (that is, the sources, destinations, and other objects you have configured), and also on your stats-level() settings.

The list command

syslog-ng-ctl query list

Use the syslog-ng-ctl query list command to display the list of metrics that {{% param "product.ose" %}} collects about the processed messages.

An example output:

  center.received.stats.processed
  center.queued.stats.processed
  destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.dropped
  destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.processed
  destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.queued
  destination.d_elastic.stats.processed
  source.s_tcp.stats.processed
  source.severity.7.stats.processed
  source.severity.0.stats.processed
  source.severity.1.stats.processed
  source.severity.2.stats.processed
  source.severity.3.stats.processed
  source.severity.4.stats.processed
  source.severity.5.stats.processed
  source.severity.6.stats.processed
  source.facility.7.stats.processed
  source.facility.16.stats.processed
  source.facility.8.stats.processed
  source.facility.17.stats.processed
  source.facility.9.stats.processed
  source.facility.18.stats.processed
  source.facility.19.stats.processed
  source.facility.20.stats.processed
  source.facility.0.stats.processed
  source.facility.21.stats.processed
  source.facility.1.stats.processed
  source.facility.10.stats.processed
  source.facility.22.stats.processed
  source.facility.2.stats.processed
  source.facility.11.stats.processed
  source.facility.23.stats.processed
  source.facility.3.stats.processed
  source.facility.12.stats.processed
  source.facility.4.stats.processed
  source.facility.13.stats.processed
  source.facility.5.stats.processed
  source.facility.14.stats.processed
  source.facility.6.stats.processed
  source.facility.15.stats.processed
  source.facility.other.stats.processed
  global.payload_reallocs.stats.processed
  global.msg_clones.stats.processed
  global.sdata_updates.stats.processed
              tag..source.s_tcp.stats.processed

The syslog-ng-ctl query list command has the following options:

• --reset

  Use --reset to set the selected counters to 0 after executing the query.

Displaying metrics and statistics

syslog-ng-ctl query get [options]

The syslog-ng-ctl query get <query> command lists the nodes that match the query, and their values.

For example, the destination query lists the configured destinations, and the metrics related to each destination. An example output:

destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.dropped=0
destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.processed=0
destination.java.d_elastic#0.java_dst(ElasticSearch,elasticsearch-syslog-ng-test,t7cde889529c034aea9ec_micek).stats.queued=0
destination.d_elastic.stats.processed=0

The syslog-ng-ctl query get command has the following options:

• --sum

  Add up the result of each matching node and return only a single number.

  For example, the syslog-ng-ctl query get --sum "destination\*.dropped" command displays the number of messages dropped by the {{% param "product.ose" %}} instance.

• --reset

  Use --reset to set the selected counters to 0 after executing the query.

The stats command

stats [options]

Use the stats command to display statistics and metrics about the processed messages.

• For details about the available Prometheus-like metrics, see {{% xref "/metrics/reference-metrics/_index.md" %}}. You can retrieve these metrics with the syslog-ng-ctl stats prometheus command.
• For details about legacy statistics, see {{% xref "/chapter-log-statistics/_index.md" %}}.

The stats command has the following options:

• --control=<socket> or -c

  Specify the socket to use to access {{% param "product.ose" %}}. Only needed when using a non-standard socket.

• --reset=<socket> or -r

  Reset all statistics to zero, except for the queued counters. (The queued counters show the number of messages in the message queue of the destination driver, waiting to be sent to the destination.)

• --remove-orphans

  Safely removes all counters that are not referenced by any statistics producer objects.

  The flag can be used to prune dynamic and static counters manually. This is useful, for example, when a templated file destination produces a lot of stats:

      dst.file;#anon-destination0#0;/tmp/2021-08-16.log;o;processed;253592
      dst.file;#anon-destination0#0;/tmp/2021-08-17.log;o;processed;156
      dst.file;#anon-destination0#0;/tmp/2021-08-18.log;a;processed;961

  {{% alert title="Note" color="info" %}} The stats-lifetime() can be used to do the same automatically and periodically, but currently stats-lifetime() removes only dynamic counters that have a timestamp field set. {{% /alert %}}

Example for statistics

syslog-ng-ctl stats

An example output:

src.internal;s_all#0;;a;processed;6445
src.internal;s_all#0;;a;stamp;1268989330
destination;df_auth;;a;processed;404
destination;df_news_dot_notice;;a;processed;0
destination;df_news_dot_err;;a;processed;0
destination;d_ssb;;a;processed;7128
destination;df_uucp;;a;processed;0
source;s_all;;a;processed;7128
destination;df_mail;;a;processed;0
destination;df_user;;a;processed;1
destination;df_daemon;;a;processed;1
destination;df_debug;;a;processed;15
destination;df_messages;;a;processed;54
destination;dp_xconsole;;a;processed;671
dst.tcp;d_network#0;10.50.0.111:514;a;dropped;5080
dst.tcp;d_network#0;10.50.0.111:514;a;processed;7128
dst.tcp;d_network#0;10.50.0.111:514;a;queued;2048
destination;df_syslog;;a;processed;6724
destination;df_facility_dot_warn;;a;processed;0
destination;df_news_dot_crit;;a;processed;0
destination;df_lpr;;a;processed;0
destination;du_all;;a;processed;0
destination;df_facility_dot_info;;a;processed;0
center;;received;a;processed;0
destination;df_kern;;a;processed;70
center;;queued;a;processed;0
destination;df_facility_dot_err;;a;processed;0

For details about legacy statistics, see {{% xref "/chapter-log-statistics/_index.md" %}}.

Example for statistics

syslog-ng-ctl stats prometheus

The output is similar to:

syslogng_events_allocated_bytes 18446744073709550560
syslogng_filtered_events_total{id="#anon-filter0",result="matched"} 0
syslogng_filtered_events_total{id="#anon-filter0",result="not_matched"} 2
syslogng_filtered_events_total{id="ff",result="matched"} 0
syslogng_filtered_events_total{id="ff",result="not_matched"} 2
syslogng_input_events_total{id="#anon-source0#0",driver_instance="-",result="processed"} 0
syslogng_input_events_total{id="s_network#1",result="processed"} 2
syslogng_internal_source{result="dropped"} 0
syslogng_internal_source{result="queued"} 0
syslogng_output_events_total{id="d_dest#0",driver_instance="tcp,127.0.0.1:5555",result="delivered"} 0
syslogng_output_events_total{id="d_dest#0",driver_instance="tcp,127.0.0.1:5555",result="dropped"} 0
syslogng_output_events_total{id="d_dest#0",driver_instance="tcp,127.0.0.1:5555",result="queued"} 0
syslogng_output_events_total{id="d_dest#1",driver_instance="http,https://localhost:8080",result="delivered"} 0
syslogng_output_events_total{id="d_dest#1",driver_instance="http,https://localhost:8080",result="dropped"} 0
syslogng_output_events_total{id="d_dest#1",driver_instance="http,https://localhost:8080",result="queued"} 0
syslogng_parsed_events_total{id="#anon-parser0",result="discarded"} 0
syslogng_parsed_events_total{id="#anon-parser0",result="processed"} 0
syslogng_scratch_buffers_bytes 0
syslogng_scratch_buffers_total 3
syslogng_tagged_events_total{id=".source.#anon-source0",result="processed"} 0
syslogng_tagged_events_total{id=".source.s_network",result="processed"} 2

For details about the available Prometheus-like metrics, see {{% xref "/metrics/reference-metrics/_index.md" %}}.

Handling password-protected private keys

syslog-ng-ctl credentials [options]

The syslog-ng-ctl credentials status command allows you to query the status of the private keys that {{% param "product.ose" %}} uses in the network() and syslog() drivers. You can also provide the passphrase for password-protected private keys using the syslog-ng-ctl credentials add command. For details on using password-protected keys, see The syslog-ng Administrator Guide.

Displaying the status of private keys

syslog-ng-ctl credentials status [options]

The syslog-ng-ctl credentials status command allows you to query the status of the private keys that {{% param "product.ose" %}} uses in the network() and syslog() drivers. The command returns the list of private keys used, and their status. For example:

  syslog-ng-ctl credentials status
  Secret store status:
  /home/user/ssl_test/client-1/client-encrypted.key SUCCESS

If the status of a key is PENDING, you must provide the passphrase for the key, otherwise {{% param "product.ose" %}} cannot use it. The sources and destinations that use these keys will not work until you provide the passwords. Other parts of the {{% param "product.ose" %}} configuration will be unaffected. You must provide the passphrase of the password-protected keys every time {{% param "product.ose" %}} is restarted.

The following log message also notifies you of PENDING passphrases:

Waiting for password; keyfile='private.key'

• --control=<socket> or -c

  Specify the socket to use to access {{% param "product.ose" %}}. Only needed when using a non-standard socket.

Opening password-protected private keys

syslog-ng-ctl credentials add [options]

You can add the passphrase to a password-protected private key file using the following command. {{% param "product.ose" %}} will display a prompt for you to enter the passphrase. We recommend that you use this method.

syslog-ng-ctl credentials add --id=<path-to-the-key>

Alternatively, you can include the passphrase in the --secret parameter:

syslog-ng-ctl credentials add --id=<path-to-the-key> --secret=<passphrase-of-the-key>

Or you can pipe the passphrase to the syslog-ng-ctl command, for example:

echo "<passphrase-of-the-key>" | syslog-ng-ctl credentials add --id=<path-to-the-key>

• --control=<socket> or -c

  Specify the socket to use to access {{% param "product.ose" %}}. Only needed when using a non-standard socket.

• --id=<path-to-the-key> or -i

  The path to the password-protected private key file. This is the same path that you use in the key-file() option of the {{% param "product.ose" %}} configuration file.

• --secret=<passphrase-of-the-key> or -s

  The password or passphrase of the private key.

Displaying the configuration

syslog-ng-ctl config [options]

Use the syslog-ng-ctl config command to display the configuration that {{% param "product.ose" %}} is currently running. By default, only the content of the main configuration file is displayed, included files are not resolved. To resolve included files and display the entire configuration, use the syslog-ng-ctl config --preprocessed command.

Starting with {{% param "product.name" %}} version 4.2, you can display the configuration identifier (if set) and the SHA256 has of the output of the syslog-ng-ctl config --preprocessed command by running syslog-ng-ctl config --id. For details, see {{% xref "/chapter-configuration-file/configuration-identifier/_index.md" %}}.

Reloading the configuration

syslog-ng-ctl reload [options]

Use the syslog-ng-ctl reload command to reload the configuration file of {{% param "product.ose" %}} without having to restart the {{% param "product.ose" %}} application. The syslog-ng-ctl reload works like a SIGHUP.

The syslog-ng-ctl reload command returns 0 if the operation was successful, 1 otherwise.

The healthcheck command

Available in {{% param "product.abbrev" %}} 4.2 and later.

You can use the syslog-ng-ctl healthcheck command to query the healthcheck status of {{% param "product.ose" %}}. The following health values are reported:

• mainloop_io_worker_roundtrip_latency_nanoseconds: mainloop->io-worker-job->mainloop roundtrip - a basic latency measure for {{% param "product.ose" %}}.
• io_worker_latency_nanoseconds: io-worker-job start latency.
• syslogng_internal_events_queue_usage_ratio: If you are using the [internal()]({{< relref "/chapter-sources/configuring-sources-internal/_index.md" >}}) source in your configuration, then this value shows the saturation of the internal source's queue, ranging from 0 to 1. Non-zero values indicate some kind of disruption in the pipelines.

You can run syslog-ng-ctl healthcheck --timeout <seconds> to use as a boolean healthy/unhealthy check.

Health checks are also published as periodically updated metrics. You can configure the frequency of these checks with the stats(healthcheck-freq()) option. The default is 5 minutes.

Files

/opt/syslog-ng/sbin/syslog-ng-ctl

See also

The syslog-ng.conf manual page

{{% xref "/app-man-syslog-ng/syslog-ng.8/_index.md" %}}

{{% alert title="Note" color="info" %}}

If you experience any problems or need help with {{% param "product.abbrev" %}}, {{% param "product.contact" %}}.

For news and notifications about {{% param "product.abbrev" %}}, visit the AxoFlow blog.

{{% /alert %}}