Not a customer? Click the 'Start a free trial' link to begin a 30-day SaaS trial of our product and to join our community.
Existing Cisco AppDynamics customers should click the 'Sign In' button to authenticate to access the community
on 05-31-2018 07:00 PM - edited on 10-02-2018 02:10 PM by Nina.Wolinsky
Monitoring Kubernetes Microservices Applications
[Air-Date May 30, 2018]
@Mark.Prichard and @Eric.Johanson guide us through a detailed scenario of how to monitor microservices-based applications deployed using Kubernetes. They cover everything you need to know about packaging your microservices with APM agents and deploying to Kubernetes running on AWS, including: sidecars, secrets, persistent storage, and Istio for service routing.
Below is the complete recording of the technical session. Please note that this version is low sound quality. For a higher quality version of the demo portion, we recommend watching the three individual demo videos embedded underneath the full version.
Invididual Demos
[Demo 1] Setting up the Cluster and Defining the Application
Linked referenced in this webinar>>
https://kubernetes.io/docs/getting-started-guides/aws/
https://kubernetes.io/docs/getting-started-guides/ubuntu/
https://kubernetes.io/docs/getting-started-guides/ubuntu/installation/#conjure-up
https://jujucharms.com/
We’re running the AD-Capital-Docker example from the AppDynamics GitHub page, using the Kubernetes branch: https://github.com/Appdynamics/AD-Capital-Kube [Please note this is a new link, it was updated on 6/14/18]
We’re using the AppDynamics APM official base images from the Docker Store: https://store.docker.com/images/appdynamics
You’ll find instructions on how to build your own here:
https://github.com/Appdynamics/appdynamics-docker-images
Istio (https://istio.io/docs/concepts/traffic-management/overview.html) used to provide request routing and timeout/retry error handling.
Server Agent is deployed as a Kubernetes daemonset to run on each worker node: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
Q&A
Can we identify the code or queries creating problems in the environment in microservice monitoring?
Where is the base image for the machine agent?
You mentioned MySQL. Is that the backend or is it CassandraDB?
Where is the base image for MA?
Does the underlying deployment matter (e.g., bare metal, VMs, containers, or microservices)?
Do you support Nginx monitoring?
Do you have any final takeaways?
Q: Can we identify the code or queries creating problems in the environment in microservice monitoring?
A: Yes, through container monitoring you’ll be able to see the processes that are running there. There will be a command process associated with the container that you can see.
Q: Where is the base image for the machine agent?
A: One place is on the docker store, where we have images for containers with the Java Agent. We also have images with the Machine Agents (server agents). The source code for both is available on the GitHub page. We have specific requirements for ours, so it’s nice to be able to pull it and update it, then push it again. We also included a resource list above for you to reference.
Q: Do you support Docker Swarm?
A: We covered that a bit in the previous webinar. Yes, it will work fine. With any orchestrator, you will be getting the same type of information, looking at container metrics, hardware, etc. You can make the adjustment pretty easily from Kubernetes to Swarm.
Q: You mentioned MySQL. Is that the backend or is it CassandraDB?
A: This application is using MySQL, but you could use either. We monitor both using AppD. In this example, I don’t think we deployed the database but it’s very easy. You’d simply put it into its own container. You configure it to point to CassandraDB or MySQL and that would then show up. It’s very easy to do.
Q: Where is the base image for MA?
A: https://store.docker.com/images/appdynamics. Just log in to dockerhub to pull the image. To build the MA manually via docker image, use this link: https://github.com/Appdynamics/appdynamics-docker-images
Q: Can my current AppDynamics deployment monitor Kubernetes and Docker environments as long as I have an agent present?
A: Yes, as long as it’s 4.4.3
Q: Does the underlying deployment matter (e.g., bare metal, VMs, containers, or microservices)?
A: No. As long as there is a Machine Agent on the node and an Application Agent on your application, it doesn't matter if it's a VM, container, or microserverice.
Q: Do you support Nginx monitoring?
A: Yes, and we have extensions here.
Q: Do you have any final takeaways?
A: Kubernetes as an orchestrator is everywhere in the industry and there are a lot of customers wanting to go this direction. What we wanted to show you is that it’s very easy to build in APM best practices or kubernetes-style deployment. There are some things to think about when planning your deployment architecture, like separating application code from infrastructure code. Think about your style of operations and how you want to load the APM agents. Do you want to build them into base images or do you want to load them dynamically using shared storage? Think about application design. You’re probably going to want to look at things like Istio as a service mesh. It’s really straight forward; the key is to not hard code stuff that you can do dynamically!
When you’re going through this, it’s really simple but there are some small things that might catch you up. However, Kubernetes is powerful because of how much it gives you out-of-the-box dynamically and how customizable it is.
Heads up, this link was updated on 6/14/18>> it so no longer on the previous github page.
We’re running the AD-Capital-Docker example from the AppDynamics GitHub page, using the Kubernetes branch: https://github.com/Appdynamics/AD-Capital-Kube
Thank you! Your submission has been received!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form