If you are running Oracle E-Business Suite (EBS) application today you will now be able to perform an auto discovery of all related resources in OCI Stack Monitoring. It will collect metrics specific for your EBS resources as well as ability to perform correlation across the EBS application and infrastructure stack as well as enable proactive alerting.
Components that will be auto discovered includes:
Concurrent Processing Node
Workflow Manager
WebLogic
Forms
Today, Stack Monitoring service supports EBS version 12.1 and 12.2 deployments hosted on OCI, On-Premise or Third Party Cloud (eg. AWS, Azure).
In the example, I will show you how you can configure Stack Monitoring for EBS version 12.2.
Functions in Oracle Cloud Infrastructure are great. As a serverless execution environment with pre-built logging, metrics, etc. it allows developers to simply focus on their code and not worry about all of the supporting infrastructure, while still providing a lot of flexibility through the use of container primitives. As great as Functions are, they are reactive, they can only be invoked and can’t natively be configured to be executed in a spontaneous or scheduled manner. Often this won’t matter, as Functions will be invoked directly or indirectly by users, or in response to events, but sometimes you simply need a bit of code to run periodically.
With the work that I’ve been doing with Open Street Map (here), I’ve been provisioning Pelias (here) – an open-source implementation of geocoding. This architecture is not small (consisting of 10+ docker images, and potentially 100+GB of raw geo data) especially if you are looking to geocode the whole world. The workload (or pipeline) had 4 main stages – download, prepare, import and query.
Download – to get the raw data sources
Prepare – to get the raw data into a format that can be easily imported
Import – to import the data into the elastic search (which is the backend)
Query – to accept geocode queries
Each of these stages have different performance characteristics and required different resources. The main thing that I’m looking at here is the use of compute. The need for compute during the prepare and import stages is significantly different from the download and query stages. I’m also not confidently in terms of when or how much I need.
And this is why I configured a burstable instance.
Here’s a couple of things to know …
There is a baseline utilisation OCPU. Consider this as a the minimum compute you want. For my scenario, it was primarily how much compute that I needed for the download and query stages.
There is full utilisation OCPU. Where this is can be 2x or 8x the baseline utilisation. (in the terms of the documentation – the baseline utilisation can be either 12.5% or 50% of the full utilisation OCPU). For my scenario, it was primarily the prepare and import stages that needed the additional compute.
The increased capacity is based upon the CPU utilisation metrics to determine whether to burst.
The average CPU utilisation for the month needs to up to the baseline utilisation OCPU.
Burstable Instances billing is known. It doesn’t come with Bill Shock.
You can find out more about Oracle Cloud Infrastructure burstable instances (here). If you want to try this out yourself or work on your own application, sign-up (here) for the free Oracle Cloud Trial. I’d be interested to hear your experiences and learn from others as well. Leave a comment or contact me at jason.lowe@oracle.com if you want to collaborate.
RedThunder.Blog 