bitlabstudio/django-influxdb-metrics

When TIME_ZONE is set, the data is not stored in Influxdb

AdrianRibao opened this issue · 3 comments

Settings the TIME_ZONE setting makes the middleware fail to log the values.

Having:

TIME_ZONE='Europe/Madrid'

and executing the query:

select * from django_request

returns nothing.

As stated in https://docs.influxdata.com/influxdb/v0.12/write_protocols/write_syntax/#timestamps there is no need to send the timestamp. Also when is needed it should be in unixtime and nanoseconds.

Assuming this, it's safe to remove the time field from the data send to influxdb.

I've created the PR #5 that fixes this issue.

@AdrianRibao amazing pull request. I have never worked with Docker, so please give me some time to review this. I am actually planning to upgrade our infrastructure to the latest InfluxDB and Grafana version this week or next week, after that I will take of this repo.

ok @mbrochh let me know if you need help :-)

Hold on a sec, this may be a bad idea! :D

If you're hitting the same thing I hit, which I think you are, it is not that the data is 'not stored in influxdb' it's that your times are out (due to not using Django's timezone.now() and therefore not respecting timezones), so you're sending events an hour in the future etc.

You can query and see your data in this case by changing the time filter to include future events (influx by default filters to time < now()). For example:

select * from django_auth_user_login where time < now() + 1h

And you should see your missing data.

However I think we still want to always send the time in case there is some network etc. error, or Celery is down, or your InfluxDB database is down. That way once Celery/DB is back up the waiting tasks in your task queue can get processed and the event times will be correct to the time they actually occurred in your app.

At the very least I think whether to send a time or not should be optional, perhaps default to on, but disable via a Django setting?

See my PR which adds timezone awareness: #10