In part 2 of the series we will look at a simple 2-Tier architecture and investigate how best to provide End-to-End monitoring. In part 1 we have discussed the OOTB and Add-on Services available on OCI for customers to choose for End-2-End monitoring needs. This blog post will highlight the monitoring options when working with a mix of native OCI services like LBRs or VCNs and also customer managed components like Application Servers and Databases. This topic is co-authored by Gustavo Saurez, Johannes Murmann , Pulkit Sharma, Richard Jacobs and Uday Sambhara.
The below diagram shows a simple 2-tier architecture with the following components:
A Database tier running Oracle Database on an OCI Compute shape
2 Application tiers hosting WebLogic Application Servers as well as Web Server Front-ends running on OCI Compute shapes
An OCI Load Balancer front-ending the Web Servers.
All of these components are running in separate subnets with the LBR subnet being the only public one.
The diagram shows 3 different monitoring components highlighted with a light blue color:
Cloud Agent: Runs within the Operating system collecting metrics and logs from the OS and other applications like the Webserver, Database etc. Cloud Agents can also collect logs streamed through syslog, and can collect metrics from other data collection regimes such as collectd, Telegraf, Mircosoft SCOM and VMWare VCenter Ops.
APM Agent: Runs within an Application Server basically instrumenting it and providing details about the execution of applications running on the Application Server
Besides the three components mentioned above OCI also provides metrics automatically for many of the native resources. E.g. you can't install an agent on a block storage volume or VCN bu these resources will emit predefined metrics on their own.
The following table lists all the different kinds of metrics and logs that can be collected and used in monitoring the above solution:
The above example was based on a simple architecture and really no business transaction related data was captured.
Building upon the simple end-to-end use case, we will now look at a more complex use case. OCI monitoring for multi-tier applications such as Oracle E-Business Suite (EBS) deployed on OCI or on-premises infrastructure.
EBS consists of the database instance(s), application tier hosts, and Oracle WebLogic Servers, similar to the components/layers discussed in the simple End-2-End use-case. The application tier, however, is a major difference, with several EBS-specific components that are not instrumented by generic monitoring systems.
While knowing about CPU utilization and Memory usage of different nodes is important it really doesn’t provide any insight into the business side of things, e.g. Order processing times at month end, how different EBS Concurrent jobs are doing or if there are any stuck workflows.
Using the add-on services Log Analytics, Infrastructure Monitoring and Application Performance monitoring we can gather information that can be translated into business critical performance data and displayed in specific OOTB dashboards that have been tailored to specific applications like EBS, PeopleSoft or Siebel or others.
This diagram shows the components monitored and the configured agents (Cloud and APM) and metrics and logs collected from EBS. Refer to this link on EBS specific configuration needed for monitoring.
In this blog post we have seen a simple use-case for End-2-End monitoring and a complex use-case like EBS that requires business transactional data monitoring. OCI Add-on Services like Log Analytics, Application Performance Monitoring and Infrastructure monitoring address this functionality. Part 3 in our series on End-to-End Monitoring will provide more details on these Add-on Services.