Alerting and notifications in Elasticsearch - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define an alert condition that triggers when the CPU usage is above 80%.

Elasticsearch

{
  "trigger": {
    "name": "High CPU Usage",
    "condition": {
      "script": {
        "source": "return ctx.payload.cpu > [1];"
      }
    }
  }
}

Drag options to blanks, or click blank then click option'

A90

B100

C80

D70

Attempts:

3 left

💡 Hint

Common Mistakes

Using a threshold lower than 80 causes false alerts.

Using a threshold higher than 80 delays alerting.

The alert triggers when CPU usage is greater than 80%, so the correct value is 80.

2fill in blank

medium

Complete the code to send an email notification when the alert triggers.

Elasticsearch

{
  "actions": {
    "send_email": {
      "email": {
        "to": "[e-mail]",
        "subject": "Alert: CPU Usage High",
        "body": {
          "text": "CPU usage has exceeded [1]%."
        }
      }
    }
  }
}

Drag options to blanks, or click blank then click option'

A80

B70

C90

D100

Attempts:

3 left

💡 Hint

Common Mistakes

Mismatching the threshold in the email message.

Using an incorrect percentage in the notification.

The email body should mention the threshold that triggers the alert, which is 80% CPU usage.

3fill in blank

hard

Fix the error in the alert condition script to correctly check if memory usage is below 30%.

Elasticsearch

{
  "trigger": {
    "name": "Low Memory Usage",
    "condition": {
      "script": {
        "source": "return ctx.payload.memory [1] 30;"
      }
    }
  }
}

Drag options to blanks, or click blank then click option'

A<

B==

C>

D>=

Attempts:

3 left

💡 Hint

Common Mistakes

Using > instead of < causes the alert to trigger incorrectly.

Using equality operator == does not cover below threshold.

The condition should check if memory usage is less than 30%, so the operator is <.

4fill in blank

hard

Fill both blanks to create a dictionary alert that maps each server to its disk usage percentage, but only include servers with usage above 75%.

Elasticsearch

{
  "disk_alerts": {
    [1]: [2] for server, usage in servers.items() if usage > 75
  }
}

Drag options to blanks, or click blank then click option'

Aserver

Busage

Cserver.upper()

Dusage + 5

Attempts:

3 left

💡 Hint

Common Mistakes

Using transformed keys or values that don't match the original data.

Including servers with usage below or equal to 75%.

The dictionary comprehension maps each server name to its usage, filtering for usage above 75%.

5fill in blank

hard

Fill all three blanks to create an alert action that logs the alert name, the triggered condition, and the timestamp.

Elasticsearch

{
  "actions": {
    "log_alert": {
      "logging": {
        "text": "Alert [1] triggered because [2] at [3]"
      }
    }
  }
}

Drag options to blanks, or click blank then click option'

Actx.trigger.name

Bctx.condition.name

Cctx.execution_time

Dctx.payload.value

Attempts:

3 left

💡 Hint

Common Mistakes

Using incorrect context variables that do not exist.

Mixing up the order of variables in the log message.

The log message includes the alert name, the condition name, and the execution timestamp from the context.

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