Core Uses
Labels are used throughout Flashduty On-call’s alert processing workflow:
| Scenario | Use |
|---|
| Incident Filtering | Quickly filter by labels in incident list |
| Route Distribution | Route alerts to different channels based on labels |
| Assignment Notification | Match different escalation rules by labels |
| Alert Grouping | Group similar alerts by label dimensions |
| Silence/Inhibition | Match alerts to silence or inhibit by labels |
Go to Integration Details → Label Enhancement → Add Rule.
Enhancement Types
| Type | Description | Example |
|---|
| Extract | Extract content from title/description/labels using regex | Extract IP address from description |
| Combine | Concatenate new labels using template syntax | Combine domain + event ID to generate log link |
| Map | Convert values to readable names via mapping table | Map resource ID to resource type |
| Delete | Remove specified labels | Delete sensitive info labels |
Configuration Options
| Option | Description |
|---|
| Condition | Only applies to alerts matching conditions, see Configure Filter Conditions |
| Overwrite | When enabled, overwrites labels with same name; disabled by default |
| Preview | Preview rule effects using real alerts |
Multiple rules execute sequentially from top to bottom. When a rule doesn’t match, it’s skipped and no corresponding label is generated.
Configuration Examples
Mapping Data Management
Mapping Table Data Management
In the mapping table details page, you can manage mapping table data:
| Feature | Description |
|---|
| Data Search | Search by source label value |
| Data Add | Manually add mapping data |
| Data Upload | Upload new data mapping table, will overwrite existing data |
| Data Download | Download current mapping table data locally |
| Data Display | Display current mapping table data, can edit or delete |
For frequently changing mapping relationships (like Mapping api data sync), we recommend using API mapping, or use Flashduty API for automated mapping table updates.
Mapping Service API Specification
When using API mapping, your external API service must follow these specifications:
Request Specification
Flashduty will call your API via POST method with the following request body:
{
"result_label_keys": ["owner_team", "service_tier", "host_ip"],
"event": {
"account_id": 1,
"channel_id": 20,
"data_source_id": 15,
"data_source_type": "prometheus",
"description": "CPU usage for instance '10.0.1.1:9100' is over 95%",
"title": "High CPU Usage on instance 10.0.1.1:9100",
"alert_key": "d41d8cd98f00b204e9800998ecf8427e",
"alert_id": "62d6c0f6b8f1b2b3c4d5e6f7",
"event_severity": "Critical",
"event_status": "Critical",
"event_time": 1678886400,
"labels": {
"region": "us-east-1",
"service": "service-A",
"env": "production",
"instance": "10.0.1.1:9100"
}
}
}
| Field | Type | Description |
|---|
result_label_keys | array[string] | List of expected label names to return, configured by user in the rule |
event | object | Complete information of the current alert event |
Response Specification
The API must return a JSON response in the following format:
Success Response (HTTP 200):
{
"result_labels": {
"owner_team": "team-database",
"service_tier": "tier-1",
"host_ip": "10.0.1.1"
}
}
| Response Code | Description |
|---|
200 OK | Success, returns result_labels object |
404 Not Found | No matching data found |
400 Bad Request | Invalid request format |
5xx | Internal server error |
If a requested label cannot find a corresponding value, the API should not include that key in result_labels.
Security Constraints
For security purposes, the following HTTP Headers are prohibited in mapping services:
| Category | Prohibited Headers |
|---|
| Authentication | authorization, proxy-authorization, cookie, x-api-key, x-access-token |
| IP Spoofing | x-forwarded-for, x-real-ip, true-client-ip, x-client-ip |
| Host & Routing | host, x-forwarded-host, x-forwarded-proto, x-internal-id, x-user-id |
| Protocol Related | transfer-encoding, upgrade, connection |
We recommend using custom Headers with X-Custom- or X-Enrich- prefix for authentication.
Best Practices
- Performance First: The API is on the critical path of alert processing, must ensure low latency (recommended < 500ms)
- Implement Caching: For identical query conditions, implement caching to improve performance
- Idempotent Design: Multiple calls for the same event should return identical results
- Secure Authentication: API must be protected by authentication mechanisms to prevent unauthorized access
Further Reading