Tableau Love

Monitoring Tableau

Yes, TabMon can be just like “those meddling kids”. It will prevent second-rate villains like pegged CPU, poor disk speed, and low RAM from spoiling your Tableau experience.

Before you go further, make sure you visit these. They are “primer” material:

TabMon is like a Fitbit for your Tableau Server

TabMon on YouTube: A Tour of the TabMon Sample Workbook

Standard Disclaimer

TabMon is not directly supported by the fine folks at Tech Support. You know that already.

What we’re going to get into here is a bit mind-bendy. Just a reminder that you need to sink or swim with this material on your own. Or, perhaps use the Server Admin forum….but don’t go to tech support. They’re not supposed to help you get this stuff working, and I don’t want them coming after me in my sleep…because they do go ninja sometimes.

The Server Health infrastructure that TabMon relies on is quite rich. By default TabMon monitors things that most people care about. But you’re not most people, are you? You’re one of those “go further” people, I bet.

Well, we can go further and take advantage of ALL of the Server Health goodness if you know how to access it.

Let’s do it

Ready for the red pill? Begin by watching this:

Pretty neat stuff, huh?

To recap:

• You need jconsole, which is part of the Java SDK
• You need to make sure that JMX is enabled for monitoring (TabMon documentation explains how to do this). For good measure, make sure you can get through the Windows Firewall on the server, too
• Use jconsole to connect to a specific port for the service you care about: service:jmx:rmi:///jndi/rmi://host:port/jmxrmi
• You can identify the ports to connect to in tasks.yml – look for com.sun.management.jmxremote.port=? entries for each process you want to monitor (and keep in mind some of them don’t support monitoring)
• You’ll find basic stuff on the “Overview” tab, and cool stuff on the Mbeans tab under tableau.health.jmx
• Reminder: If you have two (or more) copies of a process, you want to monitor each one.

Here are a list of primary URIs that you can use. The ports MAY be different for you, but generally won’t be:

Vizqlserver
service:jmx:rmi:///jndi/rmi://host:9400/jmxrmi (vizql #1)
service:jmx:rmi:///jndi/rmi://host:9401/jmxrmi (vizql #2)

Tableau Server Application Server
service:jmx:rmi:///jndi/rmi://host:8900/jmxrmi

Data Server
service:jmx:rmi:///jndi/rmi://host:10000/jmxrmi (#1)
service:jmx:rmi:///jndi/rmi://host:10001/jmxrmi (#2)

There are others, but the information you’ll find there is less interesting (at least to me).

…and here is a (quite incomplete) list of counters that I think are particularly cool. If you play with different items, please post ’em in the comments section. Tell me what they do, and I’ll add them to the encyclopedia JMX. There are TONS of these suckers, and I’ve just started playing…

UPDATE [27-Mar-2016]. MBeans associated with the App Server process no longer work in 9.3. See this post for more info

Process	Category	Description	Counter	Description
Vizql	vizqlservice	All counters for vizql are here.	RedisConnectionPoolBlockedRequests	Counts the number of times the Redis Cache Server was "busy" when VizQL wanted to talk to it
			SessionsInFlight	The number of active sessions actually doing work on the server at the moment of measurement. A pretty good measure of "concurrent users".
			SharedSessionsFullSharedHits	When two or more users execute the same viz and DO NOT apply filters to "personalize", the viz can be served from a single, shared vizqlserver session. Modifying / filtering the viz will spawn a new (unshared) session.
App Sever	webclientappservice. create {comment project, subscription, schedule, site}	A set of counters which allow you to see when comments, projects, subscriptions, schedules and sites are created.	Average Request Latency	Avg amount of time to complete in ms
			Requests Failed	Requests which failed
			Requests Processed	Total # of requests to create
	webclientappservice. delete { comments, data sources, extract tasks, projects, subscriptions, schedules, sites, workbooks}	Tracks a user deleting one (or more) of the items listed in "Category". For example, webclientappservice.deletesites reflects the deletion of a site in the web portal	Average Batch Failure	Number of failures in the list of selected items which were tagged to be deleted
			Average Batch Size	Average number of items (workbooks, schedules, etc.) that were selected together to be deleted in a batch
			Average Request Latency	Amount of time to carry out the task
			RequestsFailed	Number of batched requests for deletion which failed.
			RequestsProcessed	Number of batched delete requests
	webclientappservice. login	Tracks login activity	AverageRequestLatency	Average time-to-login
			RequestsFailed	# of Login requests which failed (bad username, password, etc.)
			RequestsProcessed	Number of direct (non-REST, non Trusted Tickets) login attempts
	webclientappservice. logout	Tracks logout activity	AverageRequestLatency	Average time-to-logoff
			RequestsFailed	# of logout requests which failed (don't know how this would happen, but there you are)
			RequestsProcessed	Number of direct (non-REST) logout attempts
	webclientappservice. setexplicitpermissions	Indicates a user or admin changed permissions on a viz or data source	AverageRequestLatency
			RequestsFailed
			RequestsProcessed
	webclientappservice. setprojectcontrolledpermissions	Tracks if the permissions of a project have been changed from "Manager by an Owner" to "Locked to the Project" or vice-versa	AverageRequestLatency
			RequestsFailed
			AverageRequestLatency
	webclientappservice. set{workbook, project}owner	Increments when the owner of a workbook or project is changed	AverageRequestLatency
			RequestsFailed
			AverageRequestLatency
	webclientappservice. updatesiteavailability	Indicates a site has been disabled and/or re-enabled	AverageRequestLatency
			RequestsFailed
			AverageRequestLatency
	webclientappservice. updatesitesettingsforadmin	Watches whether an admin modifies site settings (disk quota, web authoring, perf reporting, etc.)	AverageRequestLatency
			RequestsFailed
			AverageRequestLatency
	iclientxmlappservice. publishdatasource	A client published a data source to Tableau Server	AverageRequestLatency	Average time to publish. Includes extract upload time.
			RequestsFailed	Failures
			AverageRequestLatency	Number of publish attempts
	iclientxmlappservice. publishdatasource	A client published a workbook to Tableau Server	AverageRequestLatency
			RequestsFailed
			AverageRequestLatency

See why this stuff could be so useful? For the security-conscious it would be very useful to know when someone changes permissions on a workbook or project…or modifies the owner of something….or rebuilds the search index (what are they trying to HIDE, I ask you?! A conspiracy theorists dream)

I’ve only dug in briefly on the iclientxmlappservice counters – there is lots of work there for someone to do 🙂

Telling TabMon how to Monitor Tableau

After you’ve selected a bunch of new counters you want to track you need to convince TabMon to watch them for you.

The video below explains how:

And with that the trilogy is complete and I can go on vacation. Enjoy, see you next year and please add to the list of stuff above!