Integrating New Relic Alerts with Discord: A Journey from Frustration to Success

Sutrishna Anjoy — Wed, 26 Mar 2025 11:54:48 +0000

Introduction

Setting up alerts for critical application issues is essential, and tools like New Relic make it easy to monitor application performance. However, New Relic doesn’t offer a direct integration with Discord, which can be frustrating when you want real-time alerts in your Discord channels.

When I started integrating New Relic Alerts with Discord, I hit multiple roadblocks, from webhook failures to incorrect payload structures. But after several iterations and experiments, I found the best approach that works seamlessly. Here’s a story of my debugging journey and how you can quickly set up New Relic alerts for Discord.

Step 1: Setting Up New Relic Alerts

Before integrating with Discord, I first needed to create an alert condition in New Relic. Here’s how:

Go to Alerts > Alert Conditions > Create Alert Condition.

Select Guided Mode.

Choose the APM service and select Error Rate as the metric.
Set the window size to 5 minutes and a threshold of 1% error rate in the last 5 minutes.
Add a meaningful name, title, and description.
Assign the alert to a default initial policy.

Great! Now I had an alert condition in place. The next challenge? Getting notifications to Discord.

Step 2: Trying Webhooks (The Wrong Way 😞)

New Relic provides several notification options, such as Slack, Webhooks, AWS EventBridge, but not Discord.

I found two promising documents:

New Relic Forum - Discord Webhook Setup

Microideation Blog on New Relic Alerts to Discord

Both documents suggested a workaround: use a Slack-compatible webhook by modifying the Discord Webhook URL like this:

<YOUR_DISCORD_WEBHOOK_URL>/slack

I was hopeful, but when I tried setting up Slack in New Relic, it only showed a login page for Slack authentication. 😤

No option to manually enter the webhook!

I even tried using New Relic CLI, but it didn’t work either.

Clearly, the Slack method was a dead end. Time for Plan B. 🚀

Step 3: Using AWS EventBridge + Lambda (The Long Way 😅)

Since the webhook approach was failing, I thought of another workaround:✔️ Use AWS EventBridge to catch New Relic alert events. ✔️ Send these events to an AWS Lambda function. ✔️ Convert the payload to a Discord-compatible format and send the alert.

Setting Up EventBridge

Create an EventBridge Partner Event Bus using New Relic:

aws.partner/newrelic.com/<NEWRELIC_ACC_ID>/acc

Create an event rule:

Name: newrelic_alerts_to_discord

Event Pattern:

{
  "source": [{
    "prefix": "aws.partner/newrelic.com"
  }]
}

Target: AWS Lambda Function

Lambda Function to Send Alerts to Discord

Here’s the Python Lambda function I wrote:

import json
import requests
import os
DISCORD_WEBHOOK_URL = os.getenv("DISCORD_WEBHOOK_URL")  # Set in Lambda environment variables
def lambda_handler(event, context):
    try:
        print("Received Event:", json.dumps(event, indent=2))
        event_detail = event.get("detail", {})
        # Extract fields
        alert_condition = ", ".join(event_detail.get("alertConditionNames", ["N/A"]))
        alert_description = ", ".join(event_detail.get("alertConditionDescriptions", ["N/A"]))
        impacted_entities = ", ".join(event_detail.get("impactedEntities", ["N/A"]))
        state = event_detail.get("state", "N/A")
        created_at = event_detail.get("createdAt", "N/A")
        # Format message for Discord
        discord_payload = {
            "content": "🚨 **New Relic Alert** 🚨",
            "embeds": [
                {
                    "title": alert_condition,
                    "description": (
                        f"**Condition Description:** {alert_description}\n"
                        f"**Impacted Entities:** {impacted_entities}\n"
                        f"**State:** {state}\n"
                        f"**Created At:** {created_at}"
                    ),
                    "color": 15158332
                }
            ]
        }
        response = requests.post(DISCORD_WEBHOOK_URL, json=discord_payload)
        if response.status_code == 204:
            return {"status": "Success"}
        else:
            return {"status": "Failed", "error": response.text}
    except Exception as e:
        return {"status": "Error", "message": str(e)}

It worked! 🎉 But, let’s be real – this was too complex for a simple webhook notification.

Step 4: The Best Approach – Using Webhooks the Right Way ✅

For Discord Webhooks to work, the JSON payload must include content or embeds. Without these keywords, Discord will reject the payload!

Final JSON Payload for Discord Webhook

{
  "content": "🚨 **New Relic Alert** 🚨",
  "embeds": [
    {
      "title": "{{ accumulations.conditionName.[0] }}",
      "description": "**Condition Description:** {{#each accumulations.conditionDescription}}{{#unless @first}}, {{/unless}}{{escape this}}{{/each}}\n**Impacted Entities:** {{#each entitiesData.names}}{{#unless @first}}, {{/unless}}{{this}}{{/each}}\n**State:** {{state}}\n",
      "color": 15158332,
      "footer": {
        "text": "{{timezone createdAt 'Asia/Kolkata'}}"
      }
    }
  ]
}

Why This Works?

✔️ Uses Handlebars syntax to format the payload correctly. ✔️ Includes the required content field, making Discord accept the message. ✔️ No need for EventBridge or Lambda – pure webhook solution! ✔️ Works seamlessly with New Relic webhook notifications.

Conclusion

💡 Lesson Learned: Always check the webhook payload format before building unnecessary workarounds! 😅

By correctly structuring the JSON using Handlebars syntax and ensuring the presence of content or embeds, I was able to directly send New Relic alerts to Discord without using AWS services.

🚀 If you’re setting up New Relic to Discord alerts, follow Solution 2 – it’s simple, efficient, and works perfectly!

Virtualization - The Basics

Sutrishna Anjoy — Mon, 01 Jul 2024 14:45:56 +0000

Virtualization in computing means creating a virtual version of something instead of a physical one. This includes virtual versions of computer hardware, storage devices, and network resources.
In this post, I will focus on discussing virtual machines on bare metal or a host machine, specifically in terms of Linux.

Virtual Machine: A VM is a software version of a physical computer. It allows you to run an operating system and applications just like on a real computer, but it works within another computer (the host), sharing its resources like CPU, memory, and storage. In fact, each VM believes it is the only system running on the hardware.

Hypervisor: A hypervisor is software that lets you run multiple VMs on one physical computer. It manages the computer's resources and makes sure each VM operates independently.

Type-1: A Type-1 hypervisor, also known as a bare-metal hypervisors, are installed directly onto the physical hardware without needing a separate operating system. It manages the VMs directly, providing them with access to the hardware resources.
Examples include KVM (Kernel-based Virtual Machine), Proxmox, VMware ESXi, Microsoft Hyper-V Server and Citrix Hypervisor (formerly XenServer).

Type-2: A Type-2 hypervisor is like a software application that you install on your computer's operating system (like Windows, macOS, or Linux). It creates VMs that can run different operating systems alongside your main operating system.
Examples include VirtualBox, VMware Workstation, and QEMU.

Different virtualization techniques used in VMs are as follows:

Fully Virtualized: When a guest OS running in a VM attempts to access hardware (like CPU, memory, or network), it interacts with virtual hardware interfaces provided by the hypervisor. The hypervisor translates these hardware calls into commands that the physical hardware can execute. This process involves emulating the actual hardware interfaces and translating the commands to ensure they are compatible with the host hardware. The guest OS are unaware that they are running on virtualized hardware.

Paravirtualization: In paravirtualization, the guest OS is modified to replace certain privileged instructions with hypercalls, which are calls directly to the hypervisor. Hypercalls are specific function calls that the guest OS uses to request services from the hypervisor, such as memory management, I/O operations, or scheduling. It reduced overhead and improve efficiency compared to traditional fully virtualized approaches.

Emulation: When a guest software running on an emulated environment makes a hardware call, such as accessing memory or processing data, the emulated software (QEMU) translates these calls into instructions that the host system can understand and execute.

Shared Hardware Virtualization: Suppose a VM running a high-performance application requires direct access to a specialized GPU for computational tasks. The hypervisor identifies the GPU and assigns it to the VM using pass-through. When the VM makes hardware calls related to GPU operations those calls are handled directly by the GPU without involving the hypervisor's virtualization layer.

Conclusion: virtualization improves efficiency by maximizing hardware use(overcommiting). This optimizes hardware use, reduces costs, enhances security by isolating each VM, and makes IT systems more flexible and easier to manage. It also speeds up deploying new software and recovering from failures.

DEV Community: Sutrishna Anjoy