Debugging

In this lab, you will use the CF CLI to view an app’s logs, as well as to find out what Cloud Foundry itself thinks is happening to your app.

Push a Buggy App

A buggy app is included in the 06-debugging/debug-app directory with a manifest.

Push 06-debugging/debug-app to PWS

Note the URL

Access the App

Open a browser and access the app.

Observe a 500 error.

What does Cloud Foundry think the health of the app is? How did it draw this conclusion?

Getting fast feedback on failures is a key element of agility. The sooner we know something is broken, the sooner we can fix it.

Use cf push –help and Cloud Foundry documentation to push the app again, in a way that Cloud Foundry will deem it unhealthy

Check out the Logs

Use cf logs to access the recent logs and debug the issue.

If you do not specify the --recent flag to cf logs, it will start tailing logs from that point onwards.

Checking Your Work

You should see something similar to this in the logs:

... [App/0] ERR ...  - RuntimeError - I am a bug, fix me:

Fix it

This app can be fixed by setting an environment variable and restarting it.

Use cf help -a to find out how to set an environment variable for your app called FIXED with a value of true

Restart your app, and visit it in a browser to check that the bug is fixed

Debug with Events

Now the app offers other links that allow you to terminate the app’s process, use up all the app’s RAM, or fill the disk.

Click “stop process”

Observe the output of cf events and cf logs for your app

Click “exhaust memory”

Observe the output of cf events and cf logs for your app

How do the two compare? What help does Cloud Foundry give you in determining the cause of failure?

Checking Your Work

You should see something like the following:

... index: 0, reason: CRASHED, exit_description: 2 error(s) ...

Click the ‘exhaust disk’ link, and check cf logs and cf events.

What happens? Is this what you expected?

Set up App Performance Monitoring

We will demonstrate application performance monitoring using NewRelic.

The setup process is different for Pivotal Web Services and Swisscom. PWS uses Cloud Foundry service brokers to automate some of the manual steps for you.

PWS Setup

The process involves creating an instance of the New Relic service, binding it to our app, adding a license key, then re-pushing. Services are covered in another section of this course, so don’t worry if you don’t understand these commands.

Create a New Relic service instance: cf create-service newrelic standard newrelic

Tell Cloud Foundry that debug-app should use your New Relic service instance: cf bind-service debug-app newrelic

Find the New Relic license key in the output of cf env debug-app

Swisscom Setup

Swisscom does not use the NewRelic Cloud Foundry service broker, so we’ll need to set up an account manually.

Create a new account on NewRelic.com

Click on your account name in the top-right of the welcome dashboard, and select Account Settings

Copy the license key from the right-hand Account Information section

Set the License Key in your App

From now on, the steps are the same regardless of whether you’re using PWS or Swisscom.

In newrelic.yml, replace YOUR-LICENSE-KEY with the value you just found

Re-push the app

Viewing the Dashboard

New Relic has a dashboard. You can find the URL by looking at the service details.

Visit the URL reported by cf service newrelic

Observe graphs showing app performance data in the New Relic dashboard. Sometimes it takes a few minutes for the data to arrive.

SSH access

Don’t forget that you can use cf ssh to look at the current filesystem of your app.

Beyond the Class

Setup Skylight for app
Setup Opbeat for app
Learn about CF Logging and Metrics
Send app logs to Papertrail

$ cf cups logdrain -l syslog://YOUR-PAPERTRAIL-LOG-DESTINATION
$ cf bind-service debug-app logdrain
# Check your Papertrail Events, no need to restart the app