At OpsGenie, we do our best to enhance our customer's experience using our platform. We consider their needs and develop features that will promote efficiency and growth.
We believe that our product is already feature-rich, yet we’re continuing to further develop it to promote customization and flexibility. Our team works daily to continue product enhancements; and they’re always ready to extend it with customizations, as you need.
We have a Web API and Software Development Kits for Java, Python, and Golang programming languages as well as Node.js environment. Isn’t it great that you can develop your own tools yourself as an extension of OpsGenie’s product out-of-the-box capabilities?
In this blog post you’ll learn how to use our Web API and add to our product capabilities.
OpsGenie Web API
Our Web API lets you interact with alerts from anything that can be sent through an HTTP request. You can accomplish almost everything you do via our Web UI with our Web API. For example, you can create, acknowledge, close, delete, list alerts; create, update, delete, list teams, and do even more programmatically through our Web API.
Developing Your Custom Solutions
We love new customization requests from our customers! It's an exciting challenge and allows us to utilize our product’s flexibility while developing these new solutions.
Once, a customer of ours explained that they needed to have multiple teams working on their time sensitive issues and asked if it was possible to create an alert per team for such issues. Challenge accepted! We examined the request and developed a script that works under the Amazon Web Services - Lambda Service using Python programming language. Let us explain….
What we did
Step 1. Our goal was to first specify whether an alert should be replicated for multiple teams. If so, we considered the initial alert as the “root alert” and created a “sub-alert” for each team. Hence we created an extra alert property named, “teamsToNotify.” As the value of “teamsToNotify”, you can assign team names for each sub-alert (this needs to be comma-separated). Sub-alerts should also have a "rootAlertID" field in the extra properties when they are created. This "rootAlertID" field is the ID of the root alert, and is used to build a parent-child relationship with the root alert and its sub-alerts.
Step 2. We created a Webhook integration to invoke the AWS Lambda script. To forward the root alert and teams to notify information to the script, we then added the conditions listed below as a filter to the integration:
- Extra Properties |Contains Key| teamsToNotify.
- Extra Properties |Contains Key| rootAlertId.
Once you complete the integration, if you create a new alert with a "teamsToNotify" key and team names as its value (e.g. "team1, team2, team3"); the integration will send this to the script. Here, the script creates a sub-alert for each team specified in the "teamsToNotify" field. The script also adds the Alert ID of each sub-alert to the root alert as a tag.
How does it sound so far? Cool, huh?
How about the interactions between a root alert and its sub-alerts? Did you question what would happen to the sub-alerts once the root alert is acknowledged? Or, what would happen to the remaining alerts if one of the sub-alerts is closed? Great news! All can be configured in many different ways depending on the logic you need.
Here is an example of what we did for a specific customer…
When a sub-alert is acknowledged, the script adds a comment to the root alert such as "User X acknowledged the alert for team Y" to indicate that a team has acknowledged the alert created for them. When a root alert or a sub-alert is closed, we consider the issue fixed and close all sub-alerts and the root alert.
Efficient, right? Please let us know what you think. Give us your feedback and continue to challenge us with your feature requests!
Sign up for OpsGenie’s 14- day free trial and see how OpsGenie is armed with all the tools and flexible configuration options to fulfill all of your alerting and incident management requirements!