LAB ‐ TestD - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

OCI Native Dashboard - Multi-VM Lifecycle Monitoring

1. Objective

The objective of this lab is to create an OCI Native Dashboard to monitor multiple virtual machines (VMs) across different compartments from a single dashboard.

Using this dashboard, we can view resource information, check VM lifecycle states, and automatically refresh the dashboard at a configured interval.

What We Achieved

  • Created a custom OCI Native Dashboard.
  • Added Resource Explorer widgets for different compartments.
  • Viewed Compute instances across multiple compartments.
  • Added a Resource Query widget to display VM lifecycle states.
  • Verified Running, Stopped, and Terminated instance states.
  • Enabled automatic refresh every 5 minutes.
  • Verified automatic dashboard refresh without manually refreshing the browser page.

2. What Is an OCI Native Dashboard?

An OCI Native Dashboard is a customizable interface in Oracle Cloud Infrastructure (OCI) that allows us to display cloud resource information and monitoring data in one place.

Instead of opening multiple OCI services and compartments separately, we can create a dashboard containing different widgets.

What Can We Do with OCI Dashboards?

  • View Compute instances and other OCI resources.
  • Display resource information from selected compartments.
  • Display metrics using Monitoring widgets.
  • Query cloud resources using Resource Query widgets.
  • View instance lifecycle states such as Running, Stopped, and Terminated when returned by the query.
  • Configure automatic dashboard refresh.
  • Create a centralized view of resources for operational monitoring.

Note: A dashboard does not replace OCI Monitoring, Logging, Cloud Guard, or other security services. It brings selected resource information and metrics together in one interface.

3. Lab Environment

Setting Value
Cloud Provider Oracle Cloud Infrastructure (OCI)
Region US East (Ashburn)
Region Identifier us-ashburn-1
Parent Compartment swiggy-dev-compartment
Dashboard Name Swiggy-Multi-VM-Monitoring
Auto Refresh Every 5 minutes

Compartment Structure

The lab uses the following compartment structure:

  • swiggy-dev-compartment
    • swiggy-dev-compute-and-storage-compartment
      • dev-app-server
      • dev-db-server
    • swiggy-dev-network-compartment
      • dev-web-server

The instances are distributed across two child compartments. This demonstrates how we can view resources from different parts of an OCI environment using a centralized dashboard.

4. Step 1 - Open OCI Dashboards

  1. Log in to the OCI Console.
  2. Open the Dashboards service.
  3. Create a new dashboard.
  4. Enter the dashboard name: Swiggy-Multi-VM-Monitoring.
  5. Save the dashboard.

The dashboard provides a workspace where we can add widgets for resource information and monitoring metrics.

5. Step 2 - Add the Resource Explorer Widget for Compute and Storage

We added a Resource Explorer widget to view resources from the Compute and Storage compartment.

Configuration

  • Widget Type: Resource Explorer
  • Region: US East (Ashburn)
  • Compartment: swiggy-dev-compute-and-storage-compartment

Result

The widget displayed:

  • Compute - Instances: 2

The two instances configured in this compartment were:

  • dev-app-server
  • dev-db-server

This widget helps us view the resource count for the selected compartment without navigating to the Compute service separately.

6. Step 3 - Add the Resource Explorer Widget for the Network Compartment

We added another Resource Explorer widget for the Network compartment.

Configuration

  • Widget Type: Resource Explorer
  • Region: US East (Ashburn)
  • Compartment: swiggy-dev-network-compartment

Result

The widget displayed:

  • Compute - Instances: 1
  • Virtual Cloud Networks - VCNs: 1

The instance in this compartment was:

  • dev-web-server

This widget helps us view the web server and relevant network resource counts in the Network compartment.

7. Step 4 - Understand the Default Root Compartment Widget

A Resource Explorer widget for the root compartment, cloudtenant26, was also present on the dashboard.

It displayed resources such as:

  • Application Integration - Notifications
  • Events Service - Rules

This widget was not specifically configured to monitor our three VMs.

Important Point

The root compartment widget displays resources within its selected scope. It does not automatically provide the lifecycle status of every instance in every child compartment.

For VM lifecycle monitoring, we used a separate Resource Query widget.

8. Step 5 - Add a Monitoring Widget for Web Server Health

We added a Monitoring widget named:

Swiggy-Web-Server-Health

Configuration

  • Widget Type: Monitoring
  • Region: US East (Ashburn)
  • Namespace: oci_compute_instance_health
  • Metric Name: InstanceAccessibilityStatus
  • Dimension: resourceDisplayName = dev-web-server
  • Description: Monitor Web Server accessibility health metrics in the Swiggy Network compartment.

Purpose

This widget is intended to display the selected Compute instance accessibility health metric.

The chart did not display a clear Running or Stopped lifecycle state because instance accessibility health and instance lifecycle state are different concepts.

  • Lifecycle state tells us whether an instance is Running, Stopped, Terminated, or in another lifecycle state.
  • Accessibility health metrics provide information about the instance's accessibility according to the metric definition.

For lifecycle-state monitoring, we used the Resource Query widget in the next step.

9. Step 6 - Add the Resource Query Widget

This was the main step in our multi-VM monitoring lab.

We added a Resource Query widget and named it:

Swiggy-All-VM-Lifecycle-Status

This widget displays the results of a resource query in a table.

Configuration Steps

  1. Open the dashboard.
  2. Click Add widget.
  3. Select the Resource Query widget.
  4. Enter the widget name: Swiggy-All-VM-Lifecycle-Status.
  5. Open the query editor.
  6. Enter the resource query.
  7. Click Search to execute the query.
  8. Review the Resource Preview and results.
  9. Save the widget and dashboard.

Query 1 - Display Instance Resources

The main query used in the lab was:

query instance resources

This query searches instance resources within the applicable query scope. The results can include lifecycle status and other resource information.

Query 2 - Display Only Running Instances

Initially, we used a query that filtered for Running instances:

query instance resources where lifeCycleState = 'RUNNING'

This query returns instances whose lifecycle state matches RUNNING.

Query 3 - Display Running and Stopped Instances

To return only Running and Stopped instances, we tested the following query:

query instance resources where lifeCycleState = 'RUNNING' || lifeCycleState = 'STOPPED'

The || operator means OR.

This query filters the results to instances whose lifecycle state is either Running or Stopped. Terminated instances are excluded by this filter.

Note: The unfiltered query is more suitable when we want to inspect all available lifecycle states, including Terminated instances when they are still returned by the query.

10. Step 7 - Verify the VM Lifecycle Status

After configuring the Resource Query widget, we verified the results in the dashboard.

The widget displayed a table with the following columns:

  • Display name
  • Resource Type
  • Status
  • OCID
  • Compartment
  • Time created

Observed Results

During the lab, the table displayed the following states:

Instance Name Observed Status
dev-web-server Running
dev-app-server Stopped
dev-db-server Terminated

These are the states observed during the practical test, not permanent states for these resources.

Understanding the Lifecycle States

Running: The instance is running.

Stopped: The instance is stopped but has not been terminated. It can generally be started again.

Terminated: The instance has been terminated. It cannot be restarted as the same instance.

Important: Stopping and terminating an instance are different operations. Termination can be destructive, so verify the instance and its associated resources before selecting Terminate.

11. Step 8 - Enable Automatic Dashboard Refresh

After verifying the lifecycle query, we configured automatic refresh.

Configuration Steps

  1. Open the Swiggy-Multi-VM-Monitoring dashboard.
  2. Locate the Auto refresh option.
  3. Select Every 5 minutes.
  4. Leave the dashboard open.
  5. Do not manually refresh the browser page.
  6. Wait for the next automatic refresh.

Practical Verification

We waited for the five-minute interval to complete.

The dashboard refreshed automatically without manually refreshing the browser page.

The terminated instance continued to appear with the Terminated status in the Resource Query table.

Result

This verified that automatic dashboard refresh was working.

Important: Auto refresh updates the dashboard view, but it does not change an instance's lifecycle state. The resource query and underlying inventory must return the latest available information for a state change to appear. Some resource updates may take time to become visible.

12. Final Dashboard Design

Our dashboard contains the following widgets:

Widget Name Purpose
Resource Explorer - Compute and Storage View resource counts in the Compute and Storage compartment
Swiggy-Web-Server-Health Display the selected web server accessibility health metric
Resource Explorer - Network View Compute instances and VCN counts in the Network compartment
Resource Explorer - Root Compartment View selected resources within the root compartment
Swiggy-All-VM-Lifecycle-Status Display instance lifecycle states in a table

Automatic refresh is configured to run every 5 minutes.

Architecture Overview

The dashboard architecture is as follows:

  1. OCI Console
  2. Swiggy-Multi-VM-Monitoring dashboard
  3. Resource Explorer widgets for Compute and Storage, Network, and Root compartments
  4. Monitoring widget for the web server accessibility metric
  5. Resource Query widget for VM lifecycle states
  6. Instances displayed in the lifecycle table:
    • dev-web-server - Running
    • dev-app-server - Stopped
    • dev-db-server - Terminated

The instance states shown above represent the observed lab results and can change as resources are started, stopped, or terminated.

13. Key Learnings

  1. OCI Native Dashboards provide a centralized view of selected cloud resources and metrics.
  2. Resource Explorer widgets help display resource information for selected compartments.
  3. Separate Resource Explorer widgets can be used to view resources from different child compartments.
  4. A Resource Query widget can display instance lifecycle states in a table.
  5. The query query instance resources can be used to inspect instance resources within the applicable query scope.
  6. The where clause filters query results by lifecycle state.
  7. The || operator represents OR in the tested query.
  8. Monitoring metrics and Compute lifecycle states serve different purposes.
  9. Automatic refresh can update the dashboard without manually refreshing the browser page.
  10. Terminated instances are different from stopped instances and cannot be restarted as the same instance.

14. Interview Explanation

Question: How have you used OCI Native Dashboards to monitor multiple VMs?

Answer:

"I created an OCI Native Dashboard named Swiggy-Multi-VM-Monitoring to view resources from different compartments in one place. I added Resource Explorer widgets for the Compute and Storage compartment and the Network compartment. I also added a Resource Query widget using query instance resources to display VM lifecycle states such as Running, Stopped, and Terminated in a table. Finally, I enabled automatic refresh every five minutes and verified that the dashboard refreshed without manually refreshing the browser page."

15. Cost and Cleanup Considerations

  • The dashboard is a visualization interface. Review OCI pricing for any underlying services and resources used by the lab.
  • Compute instances, boot volumes, block volumes, public IPs, and other associated resources may incur charges depending on their configuration and billing rules.
  • Stopping an instance does not necessarily stop all charges associated with its attached resources.
  • Terminating an instance may not automatically remove every associated resource, depending on the termination options selected.
  • Review associated volumes, IP addresses, and other resources before cleaning up the lab.
  • Check OCI Cost Analysis and usage details to verify any charges.

16. Conclusion

In this lab, we created an OCI Native Dashboard to centralize resource visibility and VM lifecycle monitoring across multiple compartments.

We used Resource Explorer widgets to view resource counts, a Monitoring widget to display a web server accessibility metric, and a Resource Query widget to display instance lifecycle states. We then configured automatic refresh every five minutes and verified that the dashboard refreshed without a manual browser refresh.

This practical exercise demonstrates how OCI dashboards can support day-to-day cloud administration and resource monitoring.

STEPS