Web server log files

Plugin: go.d.plugin Module: web_log

Overview

This collector monitors web servers by parsing their log files.

This collector is supported on all platforms.

This collector supports collecting metrics from multiple instances of this integration, including remote instances.

Default Behavior

Auto-Detection

It automatically detects log files of web servers running on localhost.

Limits

The default configuration for this integration does not impose any limits on data collection.

Performance Impact

The default configuration for this integration is not expected to impose a significant performance impact on the system.

Setup

Prerequisites

No action required.

Configuration

File

The configuration file name for this integration is go.d/web_log.conf.

You can edit the configuration file using the edit-config script from the Netdata config directory.

cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata
sudo ./edit-config go.d/web_log.conf

Options

Weblog is aware of how to parse and interpret the following fields (known fields):

nginx

apache

Notes:

• Apache %h logs the IP address if HostnameLookups is Off. The web log collector counts hostnames as IPv4 addresses. We recommend either to disable HostnameLookups or use %a instead of %h.
• Since httpd 2.0, unlike 1.3, the %b and %B format strings do not represent the number of bytes sent to the client, but simply the size in bytes of the HTTP response. It will differ, for instance, if the connection is aborted, or if SSL is used. The %O format provided by mod_logio will log the actual number of bytes sent over the network.
• To get %I and %O working you need to enable mod_logio on Apache.
• NGINX logs URI with query parameters, Apache doesnt.
• $request is parsed into $request_method, $request_uri and $server_protocol. If you have $request in your log format, there is no sense to have others.
• Don’t use both $bytes_sent and $body_bytes_sent (%O and %B or %b). The module does not distinguish between these parameters.

url_patterns

“URL pattern” scope metrics will be collected for each URL pattern.

Option syntax:

url_patterns:
  - name: name1
    pattern: pattern1
  - name: name2
    pattern: pattern2

log_type

Weblog supports 5 different log parsers:

Syntax:

log_type: auto

If log_type parameter set to auto (which is default), weblog will try to auto-detect appropriate log parser and log format using the last line of the log file.

• checks if format is CSV (using regexp).

• checks if format is JSON (using regexp).

• assumes format is CSV and tries to find appropriate CSV log format using predefined list of formats. It tries to parse the line using each of them in the following order (the first one matches is used later):

  $host:$server_port $remote_addr - - [$time_local] "$request" $status $body_bytes_sent - - $request_length $request_time $upstream_response_time
  $host:$server_port $remote_addr - - [$time_local] "$request" $status $body_bytes_sent - - $request_length $request_time
  $host:$server_port $remote_addr - - [$time_local] "$request" $status $body_bytes_sent     $request_length $request_time $upstream_response_time
  $host:$server_port $remote_addr - - [$time_local] "$request" $status $body_bytes_sent     $request_length $request_time
  $host:$server_port $remote_addr - - [$time_local] "$request" $status $body_bytes_sent
  $remote_addr - - [$time_local] "$request" $status $body_bytes_sent - - $request_length $request_time $upstream_response_time
  $remote_addr - - [$time_local] "$request" $status $body_bytes_sent - - $request_length $request_time
  $remote_addr - - [$time_local] "$request" $status $body_bytes_sent     $request_length $request_time $upstream_response_time
  $remote_addr - - [$time_local] "$request" $status $body_bytes_sent     $request_length $request_time
  $remote_addr - - [$time_local] "$request" $status $body_bytes_sent
  

  If you’re using the default Apache/NGINX log format, auto-detect will work for you. If it doesn’t work you need to set the format manually.

csv_config.format

ltsv_config.mapping

The mapping is a dictionary where the key is a field, as in logs, and the value is the corresponding known field.

Note: don’t use $ and % prefixes for mapped field names.

log_type: ltsv
ltsv_config:
  mapping:
    label1: field1
    label2: field2

json_config.mapping

The mapping is a dictionary where the key is a field, as in logs, and the value is the corresponding known field.

Note: don’t use $ and % prefixes for mapped field names.

log_type: json
json_config:
  mapping:
    label1: field1
    label2: field2

regexp_config.pattern

Use pattern with subexpressions names. These names should be known fields.

Note: don’t use $ and % prefixes for mapped field names.

Syntax:

log_type: regexp
regexp_config:
  pattern: PATTERN

Examples

There are no configuration examples.

Metrics

Metrics grouped by scope.

The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels.

Per Web server log files instance

These metrics refer to the entire monitored application.

This scope has no labels.

Metrics:

Per custom time field

TBD

This scope has no labels.

Metrics:

Per custom numeric field

TBD

This scope has no labels.

Metrics:

Per URL pattern

TBD

This scope has no labels.

Metrics:

Alerts

The following alerts are available:

Troubleshooting

Debug Mode

Important: Debug mode is not supported for data collection jobs created via the UI using the Dyncfg feature.

To troubleshoot issues with the web_log collector, run the go.d.plugin with the debug option enabled. The output should give you clues as to why the collector isn’t working.

• Navigate to the plugins.d directory, usually at /usr/libexec/netdata/plugins.d/. If that’s not the case on your system, open netdata.conf and look for the plugins setting under [directories].

  cd /usr/libexec/netdata/plugins.d/
  

• Switch to the netdata user.

  sudo -u netdata -s
  

• Run the go.d.plugin to debug the collector:

  ./go.d.plugin -d -m web_log
  

Getting Logs

If you’re encountering problems with the web_log collector, follow these steps to retrieve logs and identify potential issues:

• Run the command specific to your system (systemd, non-systemd, or Docker container).
• Examine the output for any warnings or error messages that might indicate issues. These messages should provide clues about the root cause of the problem.

System with systemd

Use the following command to view logs generated since the last Netdata service restart:

journalctl _SYSTEMD_INVOCATION_ID="$(systemctl show --value --property=InvocationID netdata)" --namespace=netdata --grep web_log

System without systemd

Locate the collector log file, typically at /var/log/netdata/collector.log, and use grep to filter for collector’s name:

grep web_log /var/log/netdata/collector.log

Note: This method shows logs from all restarts. Focus on the latest entries for troubleshooting current issues.

Docker Container

If your Netdata runs in a Docker container named “netdata” (replace if different), use this command:

docker logs netdata 2>&1 | grep web_log