Dogfooding is the practice of a company using its own product. If you’re an early adopter of Bugsink, you might want to use Bugsink to monitor Bugsink itself. This way you can provide feedback to us about the product and also ensure that you’re getting the most out of Bugsink.
There are basically two ways to do this:
Since Bugsink is built to be self-hosted, you can just point your Bugsink instance to itself. The advantages of such an approach are the usual ones of self-hosting: you’ll have full control over your data and will not have to worry about privacy issues.
The disadvantages are specific to dogfooding: in the case of a catastrophic failures, there may not be a Bugsink instance to report the failure to. Also: in the case of a bug in the ingestion/digestion process, you might run into infinite recursion, because each attempt to report the bug will itself be reported as a bug.
If you go this route, just set up a new project (“Bugsink itself” or “Dogfood”) in your Bugsink instance and use the API key for that project in your Bugsink configuration.
If you want the avoid the risks of infinite recursion, you can send your data to our instance. Reach out to us and we’ll set up a project for you on our instance. You can then use the API key for that project in your Bugsink configuration.
Add the SENTRY_DSN
to your environment, and the following to your bugsink_conf.py
:
SENTRY_DSN = os.getenv("SENTRY_DSN")
if SENTRY_DSN is not None:
sentry_sdk.init(
dsn=SENTRY_DSN,
traces_sample_rate=0,
max_request_body_size="always",
# be explicit about `in_app` because we deploy as a .whl
in_app_include=[
"alerts",
"bugsink",
"compat",
"events",
"ingest",
"issues",
"performance",
"projects",
"releases",
"sentry",
"sentry_sdk_extensions",
"snappea",
"teams",
"theme",
"users",
],
)