Infrastructure monitoring in Elasticsearch - Step-by-Step Execution

Concept Flow - Infrastructure monitoring

Start Monitoring Setup

↓

Install Metricbeat

↓

Configure Metricbeat to collect system metrics

↓

Start Metricbeat Service

↓

Metricbeat sends data to Elasticsearch

↓

Elasticsearch stores metrics

↓

Use Kibana to visualize metrics

↓

Analyze system health and performance

↓

Adjust monitoring or alerting as needed

↓

End

This flow shows how Metricbeat collects system metrics, sends them to Elasticsearch, and how Kibana visualizes them for monitoring infrastructure health.

Execution Sample

Elasticsearch

metricbeat setup
sudo systemctl start metricbeat
curl -X GET "localhost:9200/_cat/indices?v"
curl -X GET "localhost:9200/metricbeat-*/_search?size=1"

This sequence sets up Metricbeat, starts it, then queries Elasticsearch to check metric data indices and sample documents.

Execution Table

Step	Action	Command/Query	Result/Output
1	Setup Metricbeat dashboards and index templates	metricbeat setup	Loaded dashboards, index templates, and ILM policies successfully
2	Start Metricbeat service to begin data collection	sudo systemctl start metricbeat	Metricbeat service started and running
3	Check Elasticsearch indices for Metricbeat data	curl -X GET "localhost:9200/_cat/indices?v"	List shows metricbeat-7.x.x-YYYY.MM.DD index with document count > 0
4	Query a sample document from Metricbeat index	curl -X GET "localhost:9200/metricbeat-*/_search?size=1"	Returns JSON with system metrics like CPU, memory usage
5	End		Monitoring data is flowing and stored in Elasticsearch

💡 Metricbeat is running and sending system metrics to Elasticsearch indices, ready for visualization.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Metricbeat Service Status	Stopped	Stopped	Running	Running	Running	Running
Elasticsearch Indices	None	Templates loaded	Templates loaded	metricbeat-7.x.x-YYYY.MM.DD created	metricbeat index has documents	metricbeat index has documents
Metric Data Documents	0	0	0	>0	>0	>0

Key Moments - 3 Insights

Why do we run 'metricbeat setup' before starting the service?

The 'metricbeat setup' command loads dashboards and index templates into Elasticsearch, preparing it to store and visualize the incoming data correctly, as shown in step 1 of the execution table.

How do we know Metricbeat is successfully sending data to Elasticsearch?

Step 3 and 4 show Elasticsearch indices exist and contain documents with system metrics, confirming data flow from Metricbeat.

What does the 'curl' command in step 4 return?

It returns a JSON document with system metrics like CPU and memory usage, demonstrating that monitoring data is stored and queryable.

Visual Quiz - 3 Questions

Look at the execution table, what is the Metricbeat service status after step 2?

A Stopped

B Running

C Failed

D Starting

💡 Hint

Check the 'Metricbeat Service Status' variable in variable_tracker after step 2.

At which step do Elasticsearch indices for Metricbeat data first appear?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Elasticsearch Indices' variable in variable_tracker and the execution_table rows.

If Metricbeat was not sending data, what would the output of step 4 likely show?

A Empty hits array or no documents

B Error connecting to Elasticsearch

C JSON with system metrics

D List of dashboards

💡 Hint

Step 4 shows a sample document; if no data, the hits array would be empty.

Concept Snapshot

Infrastructure Monitoring with Metricbeat and Elasticsearch:
- Run 'metricbeat setup' to load dashboards and templates.
- Start Metricbeat service to collect system metrics.
- Metricbeat sends data to Elasticsearch indices.
- Use Kibana to visualize and analyze metrics.
- Monitor CPU, memory, disk, and network health.
- Adjust alerts based on metric trends.

Full Transcript

Infrastructure monitoring with Elasticsearch involves installing Metricbeat on your system to collect metrics like CPU and memory usage. First, you run 'metricbeat setup' to prepare Elasticsearch with dashboards and templates. Then, you start the Metricbeat service to begin sending data. You can verify data flow by querying Elasticsearch indices and checking for metric documents. This setup allows you to visualize system health in Kibana and respond to performance issues quickly.

Practice

1. What is the primary purpose of infrastructure monitoring in Elasticsearch?

easy

A. To create user accounts and manage permissions

B. To store large amounts of data permanently

C. To watch system health and detect issues early

D. To design the user interface of Kibana dashboards

Solution

1. Step 1: Understand infrastructure monitoring

   Infrastructure monitoring means watching your systems to keep them healthy and catch problems early.

2. Step 2: Relate to Elasticsearch context

   Elasticsearch provides APIs to check cluster and node status, which helps monitor system health.

3. Final Answer:

   To watch system health and detect issues early -> Option C

4. Quick Check:

   Infrastructure monitoring = watch health early [OK]

Hint: Monitoring means watching system health regularly [OK]

Common Mistakes:

• Confusing monitoring with data storage
• Thinking monitoring manages user accounts
• Mixing monitoring with UI design

2. Which Elasticsearch API command correctly checks the cluster health status?

easy

A. GET /_cluster/health

B. POST /_cluster/status

C. GET /_nodes/stats

D. PUT /_cluster/health

Solution

1. Step 1: Identify the correct HTTP method and endpoint

   The cluster health API uses GET method and the endpoint is /_cluster/health.

2. Step 2: Eliminate incorrect options

   POST and PUT are not used for checking health; /_nodes/stats gives node stats, not cluster health.

3. Final Answer:

   GET /_cluster/health -> Option A

4. Quick Check:

   Cluster health API = GET /_cluster/health [OK]

Hint: Use GET method with /_cluster/health to check status [OK]

Common Mistakes:

• Using POST or PUT instead of GET
• Confusing node stats with cluster health
• Using wrong endpoint paths

3. What will be the output status field when you run GET /_cluster/health on a healthy Elasticsearch cluster?

medium

A. { \"status\": \"red\" }

B. { \"status\": \"green\" }

C. { \"status\": \"yellow\" }

D. { \"status\": \"blue\" }

Solution

1. Step 1: Understand cluster health status colors

   Green means all primary and replica shards are active, so cluster is healthy.

2. Step 2: Match output with healthy cluster

   Healthy cluster returns status as "green" in the JSON response.

3. Final Answer:

   { "status": "green" } -> Option B

4. Quick Check:

   Healthy cluster status = green [OK]

Hint: Green status means cluster is fully healthy [OK]

Common Mistakes:

• Confusing yellow or red as healthy
• Expecting blue status which does not exist
• Misreading JSON output format

4. You run GET /_nodes/stats but get a 404 error. What is the most likely cause?

medium

A. The API endpoint is incorrect or misspelled

B. You used POST instead of GET method

C. The cluster is down and unreachable

D. The node stats API requires authentication

Solution

1. Step 1: Understand 404 error meaning

   404 means the requested URL or endpoint does not exist on the server.

2. Step 2: Check API endpoint correctness

   If the endpoint is misspelled or wrong, 404 occurs. The correct endpoint is /_nodes/stats.

3. Final Answer:

   The API endpoint is incorrect or misspelled -> Option A

4. Quick Check:

   404 error = wrong endpoint [OK]

Hint: 404 means wrong URL or endpoint [OK]

Common Mistakes:

• Assuming cluster down causes 404 (usually connection error)
• Confusing 404 with authentication errors
• Using wrong HTTP method but expecting 404

5. You want to monitor Elasticsearch nodes for CPU and memory usage continuously. Which approach is best?

hard

A. Restart nodes frequently to reset CPU and memory usage

B. Use GET /_cluster/health to check CPU and memory

C. Install Kibana and create dashboards without data collection

D. Run GET /_nodes/stats regularly and parse CPU/memory fields

Solution

1. Step 1: Identify API for node resource stats

   The /_nodes/stats API provides detailed CPU and memory usage per node.

2. Step 2: Understand monitoring approach

   Regularly running this API and parsing results allows continuous monitoring of resource usage.

3. Final Answer:

   Run GET /_nodes/stats regularly and parse CPU/memory fields -> Option D

4. Quick Check:

   Node stats API for CPU/memory monitoring [OK]

Hint: Use /_nodes/stats API for detailed resource monitoring [OK]

Common Mistakes:

• Using cluster health API which lacks CPU/memory details
• Assuming Kibana dashboards work without data
• Restarting nodes does not monitor usage