You can find here the list of common alerts triggered by NewRelic and how to resolve them.
Looking at the server by itself is usually not enough to understand the root cause of the issue, so it needs to be correlated to other events on the application side.
Memory Alert
Here, we have an alert on Memory usage on one of our servers, this is a non-critical alert but we will make sure no action is needed.
From the Apps section, we can see that this is coming from MnoHub.
Drilling down to processes helps us see what is going on
Everything looks fine, but to ensure business services are not impacted, we are going back to APM
All good.
APDEX Alert
The APDEX score is based on the application response time, when the application performs slowly, an alert is raised.
Clicking through the Application link (Application: Connec API) an overview of the application is displayed for the time window where the alert occurred. Digging into the Transactions section, the slowest transactions will be listed.
From there an investigation will have to be lead to find the root cause of the performance issue and address the underlying problem.
See https://maestrano.atlassian.net/wiki/x/gOTgBQ
Error Rate
When an application throws too many errors, an alert is raised. Following the alert link gives information about the Error rate over the time period.
Displaying the Events > Errors section gives a break down of the errors grouped by error message. Clicking on the message name will display the ruby trace to help troubleshoot the error.
It is recommended handling errors in the application code and return error statuses rather bubbling up the entire stack trace.
Note that a public endpoint will always be pinged by crawlers trying to find vulnerabilities and executable scripts. These types of requests should be blocked at the web server (nginx) level to avoid NewRelic raising 404 errors.