Which Oracle Cloud infrastructure Monitoring Service feature uses metrics?

(swelling music) - [Instructor] Welcome to this lesson on getting started with OCI monitoring service. We are going to look at an overview of the service some of the fundamental capabilities and a service workflow that integrates with a notification service. Monitoring is one of the foundational service of OCIs observability and management platform. It is designed to help you with actively and passively monitored cloud resources. These cloud resources can be native to Oracle Cloud Infrastructure or it could be external resources running in a different cloud infrastructure environment. The service use a concept called metrics to monitor these resources and these metrics are emitted by those cloud services. And then you can use alarms for notifying or alerting for any of the problems in your environment. There are different ways you can access these metrics and alarm data. You can use OCI console, CLI or command line interface and APIs. I would recommend you to go through some of the demos that would be highlighting how to use these service in these different ways. There are dashboards available where you can gain a single plane of glass window for monitoring your resources. Alarms is another key concept and it is used to publish messages into different destinations that are managed by the notification service. Let's look into some of the capabilities of monitoring service. We briefly spoke about metrics and these metrics are standardized across Oracle and non Oracle technologies and this approach would help you to reduce the need of having vendor specific expertise for any of your requirements. Applications commonly uses a multi-tier distributed architecture, so what this means is you are also running microservices based applications or containers. You might be also hosting bare metal servers, databases load balancers and everything that support towards this architecture. The monitoring service is designed to help you capture the status and performance summaries based on each of these service tiers and making it easy to troubleshoot when they are appearing across these tiers. The service also provides capabilities for proactive and flexible alerting. If you look at the DevOps workflow, in our previous lesson we learned about running continuous integration continuous deployment practices, and there is always a need for proactive and continuous monitoring to capture alerts before it hits the end user. Monitoring service would help you to generate alerts and also setting up alert threshold rules which can be specific or broad for any of the resources to achieve these capabilities. As we talk about these different metrics getting a unified global view of infrastructure health is also important. One of the reason is to correlate metrics with other metrics. For example, correlating a performance metric with other load metrics across all entities in the tier. And this is one of the capability of the service with providing you purpose built dashboards with a global wide visibility. Monitoring service give you features to define new custom metrics and integrate into your dashboards and alert rules. This is also highly important to use cases with extending monitoring to any type of resources using the service. Here is an end-to-end workflow of OCI monitoring service. On the left, you have applications, services and resources in a customer on-premises environment and then you have resources in Oracle Cloud Infrastructure environment. These resources are continuously emitting metrics in the form of raw metric data which means there are no filtering conditions defined to the data at that stage. The next step is to transition this raw metric data into an aggregated data, and this is done with applying certain statistics and an interval. For example, you can choose to show the minimum or maximum resource utilization of an entity. You can also access this aggregated data using OCI console or using APIs, SDKs, CLI or even using customer's third party monitoring tools like Grafana. So once the aggregation is done the next step is to define an alarm with a condition. And here in this example, we are choosing if the CPU utilization is greater than 80% that should trigger an alarm. If the CPU utilization is less than 80% the alarm status is okay, and if it is greater than 80% it should trigger an alarm into the firing state. Alarms are integrated with OCI's notification service, which will help you to notify different communication channels. We will be looking at the specifics and configurations in our next set of lessons. To summarize, we looked into an overview of monitoring service, some of the capabilities of the service, and an end-to-end workflow with an example of monitoring the CPU utilization of an instance. So that's all in this lecture. We will now look into some of the key concepts of monitoring service. Thank you for watching.