Nginx Web Server Monitoring

ComponentsEngineJS ProfilerRPA Bot RecorderRUM JSRUM Extension

Availability8.6.16 or later

What Is Monitored

Requests, errors, response time

How It Works

Log monitor and parsers

Deploy

Log format and Profile

KPIs

Requests and errors

Overview

GermainUX turns every line of your Nginx access log into a request you can filter by URL, status, client and browser, with the time Nginx took to serve it. Error-log entries become events grouped by level, so a new upstream failure stands out from the usual noise. The Nginx Web Server Profile sets up collection on each host in one step, and the only change on the Nginx side is one field in the log format. Your team sees which sites and URLs are failing, slowing down or getting unusual traffic, without logging in to each server to read its logs.

Every Request, Searchable

Method, path, query string, status, size, client, referrer and browser for each request, across all your Nginx servers in one place.

Response Time per URL

The time Nginx took to serve each request, so you can trend slow URLs and compare them before and after a release.

Error-Log Events by Level

Each error, warn or crit entry becomes an event you can count, group and alert on.

One Profile for Every Host

Apply the same Profile to one host or many. GermainUX deploys the log monitor and both parsers to each host’s Engine.

Questions It Answers

Which URLs return 5xx errors right now, and since when?
Which pages got slower after the last release?
Is traffic to a site dropping or spiking compared with a normal day?
Which clients, browsers or referrers are hitting the failing URL?
What new errors appeared in the Nginx error log today?
Is every Nginx server still writing logs that GermainUX receives?

What Is Monitored

Area	What GermainUX monitors
Requests	Every access-log entry: HTTP method, path, query string, status code and response size. A request with status `400` or higher counts as failed.
Response time	The time Nginx took to serve each request, read from the `$request_time` field of the access log
Clients	Client address, authenticated user name, referrer URL, and the browser and operating system parsed from the user agent
Errors	Every error-log entry, with its level (`error`, `warn`, `crit` and so on) and message. Error categorization groups similar messages so new ones stand out.
Availability	Up/down status and response time of the URLs Nginx serves, checked on a schedule with synthetic HTTP checks
Host	CPU, memory, disk and network of the Nginx server, and whether the Nginx process is running. See Linux monitoring or Windows monitoring.
User experience	Real-user page performance, JavaScript errors and Session Replay for the websites Nginx serves, with RUM JS or the RUM Extension

Analytics, Alerts and Automation

AI Analysis

Ask AI Explore questions such as “Which Nginx URLs had the most 5xx errors this week?” and get the answer without building a report. Outlier detection flags unusual spikes or drops in request volume, errors or response time.

Dashboards and Reports

Build dashboards and reports on the Nginx KPIs: request volume and failure rate by site or URL, slowest URLs, status-code distribution, and error-log events by level. GermainUX ships the Nginx Overview dashboard as a starting point. In the left menu, go to Dashboards > All, and then open Nginx Overview in the Nginx folder. It shows requests and failed requests by server, response time, requests by status code and by site, and error-log events by level. Click a chart to open the KPI behind it.

Nginx Overview dashboard showing requests by server, failed requests by server, response time, requests by status code, requests by site and error-log events by level over one week — Nginx Overview Dashboard - GermainUX

Analysis

Click a value on the dashboard to open it in the Analysis screen. The aggregate view compares the failed requests with the previous period and the last quarter, and shows the hourly trend. The relationships chart plots HTTP Errors events next to the requests, so you can hover an error-log entry to see its message, server and application. The segmentation breakdown lists the browsers, devices, operating systems and referrer URLs that stand out among the failed requests.

The instance view explains one error-log entry. It shows how common the error is among all HTTP Errors events, when it was first and last seen, the full message, and the requests Nginx served around it.

Analysis screen for one HTTP Errors event from web-01, showing how common it is, the file, application and system, the error-log message about a missing file, and the relationships chart with inbound HTTP requests — Instance Analysis of an Nginx Error-Log Entry - GermainUX

SLAs and Alerts

Set SLAs on the failure rate, response time or error count, and get an alert by email, SMS, Slack or Teams when one is breached. An SLA on request volume tells you when a server stops sending data.

Automation

When an SLA is breached, an automated action can run a diagnostic script, call an HTTP endpoint or open an incident.

Correlation with Other Technologies

Correlate Nginx requests with the browser sessions that made them and the application servers behind Nginx, to follow a slow or failed request from the user to its cause.

How It Works

Nginx logsLog Directory MonitorParsersKPIsAlerts

The Nginx Web Server Profile deploys three components to the GermainUX Engine of each host you apply it to:

Component	What it does
Nginx Log Directory Monitor	Watches the log directory for `.log` files as Nginx writes them. Sends files whose names contain `access` to the access log parser, and files whose names contain `error` to the error log parser.
Nginx Access Log Parser	Reads each access-log line and stores it as an Inbound HTTP Request transaction named `Nginx HTTP`, with the request, client and response time fields
Nginx Error Log Parser	Reads each error-log line and stores it as an HTTP Errors event. The event name is the log level, and the details hold the message.

The Engine reads the log files directly, so it runs on the Nginx host or on a server that can read the log directory. See File and Log Monitoring for how GermainUX reads log files.

Before You Start

A GermainUX Engine is deployed and assigned to the Nginx host. See GermainUX Engine and Assign an Engine.
The Engine’s account can read the Nginx log directory, for example /var/log/nginx.
You can edit the Nginx configuration and reload Nginx.
The access and error logs are in the same directory, with names that contain access and error and end in .log. The Nginx defaults, access.log and error.log, work.

Deploy

Add the request time to the access log

In the http block of your Nginx configuration, define a log format that adds $request_time to the end of the standard combined format, and use it for the access log:

nginx.conf

log_format germainux '$remote_addr - $remote_user [$time_local] '
                     '"$request" $status $body_bytes_sent '
                     '"$http_referer" "$http_user_agent" '
                     '$request_time';

access_log /var/log/nginx/access.log germainux;

If a server block has its own access_log line, add germainux to that line too. Then, as root, check the configuration and reload Nginx:

nginx -t && nginx -s reload

Open the Nginx Web Server wizard

In the left menu, go to Settings > Wizards. On the Nginx Web Server card, click Add.

Wizards screen showing the Nginx Web Server card with its Add and Manage buttons — Nginx Web Server Card on the Wizards Screen - GermainUX

Select the Nginx hosts

In Servers, select one or more Nginx hosts, and then click Apply.

Apply Nginx Web Server dialog with one host selected in the Servers field and the Apply button below — Apply Nginx Web Server Dialog - GermainUX

Enter the Profile settings

Fill in the fields, and then finish the wizard.

Field	Value
Application	The application the Nginx data belongs to. The default is `Nginx Web Server`. Select another application to keep each site’s data apart.
Access Log Directory	The directory that holds the Nginx logs, for example `/var/log/nginx`. Select an existing file path, or create one. The monitor reads both the access and error logs from this directory.

GermainUX deploys the log directory monitor and both parsers to the Engine of each selected host, and starts reading the logs.

You can also apply the Profile from Settings > Data Sources, on the Hosts tab. To change the settings later, reapply the Profile. See Profiles.

Validate

Check that the Profile is deployed

In the left menu, go to Settings > Wizards. On the Nginx Web Server card, click Manage to see the Engines that run the Profile.

Send a test request

From any machine that can reach the Nginx server, request a page and a path that doesn’t exist:

curl -s -o /dev/null -w "%{http_code}\n" http://NGINX_HOST/
curl -s -o /dev/null -w "%{http_code}\n" http://NGINX_HOST/germainux-test-missing

Replace NGINX_HOST with the host name of the Nginx server. The first request returns 200, and the second returns 404.

Find the requests in GermainUX

In GermainUX Workspace, open the Inbound HTTP Request KPI and look for Nginx HTTP requests to / and /germainux-test-missing. Check that each one shows its status and response time, and that the 404 request counts as failed.

Find the error-log event

When Nginx serves files from disk, it writes the missing file to its error log. Open the HTTP Errors KPI and look for an error event whose details mention germainux-test-missing.

Troubleshooting

No Nginx requests appear

Click Manage on the Nginx Web Server card and check that the host’s Engine runs the Profile. Then check that the Engine’s account can read the log directory, and that the access log’s file name contains access and ends in .log. A log named shop.log, for example, is not picked up. Rename it to shop-access.log in the access_log line.

Requests appear without a response time

The access log doesn’t include $request_time. Check that every access_log line, including the ones inside server blocks, uses the germainux format, and that you reloaded Nginx.

Some access-log lines are missing

GermainUX skips lines that don’t match the expected format. This happens when a server block writes the access log with a different log_format. Use the germainux format for every access log in the monitored directory.

No error-log events appear

Check that the error log is in the same directory as the access log, and that its file name contains error and ends in .log. Also check the level on the error_log line. With error_log /var/log/nginx/error.log crit;, for example, Nginx writes only critical entries.

Security and Privacy

Nginx monitoring data includes personal data:

Identity data: the client address and the authenticated user name of each request
URLs: the request path, query string and referrer URL. Query strings can contain email addresses, IDs or tokens.
Device data: the user agent, and the browser and operating system parsed from it
Free text: error-log messages, which often include the client address, request line and server name. They contain whatever Nginx writes into them, so treat them as possibly containing personal or customer data.

To mask, anonymize or exclude this data, see Data Privacy.

KPIs

KPI	What it holds	Data model
Inbound HTTP Request	One transaction per access-log line, named `Nginx HTTP`, with the request, client and response time	`InboundHttpRequest`
HTTP Errors	One event per error-log line, named after its level, with the message in the details	`GenericEvent`

GermainUX uses these shared KPIs for other web servers too. The Nginx HTTP name tells the Nginx requests apart. Neither KPI has a default SLA. Add the thresholds you need. See KPIs and SLAs.

Profiles

Apply, reapply and disable Profiles

File and Log Monitoring

How GermainUX reads log files

Automation

More Automation Features

Get Help

The GermainUX team can help you monitor Nginx servers that use a custom log format, or split the data by site.

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't Find What You Need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.

What Is Monitored

How It Works

Deploy

KPIs

Overview

Every Request, Searchable

Response Time per URL

Error-Log Events by Level

One Profile for Every Host

Questions It Answers

What Is Monitored

Analytics, Alerts and Automation

AI Analysis

Dashboards and Reports

Analysis

SLAs and Alerts

Automation

Correlation with Other Technologies

How It Works

Before You Start

Deploy

Validate

Troubleshooting

Security and Privacy

KPIs

Related Documentation

Profiles

File and Log Monitoring

Automation

Get Help

Contact GermainUX Support

Can't Find What You Need?