Alerting and notifications in Elasticsearch - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of alerting in Elasticsearch?

Alerting in Elasticsearch helps you monitor your data and get notified automatically when certain conditions or thresholds are met, so you can react quickly to important events.

beginner

Name the main components involved in Elasticsearch alerting.

The main components are:
1. Monitors - define what to watch and how often.
2. Triggers - define conditions that cause alerts.
3. Actions - define what happens when a trigger fires, like sending notifications.

intermediate

How do you define a trigger condition in Elasticsearch alerting?

A trigger condition is defined using a query or script that checks if data meets certain criteria. When the condition is true, the trigger activates and runs its actions.

beginner

What types of notification channels can Elasticsearch alerting use?

Elasticsearch alerting supports multiple notification channels like email, Slack, webhooks, PagerDuty, and custom integrations to send alerts to the right people or systems.

intermediate

Explain how a monitor schedule affects alerting in Elasticsearch.

The monitor schedule sets how often Elasticsearch checks the data for trigger conditions. A shorter schedule means faster alerts but more resource use; a longer schedule means slower alerts but less load.

What does a monitor do in Elasticsearch alerting?

A Checks data regularly to find issues

B Sends notifications to users

C Stores alert history

D Defines user permissions

A monitor regularly checks your data to see if any trigger conditions are met.

Which component defines the condition that triggers an alert?

A Trigger

B Monitor

C Action

D Dashboard

Triggers define the specific conditions that cause alerts to fire.

Which notification channel is NOT commonly supported by Elasticsearch alerting?

A Email

B SMS

C Webhooks

D Slack

SMS is not a default notification channel in Elasticsearch alerting; others like email, Slack, and webhooks are supported.

What happens when a trigger condition is met?

A The Elasticsearch cluster restarts

B The monitor stops running

C Data is deleted

D An action is executed to notify

When a trigger condition is true, the defined actions run to notify users or systems.

Why is the monitor schedule important?

A It stores alert messages

B It sets user access levels

C It controls how often alerts are checked

D It formats notification emails

The monitor schedule controls how often Elasticsearch checks for alert conditions.

Describe the process of setting up alerting in Elasticsearch from monitor creation to notification.

Think about the steps from watching data to sending alerts.

Explain why choosing the right monitor schedule is important for alerting performance and responsiveness.

Consider what happens if you check too often or too rarely.

Practice

1. What is the main purpose of alerting in Elasticsearch?

easy

A. To automatically notify you when certain data conditions are met

B. To store large amounts of data efficiently

C. To visualize data in dashboards

D. To backup Elasticsearch indices

Solution

1. Step 1: Understand alerting concept

   Alerting watches your data and triggers notifications when specific conditions happen.

2. Step 2: Identify main purpose

   The main goal is to notify users automatically about important data changes or events.

3. Final Answer:

   To automatically notify you when certain data conditions are met -> Option A

4. Quick Check:

   Alerting = automatic notifications [OK]

Hint: Alerting means automatic notifications on data changes [OK]

Common Mistakes:

• Confusing alerting with data storage
• Thinking alerting is for data visualization
• Mixing alerting with backup processes

2. Which of the following is the correct syntax to define a trigger in an Elasticsearch alerting watch?

easy

A. "trigger": { "schedule": { "interval": "10m" } }

B. "trigger": "interval": "10m"

C. "trigger": { "interval": "10m" }

D. "trigger": { "time": "10m" }

Solution

1. Step 1: Recall trigger syntax in watch

   Triggers use a schedule object with an interval field inside curly braces.

2. Step 2: Match correct JSON structure

   "trigger": { "schedule": { "interval": "10m" } } correctly nests schedule and interval inside trigger with proper braces and quotes.

3. Final Answer:

   "trigger": { "schedule": { "interval": "10m" } } -> Option A

4. Quick Check:

   Trigger uses schedule with interval [OK]

Hint: Trigger syntax always nests schedule and interval inside braces [OK]

Common Mistakes:

• Missing braces around schedule
• Using wrong keys like 'time' instead of 'schedule'
• Incorrect JSON structure without nested objects

3. Given this watch input snippet, what type of input is being used?

{
  "input": {
    "search": {
      "request": {
        "indices": ["logs"],
        "body": {
          "query": { "match_all": {} }
        }
      }
    }
  }
}

medium

A. Webhook input

B. HTTP input

C. Search input

D. Script input

Solution

1. Step 1: Identify input type from JSON keys

   The input uses the key "search" with a request containing indices and a query.

2. Step 2: Match input type to Elasticsearch alerting inputs

   This matches the Search input type, which runs a search query on indices.

3. Final Answer:

   Search input -> Option C

4. Quick Check:

   Input with "search" key = Search input [OK]

Hint: Look for 'search' key to identify Search input type [OK]

Common Mistakes:

• Confusing search input with HTTP or webhook inputs
• Ignoring the 'search' key and guessing script input
• Not recognizing the query structure inside input

4. You wrote this action in your watch but it fails to send an email:

"actions": {
  "send_email": {
    "email": {
      "to": "[e-mail]",
      "subject": "Alert!",
      "body": "Condition met"
    }
  }
}

What is the likely error?

medium

A. Incorrect 'to' email format

B. Body must be an object, not a string

C. Missing 'trigger' section in watch

D. Missing 'from' field in email action

Solution

1. Step 1: Check required fields for email action

   Email action requires a 'from' field to specify sender address.

2. Step 2: Identify missing 'from' field

   The given action lacks the 'from' field, causing failure to send email.

3. Final Answer:

   Missing 'from' field in email action -> Option D

4. Quick Check:

   Email action needs 'from' field [OK]

Hint: Email actions always need a 'from' address [OK]

Common Mistakes:

• Assuming 'to' format is wrong when it is correct
• Forgetting to add 'from' sender email
• Thinking trigger absence causes email failure

5. You want to create an alert that sends a Slack message only if the number of errors in logs exceeds 100 in the last 5 minutes. Which condition correctly implements this in the watch?

hard

A. "condition": { "script": { "source": "return ctx.payload.hits.total.value > 100" } }

B. "condition": { "compare": { "ctx.payload.hits.total.value": { "gt": 100 } } }

C. "condition": { "script": { "source": "return ctx.payload.hits.total > 100" } }

D. "condition": { "compare": { "ctx.payload.hits.total": { "gte": 100 } } }

Solution

1. Step 1: Understand payload structure for hits total

   In Elasticsearch 7+, total hits count is accessed as ctx.payload.hits.total.value.

2. Step 2: Choose correct condition syntax

   The compare condition with 'gt' operator on ctx.payload.hits.total.value correctly checks if errors exceed 100.

3. Final Answer:

   "condition": { "compare": { "ctx.payload.hits.total.value": { "gt": 100 } } } -> Option B

4. Quick Check:

   Use compare with ctx.payload.hits.total.value > 100 [OK]

Hint: Use compare on ctx.payload.hits.total.value for counts [OK]

Common Mistakes:

• Using ctx.payload.hits.total instead of .value
• Using script with wrong field name
• Using 'gte' instead of 'gt' when strictly greater needed