Red Hat OpenShift Red Hat Summit 2018 | OpenShift, 10 Jul 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keys to successfully monitoring complex cloud applications

Description

With the transformation towards cloud native platforms such as OpenShift, we are seeing a paradigm shift on how self-sufficient teams develop and deploy applications. Microservice teams leverage built-in platform features to run, scale, rollback and upgrade their app deployments. Monitoring helps them to understand if their apps are performing properly and interacting correctly with other apps in production. But how do they know if poor cluster performance impact application health, and how the overall performance of all apps deployed to a cluster looks? In this talk, we are going to explore how monitoring can be made a platform feature that helps application teams to monitor and maintain application and cluster health. We explain how noisy neighbors may slow down your application’s response time without requiring you to build monitoring into your application images.

A

Hello: everyone, my name is daniela ravi, sir, and I'm a technical product manager at dynaTrace, and I'm very happy to be here with you today and share what we're dynaTrace think is key for successfully monitoring, complex cloud applications.

A

So you probably know that monitoring used to be a lot about looking at dashboards, so you developed your application deployed it in your environment. You deployed it either on-premises in your own data center or somewhere in the cloud. Maybe on AWS, for example, and then you watched you watched if anything happened or if any threshold would throw an error message, so you probably stared, maybe on dashboards, showing graphs like like you see on the screen here, or you probably skim through some application log messages looking for some key words, but the thing is modern monitoring.

A

We a dynaTrace think that modern monitoring should go beyond that. So you shouldn't have different agents to cover different technologies. So there should only be one agent. You shouldn't have lots of data, but no answers. So when you think of that of that graph that I showed you. What would that mean? So you this wouldn't provide you any insight.

A

Any answer to problems that might have been that might have been available in your environment and also you won't go for or you shouldn't go for a solution that contains lots of duct tape that covers everything but is kind of, like you know, sticking together only via duct tape and also when thinking of deploying your monitoring solution. This should work smoothly for you and since we are here at the Red Hat summit, of course, containers shouldn't be something that your monitoring solution doesn't understand and, of course it should just work for the enterprise cloud.

A

So we are dynaTrace think that modern monitoring should provide you with a holistic view of your environment. It should be a I part. It should be fully automated when it comes to deployment, and it should, of course be purpose-built for the cloud, because we all know that healthy environment is something important. It is important if you do have a small environment, but it comes. It becomes highly relevant if you think of a big environment.

A

So if you do have containers in place, if you do deploy your applications using using containers, then the typical life of a container is maybe minutes, maybe hours and not necessarily days or any longer.

A

So given this kind of environment, given this kind of highly dynamic and distributed environment, so it may become difficult for your monitoring solution to monitor the applications, as the number of of nodes of containers are ever changing and also the numbers can get very big since enterprises are currently migrating applications from monoliths from monolithic applications to microservices and of course, containers are a big topic to support breaking up monolithic applications, and when thinking of that, you can of course have like thousand containers per notes available and then your monitoring solution needs to scale with your environment as well, and when thinking about that, it may also come to your mind that container health services, health, an application health may be something different.

A

So traditional monitoring tools use, for instance, container api's to provide an overview of container health, though it is important to keep track, keep an eye of container health in terms of darker stats. The Dockery api- it is, of course, not sufficient to only focus on the container health.

A

Only the most important thing is to measure the health of the services that are running inside a container, and it could very well happen that the container health that the talker stats, for instance, may show healthy results, but the services running inside the containers could be starving for recess, for resources, for instance, for example, if you're on a Java process in the container, and it could be starved for CPU and human, it may not be able to spawn multiple threads to deliver the service faster and, more importantly, looking onto application performance at a component level at a container level does not indicate the performance of your application when it comes to user experience or the delivered service that the user is is looking for.

A

So everyone who has ever participated in an IT war room during a serious incident knows that everything can look okay at a component or container level. Even when in like taking a holistic view, the results may be very poor.

A

So if, if you think of you know the typical life of a container, then on an on an infrastructure live level, you may do some chaos. Monkey testing, for instance, to ensure that your infrastructure health is is doing fine on a container level. You could look for darker steps. You could query the docker API on a micro-services level. You could look for response times of your services. You can look for failure rates. You could look at CPU usage, you can look at the throughput and, of course, on an application level.

A

You could look at how are my users experiencing the applications when you know visiting websites so with a monitoring solution? You should get all that.

A

You know different few points provided in one solution like I mentioned in the beginning. You would probably look for a holistic view and another angle to look at monitoring cloud environments is that deployment dependencies may be different from micro services Dependencies so, for instance, with dynaTrace.

A

We do cover both, so you will get, on the one hand, side the deployment dependencies that you see on the left side of the screen, and you will also get microservices dependencies with what we call in dynaTrace the service flow and when, having a closer look at a service flow, you will also get insights into the architecture of your micro services. You will notice that two micro services that are split up currently are tightly coupled, and you may probably think about you know combining these two services into one because they are so tightly coupled.

A

So why split or distribute them onto two services?

A

So we are dynaTrace think that, in order to successfully monitor your cloud environment, monitoring needs to become needs to be seen as a platform feature, so you should deploy and with territories you can deploy only one agent per host. This one agent will then take care of auto instrumentation of your containerized micro services. So there is no need to adapt your application containers. The one agent will also take care of autumn automated distributed transaction tracing and dynaTrace is also an AI based solution, and it will help you with analyzing the root cause of problems.

A

So in order to deploy the one agent on your openshift platform, for instance, dynaTrace, provides great support. So we announced yesterday that we are one of the very first Partners of RedHat to have an operator in place.

A

So the one agent operator allows you to manage dynaTrace one agent deployments, so it allows you to roll out the one agent onto specific notes only so this allows you allows you to to control one agent deployment in a fine-grained way, and what is great well, you add, of the one agent operator is that it will take care of updating the one agent automatically as soon as a new version of the one agent gets available.

A

So the one agent operator ensures that all your monitoring so that monitoring of your open shift cluster works with the latest one agent version.

A

So if you want to check out the one agent operator, so we do have a great blog post around that online and we also have a github repository available, where you can also have a closer look at the source code at the implementation of the one agent operator, and you can also use the github repository to get in touch with us. And if you have further questions to start a discussion around that and speaking of further questions. So we are happy to give you a demo of the Tanner twister in support at our booth 4:17.

A

We also do have the one agent operator running there and you can also check out dynaTrace for your own cloud environment as well and get a 15 day free trial of dynaTrace, because you know life without monitoring is like a box of chocolates. You never know what you get. So that's all from my side so far. Thank you for your attention and have a nice afternoon.