Part 1 is here.
Now we talk about the two most important tables you’ll work with:
- historical_events
- historical_event_types
As I mentioned previously, it’ll be pretty rare when you don’t use these two together when creating custom admin reports. Why? Because historical_events tells you something happened, but historical_event_types tells you what that something is.
historical_events
First, let’s look at historical_events. I’m including a field list which explains what each field does and part of an ERD which points out which fields are primary or foreign keys:
As you can see, most of the fields here are simply foreign keys to other history-related tables. The only four fields which contain “real” information are:
- Worker: The IP address of the machine which performed the task
- Is_Failure: If something went wrong (for example, an extract refresh fails), this column will return “TRUE”
- Details: A mostly empty field which sometimes is populated with info like : “Finished refresh of extracts (new extract id:{FAE9889E-2A72-47FE-9919-58C07B35632E}) for Workbook ‘Book2’ ”
- Created_at: When did this activity occur?
Note that the duration_in_ms field has not been implemented yet. You’ll want to use the standard admin reports or performance recording to do perf tuning – not this table.
historical_event_types
historical_event_types is where the fun stuff is – It tells you what each historical_event_type_id value in the previous table actually means:
The table itself is quite simple, not too much to say about it. However, its contents are quite important:
EGADS, that didn’t paste very well. Here, just download the workbook itself.
I’ve changed the color of several rows to grey – they represent events that don’t have anything to do with your Tableau Server – I’d guess that this stuff was added so it could be used by Tableau Public or other projects?
There are a few events worth calling out:
- Events 60-65: When you publish a workbook or data source, you don’t immediately have to associate it with a schedule that fires off tasks (for example, a refresh task). These events track someone doing so after a publish is complete
- Events 66-69: Here we’re tracking someone actually changing the schedule a workbook or data source is associated with.
- Event 84: Access View. This is a user executing a view.
- Event 135: Did you know you can append data directly into a Tableau Data Server Data Source from Desktop? Well, you can. And there’s an event to track it.
Summary
We’ve scratched the surface of what you can do with the history tables – here are a few quck-and-very-dirty reports using what we’ve worked through thus far:
Logins and report executions by time. You can totally see when I’ve been on vacation because of the gaps when no reports were rendered on this box. You can also see me executing tons of reports with just a few logins. Finally, we’re looking at data all the way back from November through yesterday.
Same report, but with my workers as a small multiple. I turn the second machine off at night, so in the report below you can see it’s not executing background tasks very often:
You can also see the “is_failure” field is play – and I’ve never had a failed extract refresh since I stood this server up in November. Hooray for me!
OK, we’re done. Final report – Logins by user by time...including the very FIRST login per user:
Next up – an “all those other tables” extravaganza
