Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.
AppDynamics customers and established members should click the sign in button to authenticate.
Air-Date August 2, 2018
Run Time: 60 minutes
@Mark.Prichard and @Eric.Johanson take a look at a detailed example of a containerized application and how to successfully deploy it using Kubernetes to each of the three main container management services:
In this technical session, designed for operations teams who manage cloud-native deployments,
we took an in-depth look at:
|Resource Links | Monitoring Kubernetes in the Cloud on EKS, AKS, and GKE|
We don't provide it currently, but we would take it as an action item. Following the same approach that we showed you in the webinar, we could package the Docker image with built-in AWS monitoring and make it available on the Docker Store. The AppDynamics Java Agents have tags and we could build Machine Agents for AWS with certain tags and built-in extensions, so it is doable.
Kubernetes monitoring is application-based. What we showed you today in the webinar is Java-based application monitoring on EKS, AKS, and GKE. Our example used the Java Agent, but AppDynamics provides different types of Application Agents. We don't want you to think that Kubernetes monitoring is only Java-based, so we would do a webinar based on another agent type.
You have containerized application components that you want to monitor with APM. Depending on the runtime, you install the corresponding type of APM Agent on the containers. On each Kubernetes worker node where your application is running, you install the Machine Agent to have those containers monitored. If you don't have a Machine Agent installed and if you have containers that are unrelated or that are not being monitored through APM or infrastructure components, you don't need AppDynamics App Agents.
We will publish a blog to demonstrate how to build and deploy Docker images with AWS monitors. We will also include the Docker file with the blog to show you how to build it, and if you don't want the component you can comment it out and rebuild it. We will also post the image on the Docker store.
One of the major enhancements in 4.5 is Dynamic Monitoring Mode (DMM) for all Docker Visibility Metrics. See Dynamic Monitoring Mode and Docker Visibility to learn how it works.
Basically, it is a flag that you can set on the AppDynamics Controller and it selectively controls the number of Docker Visibility metrics reported for individual containers. The default is the standard Key Performance Indicator (KPI) mode. Diagnostic mode and Advanced Diagnostic mode help with detailed troubleshooting. In normal operations, we use KPI mode and if you detect any issue on a particular node or a server, you can turn advanced modes on to collect additional metric data to diagnose problems.
The examples we demonstrated today are specific to Docker and Kubernetes but you can run AppDynamics replication on VMs like many of our customers do. Many AppDynamics customers are running Docker and Kubernetes on top of VMs too.
AppDynamics supports RedHat OpenShift. See RedHat OpenShift for instruction on using it. We are also planning a webinar on this topic, covering features such as rolling upgrade. OpenShift and Kubernetes are identical and they are 99% the same. OpenShift has a security framework and its deployment model is enterprise-grade.
AppDynamics has introduced a rich set of extensions that handles AWS. We use different AWS APIs. Putting those things together and building a Docker image is doable.
We do see a hybrid application pattern as well. Supporting applications on hybrid cloud is one of the beauties of the Kubernetes approach. GKE is offering on-prem and there are others setting up Kubernetes on-prem.
The main challenge is in security and authentication. Having those things ironed out to be working across cloud, hybrid application is a possibility.
Some of the topics we discussed in this session are relevant to this question. There is a fundamental trade-off between operational convenience and flexibility. You can either use the AppDynamics base image and extend it to include your application code, or build your own if you have certain code standards to follow.
From an operational perspective, it is easy. The downside of using your own image is the proliferation of images, with different tags and versions that you have to manage. Another scheme is dynamically managing it using a sidecar method as we showed in our previous webinar.
What we showed was to have the agents loaded into a subnet network storage and pull them into the container as needed. It requires more operational setup and you need to specify the path you use in order to pull the image file. But, it will resolve in smaller and lighter images so it is faster to load. You can also turn APM off in development mode. Run the container without APM and dynamically inject when you need them. Customers favor one of these methods but all these boils down to what you chose - operational convenience or flexibility.
The installation steps can be found here: Monitoring Applications in Docker Containers
It is not open source. You need a Server Visibility license to use it. See Monitoring Docker Containers for more information.
We have customers interested in monitoring these platforms. Considering the way we do container monitoring, AppDynamics APM could work on those technologies.
We would certainly publish best practice guides and examples either on Github or in a blog that shows how to package and deploy the agents for those technologies. We would also make the Docker images for a wider range of agents available on the Docker store.
Source code is available for the agents and it's a matter of putting them together to make it deployment-specific.