Alert History Import and Export APIΒΆ
GET https://api.robusta.dev/api/alertsΒΆ
Use this endpoint to export alert history data. You can filter the results based on specific criteria using query parameters such as alert_name
, account_id
, and time range.
Query ParametersΒΆ
Parameter |
Type |
Description |
Required |
---|---|---|---|
|
string |
The unique account identifier (found in your |
Yes |
|
string |
Start timestamp for the alert history query (in ISO 8601 format, e.g., |
Yes |
|
string |
End timestamp for the alert history query (in ISO 8601 format, e.g., |
Yes |
|
string |
The name of the alert to filter by (e.g., |
No |
Example RequestΒΆ
The following curl
command demonstrates how to export alert history data for the CrashLoopBackoff
alert:
curl --location 'https://api.robusta.dev/api/alerts?alert_name=CrashLoopBackoff&account_id=ACCOUNT_ID&start_ts=2024-09-02T04%3A02%3A05.032Z&end_ts=2024-09-17T05%3A02%3A05.032Z' \
--header 'Authorization: Bearer TOKEN_HERE'
In the command, make sure to replace the following placeholders:
ACCOUNT_ID
: Your account ID, which can be found in yourgenerated_values.yaml
file.TOKEN_HERE
: Your API token for authentication. You can generate this token in the platform by navigating to Settings -> API Keys -> New API Key, and creating a key with the "Read Alerts" permission.
Request HeadersΒΆ
Header |
Description |
---|---|
|
Bearer token for authentication (e.g., |
Response FormatΒΆ
The API will return a list of alerts in JSON format. Each alert object contains detailed information about the alert, including the name, priority, source, and related resource information.
Example ResponseΒΆ
[
{
"alert_name": "CrashLoopBackoff",
"title": "Crashing pod api-gateway-123abc in namespace prod",
"description": null,
"source": "kubernetes_api_server",
"priority": "HIGH",
"started_at": "2024-09-03T04:09:31.342818+00:00",
"resolved_at": null,
"cluster": "prod-cluster-1",
"namespace": "prod",
"app": "api-gateway",
"kind": null,
"resource_name": "api-gateway-123abc",
"resource_node": "gke-prod-cluster-1-node-1"
},
{
"alert_name": "CrashLoopBackoff",
"title": "Crashing pod billing-service-xyz789 in namespace billing",
"description": null,
"source": "kubernetes_api_server",
"priority": "HIGH",
"started_at": "2024-09-03T04:09:31.496713+00:00",
"resolved_at": null,
"cluster": "prod-cluster-2",
"namespace": "billing",
"app": "billing-service",
"kind": null,
"resource_name": "billing-service-xyz789",
"resource_node": "gke-prod-cluster-2-node-3"
}
]
Response FieldsΒΆ
Field |
Type |
Description |
---|---|---|
|
string |
Name of the alert (e.g., |
|
string |
A brief description of the alert event. |
|
string |
Source of the alert (e.g., |
|
string |
Priority level of the alert (e.g., |
|
string |
Timestamp when the alert was triggered, in ISO 8601 format. |
|
string |
Timestamp when the alert was resolved, or |
|
string |
The cluster where the alert originated. |
|
string |
Namespace where the alert occurred. |
|
string |
The application that triggered the alert. |
|
string |
Name of the resource that caused the alert. |
|
string |
The node where the resource is located. |
POST https://api.robusta.dev/api/alertsΒΆ
Use this endpoint to send alert data to Robusta. You can send up to 1000 alerts in a single request.
Request Body SchemaΒΆ
The request body must include the following fields:
Field |
Type |
Description |
Required |
---|---|---|---|
|
string |
The unique account identifier. |
Yes |
|
list |
A list of alerts to be sent. |
Yes |
Each alert in the alerts
list must follow the specific schema, which includes the following fields:
Field |
Type |
Description |
Required |
---|---|---|---|
|
string |
A short description of the alert. |
Yes |
|
string |
A detailed description of the alert |
Yes |
|
string |
The source of the alert. |
Yes |
|
string (one of: |
The priority level of the alert. |
Yes |
|
string |
A key to group alerts that are related. |
Yes |
|
boolean |
Indicates whether the alert represents a failure (default: |
No |
|
string (ISO 8601 timestamp) |
The timestamp when the alert started (optional). |
No |
|
string (ISO 8601 timestamp) |
The timestamp when the alert ended (optional). |
No |
|
dict |
Extra labels for the alert (optional). |
No |
|
dict |
Extra annotations for the alert (optional). |
No |
|
string |
Alert's cluster (default: |
No |
|
string |
A key identifying the service related to the alert (optional). |
No |
|
string |
The type of subject related to the alert (optional). |
No |
|
string |
The name of the subject related to the alert (optional) |
No |
|
string |
The namespace of the subject related to the alert (optional). |
No |
|
string |
The node where the subject related to the alert is located (optional). |
No |
|
string |
A unique identifier for the alert (optional). |
No |
Example RequestΒΆ
Here is an example of a POST
request to send a list of alerts:
curl --location --request POST 'https://api.robusta.dev/api/alerts' \
--header 'Authorization: Bearer TOKEN_HERE' \
--header 'Content-Type: application/json' \
--data-raw '{
"account_id": "ACCOUNT_ID",
"alerts": [
{
"title": "Test Service Down",
"description": "The Test Service is not responding.",
"source": "monitoring-system",
"priority": "high",
"aggregation_key": "test-service-issues",
"failure": true,
"starts_at": "2024-10-07T10:00:00Z",
"labels": {
"environment": "production"
},
"annotations": {
"env1": "true"
},
"cluster": "prod-cluster-1",
"subject_namespace": "prod",
"subject_node": "gke-prod-cluster-1-node-1"
}
]
}'
In this request, replace the following placeholders:
ACCOUNT_ID
: Your account ID, which can be found in yourgenerated_values.yaml
file.TOKEN_HERE
: Your API token for authentication. You can generate this token by navigating to Settings -> API Keys -> New API Key.
Request HeadersΒΆ
Header |
Description |
---|---|
|
Bearer token for authentication (e.g., |
|
Must be set to |
Response FormatΒΆ
Success Response
If the request is successful, the API will return the following response:
{
"success": true
}
Status Code: 200 OK
Error Response
If there is an error in processing the request, the API will return the following format:
{
"msg": "Error message here",
"error_code": 123
}
Status Code: Varies based on the error (e.g., 400 Bad Request, 500 Internal Server Error).
POST https://api.robusta.dev/api/config-changesΒΆ
Use this endpoint to send configuration changes to Robusta. You can send up to 1000 configuration changes in a single request.
Request Body SchemaΒΆ
The request body must include the following fields:
Field |
Type |
Description |
Required |
---|---|---|---|
|
string |
The unique account identifier. |
Yes |
|
list |
A list of configuration changes. |
Yes |
Each configuration change in the config_changes
list must follow the specific schema, which includes the following fields:
Field |
Type |
Description |
Required |
---|---|---|---|
|
string |
A short description of the configuration change. |
Yes |
|
string |
The previous configuration value. |
Yes |
|
string |
The new configuration value. |
Yes |
|
string |
The name of the resource affected by the configuration change. |
Yes |
|
string |
A detailed description of the configuration change (optional). |
No |
|
string |
The source of the configuration change (default: |
No |
|
string |
The cluster where the configuration change occurred (default: |
No |
|
dict |
Extra labels for the alert (optional). |
No |
|
dict |
Extra annotations for the configuration change (optional). |
No |
|
string |
The name of the subject related to the configuration change (optional). |
No |
|
string |
The namespace of the subject related to the configuration change (optional). |
No |
|
string |
The node where the subject related to the configuration change is located (optional). |
No |
|
string |
The type of subject related to the configuration change (optional). |
No |
|
string |
A key identifying the service related to the configuration change (optional). |
No |
|
string |
A unique identifier for the configuration change (optional). |
No |
Example RequestΒΆ
Here is an example of a POST
request to send a list of configuration changes:
curl --location --request POST 'https://api.robusta.dev/api/config-changes' \
--header 'Authorization: Bearer TOKEN_HERE' \
--header 'Content-Type: application/json' \
--data-raw '{
"account_id": "ACCOUNT_ID",
"config_changes": [
{
"title": "Updated test-service deployment",
"old_config": "apiVersion: apps/v1\nkind: Deployment\n....",
"new_config": "apiVersion: apps/v1...",
"resource_name": "test sercvice",
"description": "Changed deployemnt",
"source": "test-service",
"cluster": "prod-cluster-1",
"labels": {
"environment": "production"
},
"annotations": {
"env1": "true"
},
"subject_namespace": "prod",
"subject_node": "gke-prod-cluster-1-node-1"
}
]
}'
In this request, replace the following placeholders:
ACCOUNT_ID
: Your account ID, which can be found in yourgenerated_values.yaml
file.TOKEN_HERE
: Your API token for authentication. You can generate this token by navigating to Settings -> API Keys -> New API Key.
Request HeadersΒΆ
Header |
Description |
---|---|
|
Bearer token for authentication (e.g., |
|
Must be set to |
Response FormatΒΆ
Success Response
If the request is successful, the API will return the following response:
{
"success": true
}
Status Code: 200 OK
Error Response
If there is an error in processing the request, the API will return the following format:
{
"msg": "Error message here",
"error_code": 123
}
Status Code: Varies based on the error (e.g., 400 Bad Request, 500 Internal Server Error).