> ## Documentation Index > Fetch the complete documentation index at: https://docs.germainux.com/llms.txt > Use this file to discover all available pages before exploring further. # Nginx Web Server Monitoring > See which Nginx URLs fail, slow down or spike in traffic, and catch new error-log entries before users report them. Components [`Engine`](https://docs.germainux.com/deploy/germain-ux-engine) [`JS Profiler`](https://docs.germainux.com/deploy/germain-ux-js-profiler) [`RPA Bot Recorder`](https://docs.germainux.com/deploy/germain-ux-rpa-bot-recorder) [`RUM JS`](https://docs.germainux.com/deploy/germain-ux-rum-js) [`RUM Extension`](https://docs.germainux.com/deploy/germain-ux-rum-extension) Availability 8.6.16 or later > [card] [What Is Monitored](#what-is-monitored) > > Requests, errors, response time > [card] [How It Works](#how-it-works) > > Log monitor and parsers > [card] [Deploy](#deploy) > > Log format and Profile > [card] [KPIs](#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. > [card] Every Request, Searchable > > Method, path, query string, status, size, client, referrer and browser for each request, across all your Nginx servers in one place. > [card] 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. > [card] Error-Log Events by Level > > Each `error`, `warn` or `crit` entry becomes an event you can count, group and alert on. > [card] 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](https://docs.germainux.com/analytics/data-categorization.md) 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](https://docs.germainux.com/automation/synthetic-http-execution.md) | | **Host** | CPU, memory, disk and network of the Nginx server, and whether the Nginx process is running. See [Linux monitoring](https://docs.germainux.com/integrations/linux-redhat-suse-monitoring.md) or [Windows monitoring](https://docs.germainux.com/integrations/windows-monitoring.md). | | **User experience** | Real-user page performance, JavaScript errors and Session Replay for the websites Nginx serves, with [RUM JS](https://docs.germainux.com/deploy/germain-ux-rum-js.md) or the [RUM Extension](https://docs.germainux.com/deploy/germain-ux-rum-extension.md) | ## Analytics, Alerts and Automation ### AI Analysis Ask [AI Explore](https://docs.germainux.com/analytics/ai-driven-insights.md) questions such as "Which Nginx URLs had the most 5xx errors this week?" and get the answer without building a report. [Outlier detection](https://docs.germainux.com/analytics/outlier-detection.md) flags unusual spikes or drops in request volume, errors or response time. ### Dashboards and Reports Build [dashboards and reports](https://docs.germainux.com/dashboards/dashboard-and-report.md) 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](https://mintcdn.com/germain-ux/PNt8xru37fzvIoN1/images/main/nginx-monitoring/nginx-overview-dashboard.png?fit=max\&auto=format\&n=PNt8xru37fzvIoN1\&q=85\&s=7f00b824b91bd0773265e80fbbfe2b49) Nginx Overview Dashboard - GermainUX ### Analysis Click a value on the dashboard to open it in the [Analysis](https://docs.germainux.com/dashboards/analytics-dashboard/4-analysis-dashboard.md) 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. ![Analysis screen for failed requests on web-01, with the overall count, hourly trend, an HTTP Errors event open in the relationships chart, and the segmentation breakdown by browser, device, operating system and referrer URL](https://mintcdn.com/germain-ux/PNt8xru37fzvIoN1/images/main/nginx-monitoring/nginx-failed-requests-aggregate-analysis.png?fit=max\&auto=format\&n=PNt8xru37fzvIoN1\&q=85\&s=bf735432469bdaec12e8f1a4068a87df) Aggregate Analysis of Failed Nginx Requests - GermainUX 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](https://mintcdn.com/germain-ux/PNt8xru37fzvIoN1/images/main/nginx-monitoring/nginx-http-error-instance-analysis.png?fit=max\&auto=format\&n=PNt8xru37fzvIoN1\&q=85\&s=4914409db002f27e10b29cd095ae6f2e) Instance Analysis of an Nginx Error-Log Entry - GermainUX ### SLAs and Alerts Set [SLAs](https://docs.germainux.com/analytics/slas.md) on the failure rate, response time or error count, and get an [alert](https://docs.germainux.com/automation/notifications.md) 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](https://docs.germainux.com/automation/automated-actions.md) can run a diagnostic script, call an HTTP endpoint or open an incident. ### Correlation with Other Technologies [Correlate](https://docs.germainux.com/analytics/correlation-and-tracing.md) 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 logs Log Directory Monitor Parsers KPIs Alerts 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](https://docs.germainux.com/integrations/file-log-monitoring.md) for how GermainUX reads log files. ## Before You Start * A GermainUX Engine is deployed and assigned to the Nginx host. See [GermainUX Engine](https://docs.germainux.com/deploy/germain-ux-engine.md) and [Assign an Engine](https://docs.germainux.com/management/profiles-to-deploy-at-scale.md#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 **1. 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 nginx.conf theme={null} 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: ```bash theme={null} nginx -t && nginx -s reload ``` **2. 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](https://mintcdn.com/germain-ux/PNt8xru37fzvIoN1/images/main/nginx-monitoring/nginx-web-server-wizard-card.png?fit=max\&auto=format\&n=PNt8xru37fzvIoN1\&q=85\&s=86f35e8631b85fe3acae4e84cec422bf) Nginx Web Server Card on the Wizards Screen - GermainUX **3. 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](https://mintcdn.com/germain-ux/PNt8xru37fzvIoN1/images/main/nginx-monitoring/nginx-web-server-apply-servers.png?fit=max\&auto=format\&n=PNt8xru37fzvIoN1\&q=85\&s=f62ba508b7fd0685d9ea2e6bd49e5791) Apply Nginx Web Server Dialog - GermainUX **4. 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](https://docs.germainux.com/management/profiles-to-deploy-at-scale.md). ## Validate **1. 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. **2. Send a test request** From any machine that can reach the Nginx server, request a page and a path that doesn't exist: ```bash theme={null} 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`. **3. 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. **4. 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 > [accordion] 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. > [accordion] 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. > [accordion] 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. > [accordion] 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](https://docs.germainux.com/management/compliance-privacy-and-security/data-privacy.md). ## 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](https://docs.germainux.com/analytics/kpis.md) and [SLAs](https://docs.germainux.com/analytics/slas.md). ## Related Documentation > [card] [Profiles](https://docs.germainux.com/management/profiles-to-deploy-at-scale.md) > > Apply, reapply and disable Profiles > [card] [File and Log Monitoring](https://docs.germainux.com/integrations/file-log-monitoring.md) > > How GermainUX reads log files > [card] [Automation](https://docs.germainux.com/automation.md) > > 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. > [card] [Contact GermainUX Support](https://docs.germainux.com/getting-started/support.md) > > 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. > [card] 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.