Hi All,

I’m on version 9.0.0-beta and my main goal here is to query Redash usage data (what are the most viewed dashboards? which objects have not been used a long time and could probably be deprecated? etc).

I found evidence that this is or has been possible in the past:

select * from events where object_type='dashboard' and action='view' order by created_at desc
from this thread.

I have tried querying the Query Results data source for an events table and found nothing (slightly related, I’m unable to see what tables/schemas are even available in this data source; I tried SQLite’s syntax to no avail: .table , .ta and .tables all failed).

If I am looking in the wrong place or if having an events table depends on whether I’m self-hosted or not, I would love to know.

Hope this yields insight and helps others.

Thanks!

QRDS uses an in-memory SQLite database. It has no tables in it until you use it to query another query result.

What you want is to connect with Redash’s internal metadata database. The exact method for this varies depending on your installation. But ultimately you’ll add it like any other Postgres data source.

On the development Docker instance this is easy because the Postgres server is aliased as postgres within the containers. So you can create a data source with postgres as the host, user, pass, and db :wink:

FYI: the events table can be used for this but it’s not designed for it. For page views it’s fine but it won’t help if you want to know every time a query is executed, for example.

Hey @jesse

We are using the events table to do user level auditing in v8, We are testing v10 right now and it has the same issue.

Events table has no data in it. i have plenty of saved queries. Is there any particular reason behind this or it is a bug ?

Interesting. We’ve had a few reports of this

But no real conclusion to what caused it. I don’t observe this behaviour with the V10 beta, however. Can you try it?

Hi, have the same problem with v10.1.0, nothing in events table after update from V8, but we need this table for audit purposes

1 Like

Thank you for bumping this. The struggle here has been an inability to reproduce the problem by members of the core team. I will give it another try today. If not, we can’t do anything about it without a reproduction. But we are of course happy to merge a PR fixing it (and a 10.2 release) if someone in the community has better visibility into the issue than do we.

We have the same problem with version 8 and after the update from version 10.1.0, nothing in events table. We use this table for audit too.

We’re still without a reproduction on this. Until we can reproduce it there’s no way to debug / fix it :frowning:

I understand, but we did a test… we took a clean image of Redash version 8.0.2.b37747 and another with version 10.1.0.b50633, in version 10 we have the problem, but in version 8 we don’t. Could you take an original version of 10, and deploy it in an environment, to check if the error occurs?

Bumping this, since we have the same issue when we upgraded from v8 to v10.0.1 and still running into this. Can you see if the clean install helps with repro?
Alternatively, what else can we use to audit events in redash?
TIA
Additional information:
When I look at the docker logs for server container, I see the POST to the api endpoint is returning a 200 reponse. Yet nothing in the DB table.

FYI @lscapim I did exactly what you recommended…and still not able to reproduce this at all.

  1. Deploy the v8 AMI
  2. Upgrade it to V10.1 (latest release)
  3. Click around, run some queries
  4. All events appear on the events table as expected

I show no gaps or strange behaviour.

Where exactly are you looking for events? Are you connecting to your metadata database? Or are you looking with QRDS?

I was able to fix the issue, might not be the ideal solution, but want to share it here for everyone’s benefit.
Debugging steps:

We are running V10 of Redash on ECS.
I issued a “query refresh” from IU, logged onto the redis container, and ran a :

 docker exec <container> redis-cli monitor

The event queries were getting queued in the default queue: rs.queue.default - but stuck there and not picked by workers.
This might be related to the bug Job queued but not run · Issue #758 · rq/rq · GitHub

Resolution:
Swapped the queue from default to queries(this is not ideal and I am going to create a dedicated queue for events, but for testing sake used the queries queue)
here : redash/general.py at 2589bef1f21b7c84e4ceacdf5cd2c620bdedb111 · getredash/redash · GitHub
after building and verifying it was using the queries queue, I was able to see the events in the database.