In this short video, learn how to use the OCI Monitoring Service to generate alerts when the CPU utilisation of a VM instance within OCI exceeds a given value – for example 50%.

Happy monitoring 📉

I needed to test an OCI Alarm I had created that should send an e-mail notification when the average CPU utilisation of a server exceeds 50% over a 15-minute period.

I found a “quick and dirty” way to generate CPU load on Linux using this one simple command:

yes > /dev/null &

This command runs yes (which outputs an endless stream of “y” lines) and redirects all its output to /dev/null (discarding it), with & putting it in the background.

I then ran htop on the instance and I could see that this pegged the CPU at 100%!

After 15 minutes, I received a lovely alert in my inbox:

If you do this, don’t forget to kill the process afterwards using “killall yes”.

A customer of mine recently ran the OCI Security Health Check 👨‍⚕️, this flagged up the following issue:

Rather than manually clicking through the OCI Console and updating this setting for all Compute Instances (which would have been mind-numbing!) to resolve this, I wrote a PowerShell script that loops through all instances within a tenancy and changes the Instance metadata service so that it only supports Version 2 (rather than V1 and V2), updating the configuration from this:

To this:

Here is the script in all of it’s glory, it can also be found on GitHub. Simply replace TenancyOCID with the OCID of the root compartment in the tenancy and run – this will loop through all compartments, find all Compute Instances and update the setting.

# Get all Compartments
$Compartments = Get-OCIIdentityCompartmentsList -CompartmentId TenancyOCID -CompartmentIdInSubtree $true -LifecycleState Active
# Loop through all VMs and update the instance metadata service so that it only supports version 2
Foreach ($Compartment in $Compartments) 
{
Write-Host "Compartment Name:" $Compartment.Name -ForegroundColor Green
$Instances = Get-OCIComputeInstancesList -CompartmentId $Compartment.Id
Foreach ($Instance in $Instances)
    {
        Write-Host "-Instance:" $Instance.DisplayName -ForegroundColor White
        $Action = Update-OCIComputeInstance -InstanceId $Instance.Id -UpdateInstanceDetails @{InstanceOptions = @{AreLegacyImdsEndpointsDisabled = $true}}
    }
}

If you need a hand using PowerShell with OCI, check out this guide.

That’s all for now!

I’ve just posted a short video on YouTube that demonstrates how to use Cloud-init to automate the configuration of a VM instance in OCI during the creation process.

This is a great way to save time, drive consistency and reduce errors when configuring VM instances.

I’ve previously documented the process for using the OCI Bastion service to securely connect to a Windows VM instance – https://brendg.co.uk/2023/12/14/connect-to-a-windows-vm-in-oci-using-rdp-through-a-bastion-%F0%9F%94%90/

I’ve recently created a short video to accompany this which steps through the process in further detail 📼.

I’ve previously written about the fantastic OCI Security Health Check – https://brendg.co.uk/2024/07/12/assessing-the-security-posture-of-your-oci-tenant-%F0%9F%94%92/

I decided to create a short video that walks through the process of performing an OCI Security Health Check…..a picture paints a thousand words and all that! 🌆

Here is a short walkthrough of how to configure Block Volume replication in OCI to replicate a Windows VM instance between two different regions – this is useful for disaster recovery scenarios.

Want to learn more about Block Volume replication, check this out – https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/volumereplication.htm

I’ve been working with a customer that’s automation tool of choice is PowerShell…..the good news for them was that OCI provides PowerShell modules!

This means that customers can in theory do everything in PowerShell that they can with the OCI CLI.

The following guide steps through the process of setting up the PowerShell modules for OCI – OCI Modules for PowerShell

Once I’d got this setup (which wasn’t very painful), one of the first things that I helped them to automate is producing a list of all of the VM instances running within their tenancy, I’ve included the code for this below:

# Get all VMs
$Compartments = Get-OCIIdentityCompartmentsList -CompartmentId ocid1.tenancy.oc1.. -CompartmentIdInSubtree $true -LifecycleState Active

Foreach ($Compartment in $Compartments) 
{
Write-Host "Compartment Name:" $Compartment.Name -ForegroundColor Green
$Instances = Get-OCIComputeInstancesList -CompartmentId $Compartment.Id
Foreach ($Instance in $Instances)
    {
        Write-Host "-Instance:" $Instance.DisplayName -ForegroundColor White
    }
}

This loops through every Compartment from the root Compartment downwards and lists the VM instances within each of these Compartments.

The only thing that needs to be updated prior to running this script is the OCID of the root compartment (CompartmentId parameter).

Here is the output from my tenancy:

You can see all of the Compartments within the tenancy and the 3 x VM instances that I have:

• N8N
• Streamlit
• Hub-VM