Skip to main content

Alerts

Alerts are notifications that you can set up to inform you about an event. They can be created via the Create Notification selection on the Notifications page under Alerts or can be defined in the new event definition workflow.

Assigned alerts are displayed on the Notifications page. This page is also bulk friendly and allows you to edit multiple entities. You can see if your alerts are active by clicking on the Test Notifications button under More Actions. You will then see a success or error message under the entity title.

In this section, we explain how to create an alert and how to configure supported alert types.

Note

Alerts are meant to be extensible through plugins. You can find more options in Security Data Lake Marketplace or even create your own.Security Data Lake Marketplace

Events and Alerts Page

The filter functionality on the Alerts & Events page in the General perspective allows you to quickly drill down into specific types of alerts by applying targeted filters. This helps narrow the scope of your active alerts, making it easier to focus on relevant data during monitoring or investigation.

Search Panel

At the top of the page, you'll find a search bar designed to help you search through events by using keywords. To further drill down on search results, you can use filters to find specific events or alerts.

Filters

Filters allow you to narrow down events or alerts with precision. Select the + icon dropdown button next to Filters to view a list of available filter types:

Filter Option

Purpose

Type

Filters for event categories which could either be and event or an alert.

Priority

Shows only events with selected severity levels (e.g., Low, Medium, High).

Timestamp

Defines a a time window to filter events within a date/time range. Useful for incident review.

Event Definition

View only events or alerts based on predefined system or user-defined event rules.

Aggregation time range

Time window used for evaluating the event definition.

ID

Search by specific event IDs if known.

When a filter is applied, it becomes visible as a tag next to the Filters dropdown menu. Multiple filters can be selected and combined for precision targeting.

Note

You can only use one filter for a Boolean attribute. For example, you can either filter for an event or an alert but not both at the same time.

Metrics Graph Widget

This widget plots the count of events over time. It helps quickly identify spikes or trends in event occurrences.

  • Blue Line (Events): Events are color-coded to blue and represent detected events.

  • Orange Line (Alerts): Alerts are color-coded to orange and highlights triggered alerts.

  • Interactive Axis: Hover over graph points for a summary of event counts at specific times. X-axis represents a timeline, and the Y-axis represents count.

  • Export: The chart can be exported using the download icon for reporting purposes.

  • Auto-refresh: Select update behavior by clicking the Not updating dropdown and choosing a timeframe ( e.g. 5 seconds, 10 seconds, 1 minute or 5 minutes) for real-time monitoring.

This widget is instrumental in identifying spikes in malicious behavior or assessing alert volumes over time.

If the message “No events have been found” is displayed, it means no event definition rules have triggered within the selected filters or timeframe. You may need to:

  • Expand the timestamp range.

  • Remove filters.

  • Confirm event generation on the backend is functioning.

Beneath the metrics graph, all your events and alerts are listed in a table, grouped into various columns, beginning with a description of the event/alert, priority, key, type, event definition, event definition type, timestamp and actions. Additional columns can be displayed or removed by clicking on the Columns dropdown button and selecting available column categories.

From the list of all displayed alerts and events, you can either click on an event or alert to expand and view its details or you can click on the Details button in the Actions column.. You can also add notifications to an event by clicking on the More dropdown menu button in the Actions column and select Send Notifications.

Alerts Page Example

You can troubleshoot failed inputs by filtering. For instance, an event like INPUT_FAILING: An input has failed to start is a critical system warning which surfaces in the alerts and events page. Filtering by Type = Event, Event Definition = System notificationevents and Priority = Low/High quickly isolates these kinds of events for response or escalation.

Create an Alert from the Alerts Menu

  1. Navigate to the Alerts menu and select Notifications.

  2. Select the Create notification button.

  3. Complete the following fields:

    1. Title: Create a unique title for your alert.

    2. Description (optional): You may add additional details about your alert in this field if desired.

    3. Notification Type: Select the alert type from the drop-down menu.

  4. After you select an alert type, you are presented with additional fields based on the type selected. The alert types and key fields to configure for each are detailed in Alert Types.

  5. You may also choose to test your alert at this time by selecting Execute Test Notification.

  6. Click Create notification.

Create an Alert in the New Event Definition Workflow

You may also choose to create an alert while you are in the process of defining a new event.

  1. In the New Event Definition menu, there will be a selection for Notifications in the menu bar.

  2. Under Add Notification, select Create New Notification from the drop-down menu.

  3. From the menu that populates, complete the following fields:

    1. Title: Create a unique title for your alert.

    2. Description (optional): You may add additional details about your alert in this field if desired.

    3. Notification Type: Select the alert type from the drop-down menu.

  4. After you select an alert type, you are presented with additional fields based on the type selected. The alert types and key fields to configure for each are detailed in Alert Types.

  5. You may also choose to test your alert at this time by selecting Execute Test Notification.

  6. Click Create notification.

Metadata Available to Alerts

When creating alerts you can utilize metadata from the event definition, the event itself, and the event's backlog messages (if it is configured to retain a backlog). This metadata can be used when formatting email, Slack, and Microsoft Teams alerts or when providing arguments to a script alert.

For example, if you wish to include more information in your Slack alerts, you may add new fields to the Custom Message section. You may also remove any fields that you do not wish to see by deleting them from this section.

Or you could add arguments to a script alert to include more information in your alerts.

Fields that are available for each entity type are detailed below.

Event Definition Metadata

Field

Type

Description

event_definition_id

String

The database ID of the event definition

event_definition_type

String

The internal name of the event definition type (aggregation-v1 or correlation-v1)

event_definition_title

String

The title set in the UI

event_definition_description

String

The description set in the UI

job_definition_id

String

The internal job definition ID associated with a scheduled event definition

job_trigger_id

String

The internal ID associated with the current execution of the job.

Event Metadata

Field

Type

Description

event

The event as it is stored in Security Data Lake

id

String

The message ID of the stored event

event_definition_id

String

The database ID of the event definition

event_definition_type

String

The internal name of the event definition type (aggregation-v1 or correlation-v1)

origin_context

String

URN of the message or event creating this event (either event or message) (can be empty)

timestamp

DateTime

The timestamp can be set to the underlying event or message (see origin_context above)

timestamp_processing

DateTime

The timestamp for when the event was created by Security Data Lake

timerange_start

DateTime

The start of the window of data Security Data Lake used to create this event (can be empty)

timerange_end

DateTime

The end of the window of data Security Data Lake used to create this event (can be empty)

streams

String

The list of stream IDs the event is stored in

source_streams

String

The list of stream IDs the event pulled data from

alert

Boolean

Whether this event is considered to be an alert; always true for event definitions that have alerts

message

String

A human-friendly message describing this event

source

String

The host name of the Security Data Lake server that created this event

key_tuple

String

The list of values making up the event’s key

key

String

The event’s key as a single string

priority

Long

The event’s priority value

fields

Map

The custom fields attached to the event

Backlog Metadata

Field

Type

Description

backlog

The list of messages or events which lead to the alert being generated

id

String

The message ID

index

String

The name of the index the message is stored in; use together with id to uniquely identify a message in Security Data Lake

source

String

The source field of the message

message

String

The message field of the message

timestamp

DateTime

The timestamp field of the message

stream_ids

String

The stream IDs of the message

fields

Map

The remaining fields of the message (can be iterated)

Delete Queued Alerts

If processing stops and event updates begin to pile up in the queue, then you might have unknowingly fired too many alerts. To avoid an influx of alerts, make sure to set an alert grace period for event definitions. The grace period enforces a rate limit on how many alerts are triggered for identical events. This effectively prevents queued event alerts. Without a grace period in place, too many event triggers can cause a backlog of alerts.

If you are faced with queued event alerts, there are two ways of clearing the alert queue.

Clear Alert Queue Manually

Clear the alert queue manually through the interface:

  1. Navigate to the Events Definition menu by selecting Alerts > Event Definitions.

  2. From the list of definitions available, click on the Information icon under Scheduling.

  3. The event definition menu will expand. Here, you will see the number of queued alerts. If there are a lot of queued alerts, this typically suggests an abnormality. On the Queued alerts line, click on clear to clear queued alerts for the selected event definition.

Disable an Event

You can also clear the alert queue by disabling an event.

  1. As in the previous example, navigate to the Events Definitions tab.

  2. Next to your event definition, click the More drop-down button, and select Disable from the menu option for the event you wish to disable.

  3. Upon selecting the Disable option, a pop-up dialog screen appears, prompting you to confirm the selection.

  4. When disabled an alert is displayed confirming that the selected event definition has been disabled.

Alert Types

As detailed in Alerts, alerts are messages that you can configure to inform you about an event. During the process of creating an event definition, you can attach an alert to the event, and you can choose how these alerts are sent (email, Slack or Discord alert, etc.).

Security Data Lake supports alerts through the following methods:

PagerDuty Alerts

Note

In order to use PagerDuty alerts, you will need an integration routing key. If you do not already have one, you will need to create a new integration in PagerDuty.

The PagerDuty alert allows you to create new incidents in PagerDuty in response to events in your Security Data Lake server. These are the supported configuration options to be defined in the New Notification menu for PagerDuty:

  • Routing Key

    Your PagerDuty integration routing key.

  • Use a Custom Incident Key

    If enabled, an incident key will be generated using the provided Incident Key Prefix. This will prevent PagerDuty from creating multiple incidents for a single event. If not selected, an incident key will NOT be generated, and each event notification will create a new incident in PagerDuty.

  • Incident Key Prefix

    If a custom incident key is enabled, this will be used as a prefix for the incident key.

  • Client Name

    The name of the Security Data Lake system that triggered the PagerDuty incident.

  • Client URL

    The URL for your Security Data Lake web interface. If provided, this will be used to construct links that will be embedded in your PagerDuty incident.

Note

PagerDuty alerts are intended as a replacement for the PagerDuty integration, previously available from Security Data Lake Labs. If you are using the Security Data Lake Labs PagerDuty integration, you should migrate to the officially supported PagerDuty alerts.

Slack Alerts

Slack allows you to send alerts to your Slack workspace in response to events in your Security Data Lake server. These are the supported configuration options to be defined in the New Notification menu for Slack:

  • Configuration Color

    Highlight the custom message with a color you prefer.

  • Webhook URL

    The unique URL used to send messages to your Slack instance.

  • Channel

    The channel to which you will send a message or you can select @user or @team to receive the alert.

  • Custom Message

    The message that will be sent to Slack. The data described above can be used in this template.

    Note

    To send Slack alerts to an individual recipient, add their Slack ID or username to the beginning of the

    Custom Message template. Slack IDs can be found under a Slack user's profile. You can also add

    the recipient's email username, specifically the part of an email address that precedes the @ sign.

  • Time Zone for Date/Time Values

    Select your preferred time zone used for timestamps in the alert. This selection will default to UTC.

  • Message Backlog Limit (optional)

    Limit the number of backlog messages sent as part of the Slack alert. If set to 0, no limit will be enforced.

  • User Name (optional)

    User name of the sender in Slack.

  • Selections (you may choose to enable the following options):

    • Include Title: If enabled, this will include the full event definition title and description in the alert.

    • Notify Channel: If enabled, this will notify all the users in a channel with @channel.

    • Notify Here: If enabled, this will notify only active users in the channel with @here.

    • Link Names: If enabled, this will find and link channel names and user names in the alert.

  • Icon URL (optional)

    Image to use as the icon for this message.

  • Icon Emoji (optional)

    Emoji to use as the icon for this message (this overrides any icon URL).

Note

Slack alerts are intended as a replacement for the Slack integration previously available from Security Data Lake Labs. If you are using the Security Data Lake Labs Slack plugin, you should migrate to the officially supported Slack alerts at your earliest convenience

Microsoft Teams Alerts

Microsoft Teams notifications allow you to send messages to a Teams channel when specific events occur in your Security Data Lake setup. This is done via a workflow that is created in Microsoft Teams. The Microsoft Teams Notification V2 supports sending an adaptive card to the Post to a channel when a webhook request is received workflow.

Note

Make sure to copy the webhook URL when creating the workflow! This is required for theWebhook URLfield upon configuration. Also note that, Microsoft Teams requires webhooks to be generated for all individual channels.

Create a Workflow in Microsoft Teams

Follow the steps below to create a workflow in Microsoft Teams:

  1. Navigate to Apps > Workflows > Manage Workflows > Create.

  2. Search for Post to a channel when a webhook request is received under Notifications. Select the template with the most uses in workflows.

  3. Give your workflow a unique title and click Add Workflow.

  4. Save the webhook URL which is displayed in a pop up window. This is required for configuring a Security Data Lake notification later on.

In order to edit the adaptive card:

  1. Click Manage your workflow in the next pop up window.

  2. Click Edit on the following page.

  3. Expand the Send each adaptive card action.

  4. Replace body.attachments with attachments, which can be found in the dynamic content options.

  5. Click the Post card in a chat or channel.

  6. Select Post as User.

  7. Make your selections for Post In, Team and Channel.

  8. Save the workflow.

    Note

    You can expand the When a Teams webhook request is receivedtrigger to copy the webhook URL, if you did not do so earlier.

When you have the webhook URL, navigate to Security Data Lake to create a Microsoft Teams Notification V2.

Create a Microsoft Teams Notification in Security Data Lake

  1. Navigate to Alerts > Notifications and click Create notification.

  2. Give the notification a unique title and description.

  3. Select Microsoft Teams Notification V2 from the Notification Type drop-down menu.

  4. Enter the URL that you saved previously into the Webhook URL box.

  5. The default Adaptive Card Template is similar to your original adaptive card. Use the Microsoft Adaptive Card Designer if you want to customize it.

  6. Choose a relevant time zone under Time zone for date/time values. This selection will default to UTC.

  7. Select a backlog limit. This is optional.

  8. Click Execute Test Notification to validate that your notification works.

  9. Click Create Notification.

Script Alerts (Enterprise Only)

The script alert option lets you configure a script that will be executed when the alert is triggered.

These are the supported configuration options to be defined in the New Notification menu for script alerts:

  • Script Path

    The path to where the script is located. Must be within the permitted script path (which is customizable).

  • Script Timeout

    The maximum time (in milliseconds) the script will be allowed to execute before being forcefully terminated.

  • Script Arguments

    Space-delimited string of parameters. Any of the data described above can be used.

  • Send Alert Data Through STDIN

    Sends the JSON encoded data described above through standard in. You can use a JSON parser in your script.

Script Alert success is determined by its exit value; success equals zero. Any non-zero exit value will cause it to fail. Returning any error text through STDERR will also cause the alarm callback to fail.

Here is a sample Python script that shows all supported Script Alert functionality (argument parsing, STDIN JSON parsing, STDOUT, exit values, and returning an exit value).

#!/usr/bin/env python3
import json
import sys

# Function that prints text to standard error
def print_stderr(*args, **kwargs):
    print(*args, file=sys.stderr, **kwargs)

# Main function
if __name__ == "__main__":

    # Print out all input arguments.
    sys.stdout.write("All Arguments Passed In: " + ' '.join(sys.argv[1:]) + "\n")

    # Turn stdin.readlines() array into a string
    std_in_string = ''.join(sys.stdin.readlines())

    # Load JSON
    event_data = json.loads(std_in_string)

    # Extract some values from the JSON.
    sys.stdout.write("Values from JSON: \n")
    sys.stdout.write("Event Definition ID: " + event_data["event_definition_id"] + "\n")
    sys.stdout.write("Event Definition Title: " + event_data["event_definition_title"] + "\n")
    sys.stdout.write("Event Timestamp: " + event_data["event"]["timestamp"] + "\n")

    # Extract Message Backlog field from JSON.
    sys.stdout.write("\nBacklog:\n")
    for message in event_data["backlog"]:
        for field in message.keys():
            sys.stdout.write("Field: " + field + "\t")
            sys.stdout.write("Value: " + str(message[field]) + "\n")

    # Write to stderr if desired
    # print_stderr("Test return through standard error")

    # Return an exit value. Zero is success, non-zero indicates failure.
    exit(0) 

Email Alerts

Email alerts can be used to send an email to the configured alert receivers when conditions are triggered. Make sure to check the email-related configuration settings in the Security Data Lake configuration file.

Several configuration options are available for the alert to customize the email that will be sent. Note that the email body and email subject are JMTE templates. JMTE is a minimal template engine that supports variables, loops and conditions. See the JMTE documentation for a language reference.

The default body template shows some advanced examples of accessing the available information in the template:

--- [Event Definition] ---------------------------
Title:       ${event_definition_title}Description: ${event_definition_description}
Type:        ${event_definition_type}
--- [Event] --------------------------------------
Timestamp:            ${event.timestamp}
Message:              ${event.message}
Source:               ${event.source}
Key:                  ${event.key}
Priority:             ${event.priority}
Alert:                ${event.alert}
Timestamp Processing: ${event.timestamp}
Timerange Start:      ${event.timerange_start}
Timerange End:        ${event.timerange_end}
Fields:
${foreach event.fields field}${field.key}: ${field.value}
${end}
${if backlog}
--- [Backlog] ------------------------------------
Last messages accounting for this alert:
${foreach backlog message}
${message}
${end}
${end}

These are the supported configuration options to be defined in the New Notification menu for email alerts:

  • Subject

    The subject used for the email alert. As noted above, the email subject is a JMTE template.

  • Send notification as a single email to all recipients

    Use this check box to send a single message to all recipients. This option allows users to reply and continue communication about the alert. If not selected, each recipient receives a separate alert message.

  • Reply-To (optional)

    The email address recipients should reply to if necessary.

  • Sender (optional)

    The email address that is used as the sending address. If the field is left empty, the default address is used.

  • User recipient(s) (optional)

    Select Security Data Lake users to add to the To line for the alert.

  • Email recipient(s) (optional)

    Add any additional email addresses to To line for the alert.

  • CC User(s) (optional)

    Select Security Data Lake users to add to the CC line for the alert.

  • CC Email(s) (optional)

    Add any additional email addresses to CC line for the alert.

  • BCC User(s) (optional)

    Select Security Data Lake users to add to the BCC line for the alert.

  • BCC Email(s) (optional)

    Add any additional email addresses to BCC line for the alert.

  • Time zone for date/time values (optional)

    You can opt to use a specific time zone for the body of the email.

  • Body Template

    This is the template used to generate the email body. As noted above, the email body is a JMTE template.

  • HTML Body Template

    This is the template used to generate the email HTML body.

Dynamic Email Notification Addresses

Security Data Lake allows email notifications to be sent to multiple recipients. A single event definition is paired with a notification forming an alert that can be emailed to multiple email addresses using a lookup table.

The Reply-To email, Sender email, and Email Recipients values can be modified to use a lookup table by checking the relevant box. You may then select:

  • The lookup table you want to use.

  • The event field to use for the lookup.

For example, by checking the Use lookup table for email recipients box, you can set the email notification to send the alert to a customer found in a lookup table that relates customer IDs with email addresses. This way, you do not have to set up individual alerts for multiple clients. The lookup table does the mapping.

HTTP Alerts

HTTP alerts allow you to configure an endpoint that is called when the alert is triggered.

Security Data Lake sends a POST request to the alert URL, including information about the alert. The body of the request is the JSON encoded data described above.

Here is an example of the payload included in an alert:

{
  "event_definition_id": "this-is-a-test-notification",
  "event_definition_type": "test-dummy-v1",
  "event_definition_title": "Event Definition Test Title",
  "event_definition_description": "Event Definition Test Description",
  "job_definition_id": "<unknown>",
  "job_trigger_id": "<unknown>",
  "event": {
    "id": "NotificationTestId",
    "event_definition_type": "notification-test-v1",
    "event_definition_id": "EventDefinitionTestId",
    "origin_context": "urn:graylog:message:es:testIndex_42:b5e53442-12bb-4374-90ed-0deadbeefbaz",
    "timestamp": "2020-05-20T11:35:11.117Z",
    "timestamp_processing": "2020-05-20T11:35:11.117Z",
    "timerange_start": null,
    "timerange_end": null,
    "streams": [
      "000000000000000000000002"
    ],
    "source_streams": [],
    "message": "Notification test message triggered from user <admin>",
    "source": "000000000000000000000001",
    "key_tuple": [
      "testkey"
    ],
    "key": "testkey",
    "priority": 2,
    "alert": true,
    "fields": {
      "field1": "value1",
      "field2": "value2"
    }
  },
  "backlog": []
}

These are the supported configuration options to be defined in the New Notification menu for HTTP alerts:

  • URL

    The URL to POST to when an event occurs.

  • Skip TLS Verification (optional)

    Select this option to omit performing a TLS certification of the URL.

  • Basic Authentication (optional)

    The Basic authentication string needs to follow this format: <username>:<password>.

  • API Key (optional)

    Enter an optional API key if preferred. Note that if an API secret is set, an API key must also be set.

  • API Secret (optional)

    Enter an optional secret if preferred. Note that if an API secret is set, an API key must also be set.

  • Note

    If this notification calls the Security Data Lake REST API, in addition to providing proper authorization, you must add a header named X-Requested-By. Without this header, the Security Data Lake API rejects the call.

  • event_definition_id=NotificationTestId&event_definition_type=test-dummy-v1&event_definition_title=Event%20Definition%20Test%20Title&event_definition_description=Event%20Definition%20Test%20Description&job_definition_id=%3Cunknown%3E&job_trigger_id=%3Cunknown%3E&event_id=TEST_NOTIFICATION_ID&event_origin_context=urn%3Agraylog%3Amessage%3Aes%3AtestIndex_42%3Ab5e53442-12bb-4374-90ed-0deadbeefbaz&event_timestamp=2023-11-17T11%3A49%3A40.905-06%3A00&event_timestamp_processing=2023-11-17T11%3A49%3A40.905-06%3A00&event_timerange_start=&event_timerange_end=&event_streams=%5B000000000000000000000002%5D&event_source_streams=%5B%5D&event_message=Notification%20test%20message%20triggered%20from%20user%20%3Clocal%3Aadmin%3E&event_source=000000000000000000000001&event_key_tuple=%5Btestkey%5D&event_key=testkey&event_priority=2&event_fields=%7Bfield1%3Dvalue1%2C%20field2%3Dvalue2%7D&backlog=%5B%5D