Collecting Nginx Access and Error Logs with Filebeat, Logstash, and rsyslog into Elasticsearch

Nginx is widely used as a high‑performance web and reverse‑proxy server, and its access and error logs are valuable for user behavior analysis and security monitoring; the article demonstrates three ways to collect these logs and ship them to Elasticsearch for further processing.

By default Nginx stores logs in /usr/local/nginx/logs as access.log and error.log . The examples assume an Elasticsearch cluster of three nodes (172.28.65.22, .23, .24) and a Kibana instance at 172.28.65.30.

1. Directly send logs from Filebeat to Elasticsearch

Configure filebeat.yml to read the log files and output them to Elasticsearch:

- type: log
  # Change to true to enable this input configuration.
  enabled: true
  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /usr/local/nginx/logs/*.log

Set the Elasticsearch hosts in the output.elasticsearch section, start Filebeat with ./filebeat -e -c filebeat.yml -d "publish" , and verify the data in Kibana using the filebeat-* index pattern.

2. Send logs from Filebeat to Logstash, then to Elasticsearch

Create a Logstash pipeline ( filebeat-pipeline.conf ) that receives beats on port 5044 and forwards them to Elasticsearch:

input {
  beats {
    port => "5044"
  }
}
output {
  elasticsearch { hosts => ["172.28.65.24:9200"] }
  stdout { codec => rubydebug }
}

Disable the output.elasticsearch section in filebeat.yml and enable output.logstash with the Logstash host and port, then restart Filebeat. Logs appear both in Logstash’s console and in Elasticsearch.

3. Use rsyslog to forward Nginx logs to Logstash, then to Elasticsearch

Option A – configure Nginx to send logs via syslog:

access_log syslog:server=172.28.65.32:514,facility=local7,tag=nginx_access_log,severity=info;
error_log syslog:server=172.28.65.32:514,facility=local7,tag=nginx_error_log,severity=info;

Reload Nginx ( ./nginx -s reload ) and set up a Logstash syslog pipeline ( syslog-pipeline.conf ) that listens on port 514 and outputs to Elasticsearch:

input {
  syslog {
    type => "system-syslog"
    port => 514
  }
}
output {
  elasticsearch { hosts => ["172.28.65.24:9200"] index => "system-syslog-%{+YYYY.MM}" }
  stdout { codec => rubydebug }
}

Option B – if Nginx cannot emit syslog, configure rsyslog to monitor the log files and forward them:

$IncludeConfig /etc/rsyslog.d/*.conf

# /etc/rsyslog.d/nginx-log.conf
$ModLoad imfile
$InputFilePollInterval 1
$WorkDirectory /var/spool/rsyslog
$PrivDropToGroup adm

$InputFileName /usr/local/nginx/logs/access.log
$InputFileTag nginx-access:
$InputFileStateFile stat-nginx-access
$InputFileSeverity info
$InputRunFileMonitor

$InputFileName /usr/local/nginx/logs/error.log
$InputFileTag nginx-error:
$InputFileStateFile stat-nginx-error
$InputFileSeverity error
$InputRunFileMonitor

*.* @172.28.65.32:514

Restart rsyslog ( systemctl restart rsyslog ); the logs will be received by Logstash and indexed in Elasticsearch, where they can be visualized in Kibana.

The article concludes that depending on the environment, any of these three pipelines—Filebeat → ES, Filebeat → Logstash → ES, or rsyslog → Logstash → ES—can be chosen to reliably collect Nginx logs for analysis.