Monitoring a PaaS Environment: Where NGINX Amplify, New Relic APM, the Platform's Statistics and Load Alerts Each Fit

Monitoring questions come in layers. Is the container running out of memory? Is the load balancer returning errors? Is the application slow, and in which function? Has anything just crossed a threshold? No single tool answers all four well, and the platform plus two marketplace add-ons cover them without a monitoring server to run. This post follows an SRE building that stack for a PHP cluster on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The cluster serves a ticketing marketplace for a company we will call Pennant Events: an NGINX load balancer, four NGINX PHP application servers, a MariaDB cluster and Redis. The add-ons are NGINX Amplify for the NGINX layers and New Relic APM for the PHP layer, alongside the platform's built-in statistics and load alerts.

Layer one: what the platform already records

Every container's statistics are collected every minute: RAM in MiB, CPU in MHz, network in and out, disk space and IOPS, against the limits set by the cloudlets. The dashboard shows them per node or per layer for the last hour at minute resolution and hourly afterwards, because that is also how pay-per-use billing is computed. This layer answers the resource questions: is the PHP layer at its cloudlet ceiling, is MariaDB's IOPS graph touching the provider's red line, did the Redis node's memory step up last Tuesday. The SRE checks it first in any incident because it is the one view that cannot be wrong about what the containers consumed.

Layer four first: alerts, because they wake you

The platform's load alerts are triggers on those statistics: a resource above or below a percentage for a period, per node or layer, with an email and a notification frequency. Each container gets defaults at creation. The SRE tunes them for Pennant (RAM or CPU over 80% for ten minutes on any layer, disk over 85%, network out over a threshold that would mean a scraping incident) and forwards them to the operations channel with the Load Alerts to Slack package. Alerts are layer four in the question list but the first thing to set up, because they are what turns the other three from dashboards into a monitoring system.

Layer two: NGINX Amplify for the balancer and the PHP front ends

The platform's statistics show that the balancer is busy; they do not show what it is doing. The NGINX Amplify add-on installs the Amplify agent on every NGINX node in a layer, enables stub_status, extends the log format so latency and error metrics can be computed, and registers the nodes with the SRE's free Amplify account. Within minutes the account shows requests per second, active connections, response codes by class, upstream response times and upstream health, per node and aggregated, plus a static analysis of the NGINX configuration that flags weak settings. New nodes added by scaling register themselves.

The agent works on NGINX only, so it covers the balancer and the NGINX PHP layer but not LiteSpeed or Apache stacks. Metrics and configuration metadata are sent to F5's service; request bodies and content are not, which the SRE confirmed against the company's data-handling policy before enabling it. For Pennant, Amplify is the layer that answered "why did the error rate spike at 19:02": a 502 burst from one upstream whose PHP-FPM pool was saturated.

Layer three: New Relic APM for the code

Knowing an upstream was slow is not knowing why. The New Relic APM add-on installs the PHP agent on every node of the application layer (the Java agent for Tomcat, TomEE, WildFly, GlassFish or Spring Boot layers), sets the licence key and application name, and restarts the servers one at a time so the agent activates without downtime; scaled nodes receive it automatically. In the SRE's New Relic account, the application appears with transaction traces, the slowest database queries with their SQL, error rates by endpoint and throughput. The 19:02 spike became a specific story: a checkout endpoint running an unindexed query against the orders table when a promotion was announced. Agents add low single-digit percent CPU overhead, tunable by sampling and by disabling instrumentation you do not need.

How the four fit together in an incident

1. Alert in the channel: PHP layer CPU above 80% for ten minutes.
2. Statistics: the layer is at its cloudlet ceiling; MariaDB CPU is also elevated. Vertical scaling has given all it was allowed.
3. Amplify: request rate is three times normal, response codes fine, upstream latency rising; it is load, not an outage.
4. New Relic: the load is concentrated on one endpoint whose query lacks an index.
5. Fix: add the index on a clone, confirm the query plan, deploy the migration; raise the PHP layer's cloudlet ceiling for the promotion period. The alert clears.

Each tool answered exactly one question, and none of them would have been enough alone.

What the SRE did not build

No Prometheus, no Grafana, no log shipper, no monitoring server to patch. The two add-ons send to hosted services with free tiers that cover Pennant's size; the platform's own statistics and alerts are part of the environment. When Pennant grows past the free tiers, or wants metrics kept in its own region for policy reasons, the SRE's plan is a Prometheus and Grafana pair on the platform scraping the NGINX status endpoints and the application's own metrics, which the Kubernetes package includes as an option and which any environment can host. Until then, four questions, four answers, nothing to run.

Frequently Asked Questions

Does NGINX Amplify work with LiteSpeed or Apache layers?

No. Amplify monitors NGINX only, on the NGINX load balancer and NGINX PHP application server layers. For LiteSpeed, use its built-in WebAdmin statistics; for Apache, mod_status with an external scraper.

Which runtimes does the New Relic add-on support?

Java application servers (Tomcat, TomEE, WildFly, GlassFish, Spring Boot on Java Engine) and PHP application servers (Apache PHP, NGINX PHP). Other runtimes can use New Relic's agents installed by hand or the platform's custom Docker containers with the agent baked in.

Can I keep all monitoring data inside my own region?

The platform's statistics and alerts stay on the platform. Amplify and New Relic send metrics to their vendors' services. If policy forbids that, host Prometheus and Grafana on the platform instead and scrape the NGINX status and application metrics endpoints over the internal network.