Application performance monitoring in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Understanding APM transaction search query output

You run this Elasticsearch query to find APM transactions with duration over 500ms:

{
  "query": {
    "range": {
      "transaction.duration.us": { "gt": 500000 }
    }
  }
}

What does the query output represent?

Elasticsearch

{
  "query": {
    "range": {
      "transaction.duration.us": { "gt": 500000 }
    }
  }
}

A Documents where transaction duration is missing

B Documents where transaction duration equals exactly 500 milliseconds

C Documents where transaction duration is greater than 500 milliseconds

D Documents where transaction duration is less than 500 milliseconds

💡 Hint

Look at the 'range' query and the 'gt' operator meaning.

The 'range' query with 'gt' means 'greater than'. The field 'transaction.duration.us' is in microseconds, so 500000 us equals 500 ms. The query returns documents with duration above 500 ms.

🧠 Conceptual

intermediate

Purpose of APM agents in application monitoring

What is the main role of an APM agent installed in an application?

A Collect performance data and send it to the APM server

B Store logs locally on the application server

C Replace the application’s database for faster queries

D Manage user authentication and authorization

💡 Hint

Think about what data helps monitor app performance remotely.

APM agents collect metrics like response times, errors, and traces from the application and send them to the APM server for analysis.

❓ Troubleshoot

advanced

Diagnosing missing APM data in Elasticsearch

You notice no APM transaction data appears in Elasticsearch after deploying the agent. Which is the most likely cause?

A The APM server is running on a different port than Elasticsearch

B Elasticsearch cluster is running out of disk space

C The application code has no functions

D The APM agent is not configured with the correct server URL

💡 Hint

Check the agent’s connection settings to the APM server.

If the agent cannot reach the APM server due to wrong URL, no data will be sent and stored in Elasticsearch.

🔀 Workflow

advanced

Steps to set up APM monitoring for a new service

What is the correct order of steps to enable APM monitoring for a new application service?

A 1,2,3,4

B 2,1,3,4

C 2,3,1,4

D 1,3,2,4

💡 Hint

Think about infrastructure setup before code changes.

First set up the APM server and Elasticsearch, then install the agent, deploy the app, and finally check the UI.

✅ Best Practice

expert

Choosing the best APM data retention strategy

Your Elasticsearch cluster stores APM data for 90 days but is running low on disk space. What is the best practice to manage data retention without losing critical monitoring info?

A Use ILM (Index Lifecycle Management) to delete old data and keep recent data optimized

B Manually delete random old indices to free space

C Increase the cluster size without changing retention policies

D Disable APM data collection temporarily

💡 Hint

Think about automated management of data lifecycle.

ILM automates moving data through phases like hot, warm, and delete, preserving important data while freeing space.

Practice

1. What is the main purpose of Application Performance Monitoring (APM) in Elasticsearch?

easy

A. To track application speed and detect errors

B. To store user login credentials securely

C. To manage Elasticsearch cluster nodes

D. To backup Elasticsearch indexes automatically

Solution

1. Step 1: Understand APM's role

   APM is designed to monitor how fast an application runs and to find any errors it produces.

2. Step 2: Match purpose with options

   Only To track application speed and detect errors describes tracking speed and errors, which fits APM's main goal.

3. Final Answer:

   To track application speed and detect errors -> Option A

4. Quick Check:

   APM purpose = Track speed and errors [OK]

Hint: APM = watch app speed and errors [OK]

Common Mistakes:

• Confusing APM with security or backup tools
• Thinking APM manages cluster nodes
• Assuming APM stores user credentials

2. Which Elasticsearch query syntax correctly calculates the average response time from APM data?

easy

A. POST /apm-*/_update_by_query {"script": {"source": "ctx._source.duration = 0"}}

B. GET /apm-*/_search {"query": {"match_all": {}}, "size":10}

C. GET /apm-*/_search {"size":0, "aggs": {"avg_response_time": {"avg": {"field": "transaction.duration.us"}}}}

D. GET /apm-*/_search {"aggs": {"max_response_time": {"max": {"field": "transaction.duration.us"}}}}

Solution

1. Step 1: Identify aggregation for average

   The query uses "avg" aggregation on the field "transaction.duration.us" which stores response times in microseconds.

2. Step 2: Confirm query structure

   Size is 0 to avoid returning documents, focusing only on aggregation results, which is correct for average calculation.

3. Final Answer:

   GET /apm-*/_search {"size":0, "aggs": {"avg_response_time": {"avg": {"field": "transaction.duration.us"}}}} -> Option C

4. Quick Check:

   Average aggregation query = GET /apm-*/_search {"size":0, "aggs": {"avg_response_time": {"avg": {"field": "transaction.duration.us"}}}} [OK]

Hint: Average uses "avg" aggregation with size 0 [OK]

Common Mistakes:

• Using match_all without aggregation
• Using update_by_query instead of search
• Using max aggregation instead of avg

3. Given this Elasticsearch aggregation query on APM data, what is the expected output?

GET /apm-*/_search
{
  "size": 0,
  "aggs": {
    "avg_response_time": {
      "avg": { "field": "transaction.duration.us" }
    }
  }
}

medium

A. {"aggregations":{"max_response_time":{"value":500000}}}

B. {"hits":{"total":100}}

C. {"error":"Field not found"}

D. {"aggregations":{"avg_response_time":{"value":250000}}}

Solution

1. Step 1: Understand aggregation type

   The query requests the average of the field "transaction.duration.us" which holds response times in microseconds.

2. Step 2: Match output to aggregation

   The output shows an aggregation named "avg_response_time" with a numeric value representing the average, matching {"aggregations":{"avg_response_time":{"value":250000}}}.

3. Final Answer:

   {"aggregations":{"avg_response_time":{"value":250000}}} -> Option D

4. Quick Check:

   Average aggregation output = {"aggregations":{"avg_response_time":{"value":250000}}} [OK]

Hint: Aggregation output shows "aggregations" with average value [OK]

Common Mistakes:

• Confusing hits total with aggregation result
• Expecting max instead of avg
• Assuming error without checking field existence

4. You run this Elasticsearch query to get average response time but get an error: Fielddata is disabled on text fields by default. What is the likely cause?

medium

A. Trying to aggregate on a text field instead of a numeric field

B. Using the wrong index pattern in the query

C. Missing authentication credentials

D. Query syntax error in aggregation block

Solution

1. Step 1: Analyze error message

   The error says fielddata is disabled on text fields, which means aggregation was attempted on a text field.

2. Step 2: Understand aggregation requirements

   Aggregations like average require numeric fields, so using a text field causes this error.

3. Final Answer:

   Trying to aggregate on a text field instead of a numeric field -> Option A

4. Quick Check:

   Fielddata error = Aggregation on text field [OK]

Hint: Average needs numeric field, not text [OK]

Common Mistakes:

• Blaming index pattern or auth for this error
• Assuming syntax error without checking field type
• Ignoring field data type requirements

5. You want to monitor the average response time for your app but only for transactions with errors. Which Elasticsearch query snippet correctly filters and calculates this?

hard

A. { "size": 0, "query": { "term": { "error.id": "" } }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } }

B. { "size": 0, "query": { "exists": { "field": "error.id" } }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } }

C. { "size": 0, "query": { "match_all": {} }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } }

D. { "size": 0, "query": { "term": { "transaction.status": "success" } }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } }

Solution

1. Step 1: Identify filter for transactions with errors

   Transactions with errors have a non-empty "error.id" field, so we use "exists" query on "error.id".

2. Step 2: Confirm aggregation on filtered data

   The aggregation calculates average response time only on filtered documents, which is correct.

3. Final Answer:

   { "size": 0, "query": { "exists": { "field": "error.id" } }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } } -> Option B

4. Quick Check:

   Filter errors with exists + avg aggregation = { "size": 0, "query": { "exists": { "field": "error.id" } }, "aggs": { "avg_response_time": { "avg": { "field": "transaction.duration.us" } } } } [OK]

Hint: Use exists query to filter error transactions [OK]

Common Mistakes:

• Using empty term query instead of exists
• Calculating average without filtering errors
• Filtering for success instead of errors