It is recommended to use an integration for your particular serverless environment if available, as those are easier to use and capture more useful information:
If you use a serverless provider not directly supported by the SDK, you can use this generic integration.
serverless_function decorator to each function that might throw errors:
import sentry_sdk from sentry_sdk.integrations.serverless import serverless_function sentry_sdk.init( dsn="https://examplePublicKey@o0.ingest.sentry.io/0", # Set traces_sample_rate to 1.0 to capture 100% # of transactions for performance monitoring. # We recommend adjusting this value in production, traces_sample_rate=1.0, ) @serverless_function def my_function(...): ...
Use the generic integration by calling the
Decorators wrap a function and modify its behavior. Then, deploy and test the
function. Check out Sentry's sample
apps for detailed examples.
Each call of a decorated function will block and wait for current events to be sent before returning. When there are no events to be sent, no delay is added. However, if there are errors, it will delay the return of your serverless function until the events are sent. This is necessary as serverless environments typically reserve the right to kill the runtime/VM when they consider it is unused.
You can add more context as described here.
Request data is attached to all events: HTTP method, URL, headers, form data, JSON payloads. Sentry excludes raw bodies and multipart file uploads. Sentry also excludes personally identifiable information (such as user ids, usernames, cookies, authorization headers, IP addresses) unless you set
Each request has a separate scope. Changes to the scope within a view, for example setting a tag, will only apply to events sent as part of the request being handled.
The maximum amount of time to block overall is set by the
shutdown_timeout client option.
You can disable this aspect by decorating with