Anatomía de una alerta

What are alerts in New Relic?

Alerts in New Relic are a crucial tool that allows you to keep control over the status of your application. This system is designed to notify you when something goes wrong, allowing detailed configurations for effective monitoring. With New Relic, you will be able to anticipate problems before they grow and affect the end-user experience.

How are alerts structured?

An alert in New Relic is managed through a policy. This policy acts as a container to manage one or more alerts, which facilitates the organization and management of monitoring. Policies are composed of two main elements:

• Conditions: These are the rules that trigger alerts. These conditions can monitor metrics and define thresholds that, when crossed, generate an issue. For example, if your application executes less than 10 transactions per hour, you can configure it to notify you, allowing you to take corrective measures.

• Notification channels: These are the means by which you will be notified of an issue. It can be by email, Slack messages, mobile notifications, among others.

What are the types of incident preferences?

New Relic offers different types of incident preferences that determine how often and how you are notified. Choosing the right preference is key to efficient incident management. Here are the three main types:

1. Per Policy: This is the default type. An incident is opened for the entire policy, which allows you to combine related violations into a single report. This can be advantageous, as several issues can be included in a single email, saving you time and giving you a consolidated view of the issues.

2. Per Condition: Here an incident is opened for each condition within the policy. This is useful when monitoring entities that perform the same task, for example, several hosts running the same application. Multiple incidents can be generated grouped into a single problem.

   Example: If CPU utilization exceeds 50% on any host in a cluster called 'cluster ABC', several individual alerts will be raised, which will be grouped into a single problem for notification.

3. Per Incident: A new incident is generated for each violation detected. It can be overwhelming if an email is generated for each problem, but it is useful for critical processes where each error needs immediate attention, such as when the essential process of an application is stopped.

How is it applied in practice?

A concrete example of an alert policy is "FoodMe Policy", designed to monitor critical applications such as FoodMe App. In this case, if more than 0.1% of transactions result in errors, this will trigger a workflow notification to ensure that you are immediately aware and can act accordingly.

Why is it important to choose the right incident preference?

By choosing the right incident preference, you ensure that the alerting system is efficient and provides you with the information you really need. If you don't have the right strategy, you can be inundated with notifications, which can result in important incidents not getting the attention they deserve. Therefore, analyze the specific needs of your business and your application to choose the most convenient option.

Practical tips for setting up effective alerts

• Customize the conditions for each type of monitoring: Not all applications or services are the same. Adjust the conditions to truly reflect what is critical to you.
• Select the right notification channels: Choose channels that are effective for your team, ensuring that alerts are received and addressed quickly.
• Review and adjust policies regularly: As your application and infrastructure evolve, so should your alerting policies.