Disable django db and cache instrumentation for edxapp

[robrap]

We should consider disabling the following, in order to drop the duplicate spans created for the db and cache:

• Django DB: ddtrace.config.django['instrument_databases'] | DD_DJANGO_INSTRUMENT_DATABASES
  • Note with this, we will still get db spans created from the underlying db library. It’s just that the default is to create a span from the ORM.
• Django Cache: ddtrace.config.django['instrument_caches'] | DD_DJANGO_INSTRUMENT_CACHES
  • Note that the cache layer will still get instrumented from the supported library, but we will avoid creating a duplicate span when the django cache gets called.

Notes:

• It is uncertain what we want to do here. Once we determine and implement, we should potentially create an ADR, and also update the appropriate How-To doc.
  • See Slack thread for additional thoughts.
• This should be a small change.
• This should make it easier to understand traces, and make them less cluttered.
• It should also greatly reduce ingested and indexed spans.

[robrap]

@timmc-edx: Let me know if you end up implementing this on another ticket and leaving it in place. Thanks.

[timmc-edx]

I was curious about what span tags are different between the Django spans and the library spans. Here's what I found in a recent pair of spans:

• service defaultdb operation mysql.query:
  • component is django-default
  • Has additional tags db.instance:wwc, django.db.alias:default, django.db.vendor:mysql
• service mysql operation mysql.query
  • component is mysqldb
  • Has additional tags db.system:mysql, duration:475474

The only potentially valuable thing I see on the defaultdb span is db.instance, but I think each of our webapps only talks to at most one instance of each kind of database.

[timmc-edx]

Here's a pair of memcache spans, with common values removed. These are much more different from each other than the MySQL spans were:

service:django
operation_name:django.cache
resource_name:"django.core.cache.backends.memcached.get default"

{
  "component": "django",
  "db": {
    "row_count": 1
  },
  "django": {
    "cache": {
      "backend": "django.core.cache.backends.memcached.PyMemcacheCache",
      "key": "[REDACTED]"
    }
  },
  "language": "python",
}

service:memcached
operation_name:memcached.command
resource_name:get

{
  "component": "pymemcache",
  "db": {
    "row_count": 0,
    "system": "memcached"
  },
  "duration": 2148268,
  "language": "python",
  "network": {
    "destination": {
      "ip": "[REDACTED]",
      "port": [REDACTED]
    }
  },
  "span": {
    "kind": "client"
  },
}

In particular the presence of the cache key in the Django-level span makes it useful enough that I'd be reluctant to get rid of it.

[robrap]

The only potentially valuable thing I see on the defaultdb span is db.instance, but I think each of our webapps only talks to at most one instance of each kind of database.

Additionally, if we lose the service name and remap these to edx-edxapp-lms, and if we dropped the Django DB (ORM) spans, I think we'd lose whether we connected to defaultdb or the read-replica, but I don't see that as a wildly big deal. It also is not critical that we drop these extra spans either.

UPDATE: Unfortunately, if we remap the DB spans, the two share the same operation_name, so they may look very similar in a trace when the old service name (e.g. mysql vs defaultdb) won't be visible.