The Stackdriver debugger allows you to inspect and analyze the state of your applications in real time without having to stop the application. With the debugger, you will be able to capture the call stack and variables without slowing down the application; this is particularly helpful if you want to debug or trace your code and understand its behavior. Stackdriver does this by capturing the application state by means of debug snapshots, which add less than 10 ms to the latency:

Debugger supports a variety of platforms:

Let's explore the debugger with the Hello World app we deployed earlier. We will use the version that works. If you deleted the app, simply follow the earlier process and redeploy the app.

Navigate to the Debug page in the side-bar tab:

You will see the Stackdriver Debug dashboard with our app. The Stackdriver debugger uses source context information to display the correct version of the source code here. This source code information is captured in the source-context.json file. When we deployed our Python app, a source-context.json file was generated and uploaded with our application. The Stackdriver debugger uses this file to load the correct version of the source code that is in production.

If you have custom source code, you can choose to load it into the debugger by clicking the dropdown on the left and selecting Add source code:

You will see a host of options to load your source code. This code is not uploaded to the GCP servers but instead uses HTML5 APIs and is loaded in the browser. This is only supported on Google Chrome currently:

Let's go back and load our application:

You can filter between apps by selecting the App in the drop-down menu. I selected the app that works without any errors:

Let's take a debug snapshot for our application. A debug snapshot captures the local variables and call stack at a specific line location in your code. Let's take a snapshot on line 20 where an error was intentionally added to our code in the main.py file.

Click on the line number. You will see a blue marker:

On the right side, you will see the status change to Waiting for snapshot to hit. The running application will not stop.:

If you are not sure how many snapshots were taken, locate Snapshot History at the bottom of the page:

You will see that the debugger is ready to take a snapshot at line 15 of the main.py file:

We will now send a request to our app to capture the variables and the call stack at that specific line. Simply click on your web app URL above the page:

Once the browser loads the page and sends the request to your app, the debugger captures the stack. You will see the following in your console:

The Call Stack panel shows all the results and values of local variables captured at that point in the code and at that point in time. You can even browse through the variables captured:

Let's take this a step further and add a debug logpoint. A logpoint enables you to inject logging into your running app without the need to stop it or restart it. Select the Logpoint tab right next to the Snapshot tab:

Let's add a simple logpoint Message:

Once you have finished, click Apply:

You will see that the logpoint is created. Make note that this logpoint is only valid for 24 hours. In the Logpoint History tab, you will see the logpoint created:

Most noticeable is the logpoint added to the code:

Let's go back to the web app URL and initiate a request. Select the Logs panel at the bottom of the page to see your logpoint trigger: