Monitoring Pivotal Cloud Foundry Applications and Infrastructure
Air-Date June 19, 2018
Run Time: 60 minutes
Resource Links>>
GitHub: cloudfoundry/hwc-buildpack
AppDynamics Docs: .NET Microservices Agent
AppDynamics Blog: Blue-Green Deployment Strategies for PCF Microservices
AppDynamics for Pivotal Cloud Foundry v4.4.231 is now available!
Many of our largest customers are using Pivotal Cloud Foundry (PCF) to provide cloud services on a variety of public and private infrastructures. In this hands-on session for operations teams and developers, we’ll do a deep dive to show you how to monitor polyglot distributed applications deployed to PCF.
@Mark.Prichard , @Pavan Krishna.Nimmagadda, and @Jeffrey.Holmes take you through the complete application lifecycle, showing how to deploy and configure APM solutions using Cloud Foundry buildpacks for Java, .NET, node.js, Python, and other languages; how to install and configure the AppDynamics Service Broker tile; plus a detailed look at monitoring PCF and BOSH infrastructure health and availability using the new monitoring integration recently introduced for Pivotal 2.x.
Q&A
Q: Can you talk about database monitoring and analytics?
A: Analytics is in works and can be expected in a future release. Database monitoring is also in the works. Once you’ve moved to the latest version of the tile, it’s a simple upgrade.
Q: Can you contrast each of the configurations that you’ve explained with the CF CLI alternative?
A: We’ve stuck to manifest.yml because it’s elegant and simple. All of the options that are available in manifest.yml can be provided as command line options as you are doing a CF push. Technically, you don’t need to do the manifest. You can create an instance as usual and say cf push bind-service AppD 4.4.3 <application-name> - b <buildpack>
Q: Is there a difference between CF create-service and create-user-provided-service?
A: User-provided service isn’t something we recommend because you’re supplying all of the connection and authentication parameters for the Controller as part of the command. One of the benefits of using the Marketplace service is that it’s all encapsulated in the tile and you don’t need to supply those parameters and bind to that service. In a nutshell, you can either configure it inside your tile one time using the Marketplace service or repeatedly configure it with user-provided service on the command line without using the tile. The tile is easiest way.
Q: Do I need to create a new service instance per application or can a service bind to multiple applications?
A: You can create one service instance and bind to hundreds of applications. Please note that one service instance is a 1-1 mapping with the Controller. If you are using a 4.4.3 Controller, you can create just one instance and you can bind it to as many applications as you’d like and they’ll all report to the 4.4.3 Controller.
Q: If we defined user-provided services per CF spaces, how do we specify different license keys?
A: Let’s say you have a dev-test and pre-prod Controller, each with its own license key that you need to manage. If you’re using the user-provided service, use the "Add" button on the Controller Configuration screen to manage your Controllers (see 41:20 in the recorded webinar above for a visual of this screen). If you have a different access key or Controller configuration to maintain, you can create another entry there. You’d create an instance of that and bind it. You’re creating a plan and when you list the service, you’ll see the different plans (e.g. prod, test, etc.).
If you use the Service Broker approach, different tiles would be deployed into different foundations. Alternatively, you could have one tile with different plans and each plan could refer to different Controllers with different license keys. When you create the service, you would refer to the appropriate plan with the correct license key and bind to that within that space
.
Q: Is it possible to run an analytics agent in its own container and use the remote analytics functionality?
A: You could, but we are packaging it as an extension of the machine agent. If you want to push out a standalone analytics agent to Cloud Foundry, you would push it like any other application. Pushing a machine agent with an analytics agent to get CF metrics will not work. That being said, the tile should include all of this and do the hard work for you.
Q: In addition to unhealthy alerting/reporting, can I configure regular status reporting (e.g. daily memory/CPU/disk usage per application instance)?
A: Yes, you can regularly generate a report that’s essentially a snapshot of the dashboard we showed. Since you have all of the metrics available, you can create your own custom report that would show you remaining memory.
Q: How we can reliably ensure the PCF application is instrumented and verified immediately during the change window? Sometimes the PCF application Appdynamics instrumentation doesn't reflect immediately.
A: Typically, when you initially instrument your PCF app, there is a 5 minute delay before it shows up in the Controller. You should then know whether or not there’s an issue and can begin troubleshooting. You can log on to the container via CF SSH and look at the logs available from the application agent or you can say cf logs <application name> in the command line to pull all of the logs. It’s like debugging any other agent to controller issues.
Q: Can I have customized parameters via the tile that are unique to the individual PCF applications being instrumented?
A: Yes, you can do this by pushing your environment variable. In the manifest.yml under the services, you include an env space and push it as an environment variable to your application. Your application will read it as an environment variable and use it. You can also set the standard environment variables that we expose in configuring the agents inside your manifest.yml. For CLI, you say set-env <variable-name> <value>.
Q: Can I see machine agents metrics on the container level?
A: The loggregator API doesn’t provide visibility into specific containers in PCF but it’s on the roadmap. For those familiar with our container monitoring for Docker and Kubernetes, we would like to provide a similar solution but for Pivotal applications deployed on Cloud Foundry. We don't have all the information coming directly from the loggregator but we may have ways around this to provide an equivalent set of metrics as much as we’re able to. We’re waiting for those metrics to be exposed.
Q: Does it support .NET Core?
A: An upcoming buildpack will support .NET Core for Windows, and .NET Core for Linux is in the works.
Q: What are the key takeaways?
A: Install the Service Broker tile! Trying to push your application is a big hassle, so the tile is the simplest way to go. If you find something that prevents you from installing it, we can help you resolve it. We also recommend using the integrations as much as possible. Our core philosophy was to stick to the pivotal architecture.
The infrastructure monitoring we offer will save you a fair amount of work. You can look at Pivotal’s documentation and continue to improve upon it based on your experiences monitoring your application.
Finally, there’s always more work to be done. If there are any gaps in the monitoring space you’d like us to address, get in touch with us!
