Error Monitoring

Monitoring for your site just got easier. With our powerful error monitoring service backed by our class leading APM solution, get back to what really matters by easily consolidating your error service and APM solution into one. When the error monitoring service is enabled, you will gain access to the context in which errors occur on your application. With our high fidelity overview charts as well as our detailed error tracing, you will gain insights into your app’s error trends as well as how these issues arose.

Enabling Error Monitoring

Error Monitoring is available to apps using Python 2.7+. It supports automatically reporting exceptions for applications using Django 1.8+ or Celery 3.1+. To enable:

1. Update to the latest version:

pip install scout-apm --upgrade

Error Monitoring was released in scout-apm version 2.21.0 and is enabled by default in version 2.23.0. Application monitoring must be enabled to use error monitoring.

2. Set the monitor and errors_enabled (optional since v2.23.0) config options to True.

If you are using a config file:

from scout_apm.api import Config

Config.set(
    # ... other configuration options
    monitor=True,
    errors_enabled=True,  # Defaults to true since v2.23.0
)

If you are using environment variables:

export SCOUT_MONITOR=True
export SCOUT_ERRORS_ENABLED=True

3. Deploy

4. Reach out to support@scoutapm.com to have us enable the service

Reporting Exceptions

Scout’s error monitoring will automatically capture errors raised on the Django signal got_request_exception and the Celery signal task_failure.

There is no visible effect on your application, and the error will be propagated further on.

However, if an error is caught, the error will never be received by our signal handler. To report this error to Scout use:

import scout_apm.api
scout_apm.api.Error.capture(e)

Ex:

import scout_apm.api
try:
    raise ValueError("Oh No!")
except ValueError as e:
    scout_apm.api.Error.capture(e)

The capture function supports a number of additional parameters to support manually instrumenting other frameworks.

• request_path - The relative path for the request such as: "/test/"
• request_params - A dict representing the query string parameters. This should be JSON-serializable.
• session - A dict representing the session for the request. This should be JSON-serializable.
• custom_controller - A string that is used to identify the controller or job, such as a background task name.
• custom_params - A dict of any additional values that should be included with the error. These will be unassociated with the scout_apm.api.Context. This should be JSON-serializable.

Ex:

from datetime import datetime
import scout_apm.api

# Assume request exists that contains the properties:
# path, session and GET

try:
    raise ValueError("Oh No!")
except ValueError as e:
    scout_apm.api.Error.capture(
        e,
        request_path=request.path,
        request_params=request.GET,
        request_session=request.session,
        custom_controller="broken_view",
        custom_params={"datetime": datetime.utcnow().isoformat()}
    )

Adding Context

Adding context to errors works exactly the same as adding context to web endpoints and background jobs.

If you have already added context to the endpoint or background job where the error has occurred, this context will be shown on the errors page.

Individual Error

To add context to an individual error, such as one that is caught:

import scout_apm.api

try
    raise ValueError("Oh No!")
except ValueError as e:
    scout_apm.api.Context.add("account_id", account.id)
    scout_apm.api.Context.add("user_id", request.user.id)
    scout_apm.api.Error.capture(e)

Visit our custom context section to learn more.

Not seeing errors?

Reach out to us at support@scoutapm.com for further support and troubleshooting assistance