OverOps allows you to fully customize alerts using raw event and threshold data flowing into the selected HTTP endpoint.
- Open Settings by clicking Settings in the top right corner of the OverOps dashboard.
This opens the Settings dashboard for the environment you're in (you can see the environment in the upper left corner of the screen).
- Go to General Settings > Alerts.
- Click the Webhook tab.
- To receive the outgoing Webhook traffic, implement an HTTP endpoint in a web-facing server.
- From the Webhook tab, enter the URL to receive the outgoing Webhook traffic.
Only admin users (account owners and admins) are authorized to change default integration settings.
Examples of Webhooks can be found here.
Once the Webhook endpoint is configured, OverOps sends a JSON message to that endpoint whenever an alert you configured gets triggered.
The tables below, describe the different message structures:
JSON structure
All alerts have the following skeleton:
{
api_version: "0.1",
type: "...",
date: ,
username: "...",
service_id: "...",
service_name: "...",
data: {
type: "NEW_EVENT",
summary: "...",
view_name: "...",
added_by: ["..."],
data: {
}
}
}api_version
string
The current API version: "0.2"
type
string
Message types are either "ALERT" or "TEST"
date
number
Timestamp in milliseconds at which the message was sent
username
string
The username/email of the secret key's owner
service_id
string
The username/email of the secret key's owner
service_name
string
The name of the secret key to which the alert pertains
The 'data' object represents the alert payload, and consists of the following:
type
string
Either "NEW_EVENT" or "THRESHOLD", depending on the type of alert
summary
string
A human readable description of the alert, rendered by OverOps
view_name
string
The name of the view for which the alert was triggered
added_by
array
An array of usernames/emails of the user(s) that configured the alert
data
object
Variant payload per event type
New event payload structure:
{
type: "...",
location: {
},
entry_point: {
},
stacktrace: [{
}, {
},
],
link: "...",
server_name: "...",
app_name: "..."
}type
string
One of "EXCEPTION", "LOG" or "HTTP_ERROR"
location
frame
The location in the code in which the event happened. See structure below
entry_point
frame
The transaction in the code in which the event happened. See structure below
stracktrace
array
An array of frames constituting the stack trace of the avent. See frame structure below
link
string
A web link to a root cause analysis of the error in OverOps
server_name
string
The name of the server on which the event happened
app_name
string
The name of the application in which the event happened
deployment_name
string
The name of the deployment in which the event happened
For events of type "EXCEPTION", the following fields will also be present:
name
string
The name of the exception that was thrown
is_caught
boolean
Whether or not this exception was caught by user code or not
message
string
The exception message
For events of type "LOG", the following fields will also be present:
level
string
One of "FATAL", "ERROR" or "WARN"
message
string
The error message that was written to the log
For events of type "HTTP_ERROR", the following fields will also be present:
error_code
string
The error code received or sent by the HTTP framework, that triggered this event
message
string
The error message describing the error that triggered this event
Locations, entry points and stack traces are made up of frames, each with the following structure:
{
class_name: "...",
method_name: "...",
method_desc: "...",
full_name: "...",
is_3rd_party: true/false,
is_catch_frame: true/false,
is_hit_frame: true/false,
modification_timestamp:
}class_name
string
The fully qualified class name described in the frame
method_name
string
The name of the method described in the frame
method_desc
string
The method descriptor, in bytecode format, of the method described in the frame
full_name
string
A human readable rendition of the class name, method name and method descriptor
is_3rd_party
boolean
Whether or not this frame belongs to the user's code, or a 3rd party library/framework
is_catch_frame
boolean
For exceptions, whether or not the exception was caught in this frame
is_hit_frame
boolean
Whether or not this is the frame in which the event happened
modification_timestamp
number
Timestamp in milliseconds at which the code in this frame was last modified
Threshold alert payload structure:
{
threshold: ,
times: ,
from_timestamp: ,
to_timestamp: ,
top_events: [{
}, {
}]
}threshold
number
The number defined by the user over which an alert is triggered
times
number
The number of times the errors which triggered this alert actually happened
from_timestamp
number
Timestamp in milliseconds at which the current alert window begun
to_timestamp
number
Timestmap in milliseconds at which the current alert window ended
top_events
array
An array of the top events that contributed to the threshold being reached. See structure below
Top event objects have the following structure:
{
title: "...",
frame: {
},
times: ,
link: "..."
}
title
string
A human readable description of the event, rendered by OverOps
frame
frame
The location in the code in which the event occurred. See structure above
times
number
The number of times this specific event happened within the alert window
link
string
A web link to a root cause analysis of the event in OverOps
The Webhooks below listed are not supported and are provided as is!
Updated about a month ago