Scribd
Upload
255 views3 pages

Monitor Statistics and Metrics of Syslog

This document discusses monitoring statistics and metrics for syslog-ng. There are 4 levels of statistics that provide increasing detail about sources, destinations, files, filters and other syslog-ng components. The monitoring() source allows selecting specific statistics to monitor and outputs them in a structured format like JSON. An example shows configuring the monitoring() source to output all available statistics in JSON format to a file every 10 seconds.

Uploaded by

Lê Cường
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
255 views3 pages

Monitor Statistics and Metrics of Syslog

This document discusses monitoring statistics and metrics for syslog-ng. There are 4 levels of statistics that provide increasing detail about sources, destinations, files, filters and other syslog-ng components. The monitoring() source allows selecting specific statistics to monitor and outputs them in a structured format like JSON. An example shows configuring the monitoring() source to output all available statistics in JSON format to a file every 10 seconds.

Uploaded by

Lê Cường
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Monitor statistics and metrics of syslog-ng

First, need to define stats level .There are 4 stats level :

 Level 0 : statistics about the sources and destinations.


 Level 1 : statistics about sources ,destinations , files, filters and so on .
 Level 2 : detailed statistics based on the hostname.
 Level 3 : very detailed statistics based on various message parameters like facility, severity, or tags.
Note that level 2 and 3 increase the memory requirements and CPU load. For details on message statistics

Implement the monitoring() source


The monitoring() source allows you to select which statistics of syslog-ng PE you want to monitor.  The statistics
are available as structured name-value pairs so you can easily convert the statistics and metrics, for example, into
JSON or WELF format.

The monitoring() source queries the statistics (counters) that syslog-ng PE collects, formats them, and optionally
resets the counters.

Example: Save all statistics into a file in JSON format :


The following configuration increases the stats-level() option to 3, generates a JSON-formatted message every
10 seconds. The generated message contains every available statistics, and is saved into the /var/log/syslog-ng-
statistics.log file.

The generated message is similar to this one:

The query() option is required in monitoring():

Type: String
Description: Specifies which statistics will be included in the messages. Note that the list of available statistics
depends on your syslog-ng PE configuration (mainly the configured sources and destinations) and on the stats-level()
global option. The * string includes every available counters. The syntax of the query option is identical to the syslog-
ng-ctl query get “<query>” command.

Example:  

the "destination*" query lists the configured destinations, and the metrics related to each destination.

The type of the statistics:


 processed: The number of messages that successfully reached their destination driver. Note that this does not
necessarily mean that the destination driver successfully delivered the messages (for example, written to disk or sent to a
remote server).
 dropped: The number of dropped messages — syslog-ng PE could not send the messages to the destination and the
output buffer got full, so messages were dropped by the destination driver, or syslog-ng PE dropped the message for
some other reason (for example, a parsing error).
 queued: The number of messages passed to the message queue of the destination driver, waiting to be sent to the
destination.
 suppressed: The number of suppressed messages (if the suppress() feature is enabled).
 stamp: The UNIX timestamp of the last message sent to the destination.
 discarded: The number of messages discarded by the given parser. These are messages that the parser could not
parsed, and are therefore not processed. For example:
parser;demo_parser;;a;discarded;20

 memory_usage: The memory used by the messages in the different queue types (in bytes). This includes every queue
used by the object, including memory buffers (log-fifo) and disk-based buffers (both reliable and non-reliable). For
example:
dst.network;d_net#0;tcp,127.0.0.1:9999;a;memory_usage;0

 matched: The number of messages that are accepted by a given filter. Available for filters and similar objects (for
example, a conditional rewrite rule). For example, if a filter matches a specific hostname, then the matched counter
contains the number of messages that reached the filter from this hosts.
filter;demo_filter;;a;matched;28

 not_matched: The number of messages that are filtered out by a given filter. Available for filters and similar objects
(for example, a conditional rewrite rule). For example, if a filter matches a specific hostname, then
the not_matched counter contains the number of messages that reached the filter from other hosts, and so the filter
discarded them.
filter;demo_filter;;a;not_matched;0

 written: The number of messages successfully delivered to the destination. This value is calculated from other
counters: written = processed - queued - dropped. This metric is calculated from other metrics. You cannot reset this
metric directly: to reset it, you have to reset the metrics it is calculated from.

You might also like