Skip to main content

Web server log files

Plugin: go.d.plugin Module: web_log


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


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


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.


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.


web_log.type_requestssuccess, bad, redirect, errorrequests/s
web_log.status_code_class_responses1xx, 2xx, 3xx, 4xx, 5xxresponses/s
web_log.status_code_class_1xx_responsesa dimension per 1xx coderesponses/s
web_log.status_code_class_2xx_responsesa dimension per 2xx coderesponses/s
web_log.status_code_class_3xx_responsesa dimension per 3xx coderesponses/s
web_log.status_code_class_4xx_responsesa dimension per 4xx coderesponses/s
web_log.status_code_class_5xx_responsesa dimension per 5xx coderesponses/s
web_log.bandwidthreceived, sentkilobits/s
web_log.request_processing_timemin, max, avgmilliseconds
web_log.requests_processing_time_histograma dimension per bucketrequests/s
web_log.upstream_response_timemin, max, avgmilliseconds
web_log.upstream_responses_time_histograma dimension per bucketrequests/s
web_log.current_poll_uniq_clientsipv4, ipv6clients
web_log.vhost_requestsa dimension per vhostrequests/s
web_log.port_requestsa dimension per portrequests/s
web_log.scheme_requestshttp, httpsrequests/s
web_log.http_method_requestsa dimension per HTTP methodrequests/s
web_log.http_version_requestsa dimension per HTTP versionrequests/s
web_log.ip_proto_requestsipv4, ipv6requests/s
web_log.ssl_proto_requestsa dimension per SSL protocolrequests/s
web_log.ssl_cipher_suite_requestsa dimension per SSL cipher suiterequests/s
web_log.url_pattern_requestsa dimension per URL patternrequests/s
web_log.custom_field_pattern_requestsa dimension per custom field patternrequests/s

Per custom time field


This scope has no labels.


web_log.custom_time_field_summarymin, max, avgmilliseconds
web_log.custom_time_field_histograma dimension per bucketobservations

Per custom numeric field


This scope has no labels.


weblog.custom_numeric_field{{field_name}}_summarymin, max, avg{{units}}

Per URL pattern


This scope has no labels.


web_log.url_pattern_status_code_responsesa dimension per patternresponses/s
web_log.url_pattern_http_method_requestsa dimension per HTTP methodrequests/s
web_log.url_pattern_bandwidthreceived, sentkilobits/s
web_log.url_pattern_request_processing_timemin, max, avgmilliseconds


The following alerts are available:

Alert nameOn metricDescription
web_log_1m_unmatched web_log.excluded_requestspercentage of unparsed log lines over the last minute
web_log_1m_requests web_log.type_requestsratio of successful HTTP requests over the last minute (1xx, 2xx, 304, 401)
web_log_1m_redirects web_log.type_requestsratio of redirection HTTP requests over the last minute (3xx except 304)
web_log_1m_bad_requests web_log.type_requestsratio of client error HTTP requests over the last minute (4xx except 401)
web_log_1m_internal_errors web_log.type_requestsratio of server error HTTP requests over the last minute (5xx)
web_log_web_slow web_log.request_processing_timeaverage HTTP response time over the last 1 minute
web_log_5m_requests_ratio web_log.type_requestsratio of successful HTTP requests over over the last 5 minutes, compared with the previous 5 minutes



No action required.



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


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



$host ($http_host)%vName of the server which accepted a request.
$server_port%pPort of the server which accepted a request.
$scheme-Request scheme. "http" or "https".
$remote_addr%a (%h)Client address.
$request%rFull original request line. The line is "$request_method $request_uri $server_protocol".
$request_method%mRequest method. Usually "GET" or "POST".
$request_uri%UFull original request URI.
$server_protocol%HRequest protocol. Usually "HTTP/1.0", "HTTP/1.1", or "HTTP/2.0".
$status%s (%>s)Response status code.
$request_length%IBytes received from a client, including request and headers.
$bytes_sent%OBytes sent to a client, including request and headers.
$body_bytes_sent%B (%b)Bytes sent to a client, not counting the response header.
$request_time%DRequest processing time.
$upstream_response_time-Time spent on receiving the response from the upstream server.
$ssl_protocol-Protocol of an established SSL connection.
$ssl_cipher-String of ciphers used for an established SSL connection.


  • 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.
Config options
update_everyData collection frequency.1no
autodetection_retryRecheck interval in seconds. Zero means no recheck will be scheduled.0no
pathPath to the web server log file.yes
exclude_pathPath to exclude.*.gzno
url_patternsList of URL patterns.[]no
url_patterns.nameUsed as a dimension name.yes
url_patterns.patternUsed to match against full original request URI. Pattern syntax in matcher.yes
log_typeLog parser type.autono
csv_configCSV log parser
csv_config.delimiterCSV field delimiter.,no
csv_config.formatCSV log
ltsv_configLTSV log parser
ltsv_config.field_delimiterLTSV field delimiter.\tno
ltsv_config.value_delimiterLTSV value delimiter.:no
ltsv_config.mappingLTSV fields mapping to known fields.yes
json_configJSON log parser
json_config.mappingJSON fields mapping to known fields.yes
regexp_configRegExp log parser
regexp_config.patternRegExp pattern with named groups.yes

"URL pattern" scope metrics will be collected for each URL pattern.

Option syntax:

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

Weblog supports 5 different log parsers:

Parser typeDescription
autoUse CSV and auto-detect format
csvA comma-separated values
regexpRegular expression with named groups


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.


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
label1: field1
label2: field2

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
label1: field1
label2: field2

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

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


log_type: regexp
pattern: PATTERN


There are no configuration examples.


Debug Mode

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

Do you have any feedback for this page? If so, you can open a new issue on our netdata/learn repository.