Environment not set, but environment "tag" works

1 
    # XXX Configuring Sentry additional debug information - See https://docs.sentry.io/learn/context#capturing-the-user
    with configure_scope() as scope:
      scope.user = {
        "id": user.id,
        "email": user.email,
        "username": user.username,
        "ip_address": user.ip,
      }

      # TODO This setup could/should be moved to its own middleware, not critical though
      scope.set_tag("env", settings.ENV)
      init(environment=settings.ENV)

image
image.png1860×476 26.7 KB

I don’t understand why environment isn’t available, but the tag is set:

2

Hi @Vadorequest, I’m not entirely sure what you’re trying to do. Why have the init call inside of configure_scope?

4

Environment is a top level attribute. I can’t comment on how to configure it in the new SDK but sending a tag named something like env won’t magically detect it.

5

@Vadorequest the environment keyword argument needs to be set wherever you call init the first time. You can’t call init multiple times to supplement arguments.

6

Thanks everyone, I had fix the issue since posted it, but couldn’t reply. Indeed, I had made a mistake with setting the environment in configure_scope.

Here is what I did since then, this is my django manage.py:

#!/usr/bin/env python
import os
import sys

if __name__ == "__main__":
  os.environ.setdefault("DJANGO_SETTINGS_MODULE", "some.settings")

  from prettyconf import Configuration
  from django.core.management import execute_from_command_line
  from sentry_sdk import configure_scope, init
  from sentry_sdk.integrations.django import DjangoIntegration

  BASE_DIR = os.path.dirname(os.path.abspath(__file__))

  # set up configuration
  config_path = os.path.join(BASE_DIR, 'settings.ini')
  config = Configuration(starting_path=config_path)

  ENV = config('ENV', default='development')
  ENABLE_SENTRY = config('ENABLE_SENTRY', default=True if (ENV == 'production' or ENV == 'staging') else False, cast=config.boolean)

  if ENV == 'development' and sys.argv[1] == 'runserver':
    if '--nostatic' not in sys.argv:
      sys.argv.append('--nostatic')

  if ENABLE_SENTRY:
    # Enabling sentry for all "manage" commands - See https://docs.sentry.io/learn/environments/?platform=python
    init(
      dsn="IsThisSensibleInfoBTW?",
      integrations=[DjangoIntegration()],
      environment=ENV,
    )

    with configure_scope() as scope:
      scope.set_tag("env", ENV)
      scope.set_tag("sentry_startup_mode", 'manage.py')

  execute_from_command_line(sys.argv)

I’m enabling Sentry right from the manage.py, I noticed it helped auto-detect issues like migrations, basically any command that goes through manage.py gets “watched” and that’s actually awesome because I get the SQL queries ran in my server when a migration fails, for instance. <3

I also added a similar code in my settings.py:

if ENABLE_SENTRY:
  # Enable Sentry - See https://sentry.io/unly/studylink/#welcome
  sentry_sdk.init(
    dsn="IsThisSensibleInfoBTW?",
    integrations=[DjangoIntegration()],
    environment=ENV,
  )

  with configure_scope() as scope:
    scope.set_tag("env", ENV)
    scope.set_tag("sentry_startup_mode", 'settings.py')

I’m not sure if the duplicate is necessary though, I had first configured it in a middleware, then moved it to the settings.py, then duplicated it to manage.py to handle more errors.

Must say I love the tool so far! :slight_smile:

7

That sounds reasonable. I think only the call in either manage.py or settings.py is necessary. I wonder which errors you catch additionally by putting it into manage.py? I presume you catch all the errors that happen when your settings.py contains broken code? Or are there other situations I forgot?

8

I tried settings.py first and on my own computer I noticed it wouldn’t catch the migration errors, though it worked that way on the production server even with the sentry setup done in settings.py

Moving it to manage.py worked for more use-cases on my personal computer.
Since I’m not a Django expert by any mean, I decided to keep both, since it doesn’t seem to cause any issue and is unlikely to change anyway. But I guess I could safely remove what’s done in the settings.py indeed!

9

Ok cool. I’ll keep the recommendation in the docs as-is though as settings.py is just the usual place to put these kind of things.

You can generally initialize all the integrations wherever you want, with the caveat that you may catch more/less errors. We need to document this outside of the context of the Django integration I think.

1 Like