anchor.diff:  
       ./prometheus-nginxlog-exporter -config-file /path/to/config.hcl
   
  -== Collected metrics
  -
  -This exporter collects the following metrics. This collector can listen on
  -multiple log files at once and publish metrics in different namespaces. Each
  -metric uses the labels `method` (containing the HTTP request method) and
  -`status` (containing the HTTP status code).
  -
  -[IMPORTANT]
  -====
  -Keep in mind that some of these metrics will require certain values to be present
  -in your access log format (for example, the `http_upstream_time_seconds` metric
  -will require your access to contain the variable `$upstream_response_time`.
  -====
  -
  -Metrics are exported at the `/metrics` path.
  -
  -These metrics are exported:
  -
  -|===
  -| `<namespace>_http_response_count_total` | The total amount of processed HTTP requests/responses.
  -| `<namespace>_http_response_size_bytes` | The total amount of transferred content in bytes.
  -| `<namespace>_http_upstream_time_seconds` | A summary vector of the upstream response times in seconds. Logging these needs to be specifically enabled in NGINX using the `$upstream_response_time` variable in the log format.
  -| `<namespace>_http_upstream_time_seconds_hist` | Same as `<namespace>_http_upstream_time_seconds`, but as a histogram vector. Also requires the `$upstream_response_time` variable in the log format.
  -| `<namespace>_http_response_time_seconds` | A summary vector of the total response times in seconds. Logging these needs to be specifically enabled in NGINX using the `$request_time` variable in the log format.
  -| `<namespace>_http_response_time_seconds_hist` | Same as `<namespace>_http_response_time_seconds`, but as a histogram vector. Also requires the `$request_time` variable in the log format.
  -|===
  -
  -Additional labels can be configured in the configuration file (see below).
  -
  -== Configuration file
  -
  -You can specify a configuration file to read at startup. The configuration file
  -is expected to be either in https://github.com/hashicorp/hcl[HCL] or YAML format. Here's an example file:
  -
  -[source,hcl]
  -----
  -listen {
  -  port = 4040
  -  address = "10.1.2.3"
  -  metrics_endpoint = "/metrics"
  -}
  -
  -consul {
  -  enable = true
  -  address = "localhost:8500"
  -  datacenter = "dc1"
  -  scheme = "http"
  -  token = ""
  -  service {
  -    id = "nginx-exporter"
  -    name = "nginx-exporter"
  -    address = "192.168.3.1"
  -    tags = ["foo", "bar"]
  -  }
  -}
  -
  -namespace "app1" {
  -  format = "$remote_addr - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" \"$http_x_forwarded_for\""
  -  source {
  -    files = [
  -      "/var/log/nginx/app1/access.log"
  -    ]
  -  }
  -  labels {
  -    app = "application-one"
  -    environment = "production"
  -    foo = "bar"
  -  }
  -
  -  histogram_buckets = [.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10]
  -}
  -
  -namespace "app2" {
  -  format = "$remote_addr - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" \"$http_x_forwarded_for\" $upstream_response_time"
  -  source {
  -    files = [
  -      "/var/log/nginx/app2/access.log"
  -    ]
  -  }
  -}
  -----
  -
  -The same file as YAML file:
  -
  -[source,yaml]
  -----
  -listen:
  -  port: 4040
  -  address: "10.1.2.3"
  -  metrics_endpoint: "/metrics"
  -
  -consul:
  -  enable: true
  -  address: "localhost:8500"
  -  datacenter: dc1
  -  scheme: http
  -  token: ""
  -  service:
  -    id: "nginx-exporter"
  -    name: "nginx-exporter"
  -    address = "192.168.3.1"
  -    tags: ["foo", "bar"]
  -
  -namespaces:
  -  - name: app1
  -    format: "$remote_addr - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" \"$http_x_forwarded_for\""
  -    source:
  -      files:
  -        - /var/log/nginx/app1/access.log
  -    labels:
  -      app: "application-one"
  -      environment: "production"
  -      foo: "bar"
  -    histogram_buckets: [.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10]
  -  - name: app2
  -    format: "$remote_addr - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" \"$http_x_forwarded_for\" $upstream_response_time"
  -    source:
  -      files:
  -        - /var/log/nginx/app2/access.log
  -----
  -
  -Advanced features
  ------------------
  -
  -### Log sources
  -
  -Currently, the exporter supports reading log data from
  -
  -1. files
  -2. syslog
  -
  -All log sources can be configured on a per-namespace basis using the `source` property.
  -
  -#### Reading from files
  -
  -When reading from log files, all that is needed is a `files` property:
  -
  -```hcl
  -namespace "test" {
  -  source {
  -    files = ["/var/log/nginx/access.log"]
  -    // ...
  -  }
  -}
  -```
  -
  -#### Reading from syslog
  -
  -The exporter can also open and listen on a Syslog port and read logs from there. Configuration works as follows:
  -
  -[source,hcl]
  -----
  -namespace "test" {
  -  source {
  -    syslog {
  -      listen_address = "udp://127.0.0.1:8514" <1>
  -      format = "rfc3164" <2>
  -      tags = ["nginx"]
  -    }
  -
  -    // ...
  -  }
  -}
  -----
  -<1> The `listen_address` might be either a TCP or UDP address. UNIX sockets are not supported (yet -- pull requests are welcome)
  -<2> The `format` may be one of `rfc3164`, `rfc5424`, `rfc6587` or `auto`. If omitted, it will default to `auto`.
  -
  -Have a look at http://nginx.org/en/docs/syslog.html[the respective section of the NGINX documentation] on how to set up NGINX to log into syslog.
  -
  -Experimental features
  ----------------------
  -
  -The exporter contains features that are currently experimental and may change without prior notice.
  -To use these features, either set the `-enable-experimental` flag or add a `enable_experimental`
  -option to your configuration file (on the root of the configuration file document, like
  -`enable_experimental: true` in YAML or `enable_experimental = true` in HCL).
  -
  -### Dynamic re-labeling
  -
  -Re-labeling lets you add arbitrary fields from the parsed log line as labels to your metrics.
  -To add a dynamic label, add a `relabel` statement to your configuration file:
  -
  -[source,hcl]
  -----
  -namespace "app-1" {
  -  // ...
  -
  -  relabel "host" {
  -    from = "server_name"
  -    whitelist = [ <1>
  -      "host-a.com",
  -      "host-b.de"
  -    ]
  -  }
  -}
  -----
  -<1> The `whitelist` property is optional; if set, only the supplied values will be added as label.
  -All other values will be subsumed under the `"other"` label value. See #16 for a more detailed
  -discussion around the reasoning.
  -
  -Dynamic relabeling also allows you to aggregate your metrics by request path (which replaces
  -the experimental feature originally introduced in #23). The following example splits the content of
  -the `request` variable at every space (using `split`) and return the second element (index 1) of the
  -resulting list which is the base for the regex):
  -
  -[source,hcl]
  -----
  -namespace "app1" {
  -  // ...
  -
  -  relabel "request_uri" {
  -    from = "request"
  -    split = 2
  -
  -    match "^/users/[0-9]+" {
  -      replacement = "/users/:id"
  -    }
  -
  -    match "^/profile" {
  -      replacement = "/profile"
  -    }
  -  }
  -}
  -----
  -
  -The YAML configuration for relabelings works similar to the HCL configuration:
  -
  -[source,yaml]
  -----
  -namespaces:
  -- name: app1
  -  relabel_configs:
  -  - target_label: request_uri
  -    from: request
  -    split: 2
  -    matches:
  -    - regexp: "^/users/[0-9]+"
  -      replacement: "/users/:id"
  -----
  -
  -If your regular expression contains groups, you can also use the matched values of those in the `replacement` value:
  -
  -[source,hcl]
  -----
  -relabel "request_uri" {
  -  from = "request"
  -  split = 2
  -  
  -  match "^/(users|profiles)/[0-9]+" {
  -    replacement = "/$1/:id"
  -  }
  -}
  -----
  -
  -Installing & running the collector
  -----------------------------------
  -
  -### DEB/RPM packages
  -
  -In the https://github.com/martin-helmich/prometheus-nginxlog-exporter/releases[releases section],
  -you can find both DEB and RPM packages for download. These come with a dependency on systemd and
  -configure the exporter to be running automatically:
  -
  -    $ wget https://github.com/martin-helmich/prometheus-nginxlog-exporter/releases/download/v1.5.0/prometheus-nginxlog-exporter_v1.5.0_linux_amd64.deb
  -    $ apt install ./prometheus-nginxlog-exporter_v1.5.0_linux_amd64.deb
  -
  -The packages drop a configuration file to `/etc/prometheus-nginxlog-exporter.hcl` which you can
  -adjust to your own needs.
  +Installation
  +------------
  +
  +There are multiple ways to install this exporter.
  +
  +=== Docker
  +
  +Docker images for this exporter are available at the quay.io and pkg.github.com
  +registries:
  +
  +  - `quay.io/martinhelmich/prometheus-nginxlog-exporter:v1`
  +  - `docker.pkg.github.com/martin-helmich/prometheus-nginxlog-exporter/exporter:v1`
  +
  +Have a look at the https://github.com/martin-helmich/prometheus-nginxlog-exporter/releases[releases page]
  +to see the available versions and how to pull their images. In general, I would
  +recommend using the `v1` tag instead of `latest`.
  +
  +Run the exporter as follows (adjust paths like `/path/to/logs` and
  +`/path/to/config` to your own needs):
  +
  +    $ docker run --name nginx-exporter -v /path/to/logs:/mnt/nginxlogs -p 4040:4040 quay.io/martinhelmich/prometheus-nginxlog-exporter mnt/nginxlogs/access.log
  +
  +Command-line flags and arguments can simply be appended to the `docker run` command, for example to use a
  +configuration file:
  +
  +    $ docker run --name nginx-exporter -p 4040:4040 -v /path/to/logs:/mnt/nginxlogs -v /path/to/config.hcl:/etc/prometheus-nginxlog-exporter.hcl quay.io/martinhelmich/prometheus-nginxlog-exporter -config-file /etc/prometheus-nginxlog-exporter.hcl
  +
  +=== DEB and RPM packages
  +
  +Each https://github.com/martin-helmich/prometheus-nginxlog-exporter/releases[release]
  +from 1.5.1 or newer provides both DEB and RPM packages.
  +
  +    $ wget https://github.com/martin-helmich/prometheus-nginxlog-exporter/releases/download/v1.6.0/prometheus-nginxlog-exporter_1.6.0_linux_amd64.deb
  +    $ apt install prometheus-nginxlog-exporter_1.6.0_linux_amd64.deb
  +
  +The package come with a dependency on systemd and configure the exporter to be
  +running automatically:
  +
  +    $ systemctl status prometheus-nginxlog-exporter
  +    $ # systemctl disable prometheus-nginxlog-exporter
  +    $ # systemctl enable prometheus-nginxlog-exporter
  +
  +The packages drop a configuration file to `/etc/prometheus-nginxlog-exporter.hcl`
  +which you can adjust to your own needs.
   
   ### Manual installation, with systemd
   
  -If you do not want to use one of the pre-built packages, you can download the binary itself and
  -manually configure systemd to start it. You can find an example unit file for this service
  +If you do not want to use one of the pre-built packages, you can download the
  +binary itself and manually configure systemd to start it. You can find an
  +example unit file for this service
   https://github.com/martin-helmich/prometheus-nginxlog-exporter/blob/master/res/package/prometheus-nginxlog-exporter.service[in this repository].
   Simply copy the unit file to `/etc/systemd/system`:
   
  
positive.code:         name: exporter-config
  ----
  
  In this example, the configuration file is passed via the `exporter-config` ConfigMap. This might look like follows:
  
  [source,yaml]
  ----
  
negative.code:     $ systemctl enable prometheus-nginxlog-exporter
      $ systemctl start prometheus-nginxlog-exporter
  
  The shipped unit file expects the binary to be located in
  `/usr/sbin/prometheus-nginxlog-exporter` (if you sideload the exporter without
  using your package manager, you might want to put it to `/usr/local`, instead)
  and the configuration file in `/etc/prometheus-nginxlog-exporter.hcl`. Adjust
  to your own needs.
  
  ### Kubernetes
  
  If you run a logfile-generating service (be it NGINX, or anything that generates
  similar access log files) in Kubernetes, you can run the exporter as a sidecar
  along your "main" container within the same pod.
  
  The following example shows you how to deploy the exporter as a sidecar,
  accepting logs from the main container via syslog:
  
  [source,yaml]
  ----
  