In FlashDuty incident details, incident labels display alert source data information in key:value format. These labels come from various alert events integrated with FlashDuty. When automatically generated labels from source data cannot meet business requirements, you can enrich alerts with additional label information through label enrichment to improve incident handling efficiency.Label Uses#
In FlashDuty, labels are the basic data model for alert events and incident handling. Labels serve many purposes, including but not limited to:Incident List: The incident list supports quick filtering by labels, making it easier for users to view and manage all incident records with the same labels, improving incident handling efficiency and focus
Route Configuration: When matching channels with routing rules, labels can be used as conditions to route events with the same labels to one or multiple channels
Drop Rule: When specific alerts are not needed, they can be matched using labels in drop rules
Assignment Notification: Labels can be used in assignment conditions to implement more precise and flexible notification strategies
Alert Grouping: By intelligently using same or different labels as dimensions during grouping, effectively categorize alert events and reduce noise, improving incident clarity and handling efficiency
Silence Rule: Labels can be included in silence conditions for precise filtering and silencing of alerts associated with specific labels, enabling advanced customization and noise control
Inhibit Rule: Labels serve as key conditions, allowing inhibit rules to more accurately identify and block alert events meeting specific criteria (including label matches), optimizing system efficiency and reducing false alarms
Label Enrichment: The label enrichment feature allows automatic extraction or derivation of new labels from existing source labels during configuration, optimizing label structure and enhancing resource classification and management flexibility
Configuring Label Enrichment#
Each alert event in the integration center has label enrichment configuration options, which can be configured after creating the alert event.Types of Label Enrichment#
Extract: Using regular expressions to extract needed information from alert titles, detailed descriptions, and existing label fields to automatically generate additional labels.
Compose: Composition rules can build new labels using Go template syntax, extracting label values with {{.Labels.Field}} format or generating new labels using fixed values.
Map: Maps source key-value pairs to new key-value pairs through mapping relationships. Requires pre-creating schema mapping relationships and uploading metadata before configuration. See configuration examples below. Delete: Removes labels with specified names. If the label to be deleted doesn't exist, the operation is ineffective.
Configuration Instructions#
Conditions: When performing label enrichment, you can configure prerequisite rules to restrict whether labels are generated or deleted (disabled by default). When restricted, labels won't be generated or deleted if conditions aren't met. You can learn how to configure conditions in Configuring Filter Conditions. Override: When generating new labels based on conditions, you can choose whether to override existing labels (disabled by default). For example, if a new label named "host" with value "A" is generated, it will override the original label if "host" already exists in the original alert.
Preview: After configuring rules, preview is supported to visually observe the configuration effects.
Multiple label rules can be configured and will execute from top to bottom. When a rule doesn't match, corresponding labels won't be generated/deleted, without any notification.
Configuration Examples#
Scenario: Alert events come from email integration, and key information needs to be extracted from descriptions as labels for other scenarios, such as extracting IP and trigger values as separate labels.1.1 Original Alert#
2. Label Composition#
Scenario: The company's log platform can directly access log details through domain+eventID+timestamp, but alert information only contains eventID and timestamp labels, so these need to be combined into an access URL.2.1 Original Alert#
2.2 Composition Rules#
2.3 Composition Results#
3. Label Mapping#
Scenario: When source alert label values are variable and not intuitively meaningful, mapping can be used to map source labels to newly defined labels and values. For example, when source alerts only contain resource type IDs but you want to show corresponding resource type names, this can be achieved through mapping.3.1 Creating Schema Mapping Relationships#
Source alert information only contains resource type IDs and numerically represented alert levels. Labels needing mapping are: ID->Type, Level->DLevel.| Source Label 01 | Target Label 01 | Source Label 02 | Target Label 02 |
|---|
| ID | Type | Level | Dlevel |
Create schema, where source_labels and result_labels parameters represent source and target label names respectively (more creation methods)| ID | Type | Level | Dlevel |
|---|
| A | server | 1 | Down |
| B | router | 2 | Danger |
| C | gateway | 3 | Warning |
| D | database | 4 | Notice |
| E | MQ | 5 | Info |
3.3.1 Original Alert#
3.3.2 Mapping Results#
If you don't want source labels to remain, this can be achieved using delete rules.
