Troubleshooting Metrics Collection
Learn what to check if the NGINX Amplify Agent isn’t reporting metrics.
After you install and start the agent, it should start reporting right away, pushing aggregated data to the Amplify backend at regular 1 minute intervals. It’ll take about a minute for a new system to appear in the Amplify web interface.
If you don’t see the new system or NGINX instance in the web interface, or (some) metrics aren’t being collected, please review the following:
- The Amplify Agent package has been successfully installed, and no warnings were reported during the installation.
amplify-agentprocess is running and updating its log file.
- The agent is running under the same user as your NGINX worker processes.
- The NGINX instance is started with an absolute path. The agent can’t detect NGINX instances launched with a relative path (e.g. “./nginx”).
- The user ID that is used by the agent and the NGINX instance, can run
ps(1)to see all system processes. If
ps(1)is restricted for non-privileged users, the agent won’t be able to find and properly detect the NGINX master process.
- The time is set correctly. If the time on the system where the agent runs is ahead or behind the world’s clock, you won’t be able to see the graphs.
stub_statusis configured correctly, and the
stub_status moduleis included in the NGINX build (this can be confirmed with
- NGINX access.log and error.log files are readable by the user
nginx(or by the user set in NGINX config).
- All NGINX configuration files are readable by the agent user ID (check owner, group, and permissions).
- Extra configuration steps have been performed as required for the additional metrics to be collected.
- The system DNS resolver is correctly configured, and receiver.amplify.nginx.com can be successfully resolved.
- Outbound TLS/SSL from the system to receiver.amplify.nginx.com is not restricted. This can be confirmed with
curl(1). Configure a proxy server for the agent if required.
- selinux(8), apparmor(7) or grsecurity are not interfering with the metric collection. E.g., for selinux(8)* review /etc/selinux/config. Try
setenforce 0temporarily and see if it improves the situation for certain metrics.
- Some VPS providers use hardened Linux kernels that may restrict non-root users from accessing /proc and /sys. Metrics describing system and NGINX disk I/O are usually affected. There is no easy workaround except for allowing the agent to run as
root. Sometimes fixing permissions for /proc and /sys/block may work.