1 of 1 people found this helpful
Hi Julie -
Can you help us understand why this Server was purchased? At the highest level, are you using it to serve "IT blessed" reports to a large number of users? Or, is it more of a collaboration / sharing environment to help foster an analytic culture in your organization?
If you're leaning more towards the latter, then you're probably going to have to put up with a certain amount of bad authoring from your users. They don't know what they don't know, and if you add too much friction to the process of publishing / sharing ...they just won't use Server and you won't get the levels of adoption you're hoping for.
If your group and a few trusted authors will be doing all the work of authoring (more of a legacy "report factory" approach), then lock that sucker down. I've known some companies that simply tell their people to drop workbooks they want published in a fileshare, and then IT takes it from there. Folks on the IT staff look at the workbook, make sure it isn't doing anything "evil", and then publish, else return it to the author with some suggestions.
In terms of the sandbox idea: from a licensing perspective, be careful that your "sandbox" stays a true non-production environment (unless you purchased 2 production servers). Tableau gives you two non-prod environments with Server, but they really are for "back office" use. In other words, if your users are actively connecting / publishing to it...it's production.
When you give your users an easy way to access the data they want (via a Data Server data source), users aren't generally going to be particularly interested in writing lots of custom SQL - at least that's what I've found -- they take the path of least resistance. So, I'd suggest that you pre-create data sources that hit your important databases, publish them to Tableau Server, and then "encourage" (or even force) all questions to your RDBMS tier to go through those "blessed" data sources.
At Tableau, our internal Tableau Server is "wide open" from a publishing standpoint. However, the databases which most people use are monitored very closely. If you write some nasty cross-join that takes too much time to run on the database, the query is simply killed (automatically) and you get a nasty-gram in the mail. I personally think this is a pretty good compromise because:
- It encourages all the good stuff that you WANT to encourage (creativity, experimentation, thinking outside of the box, etc.)
- It protects the data systems from "dumb stuff"
- When you author, you do so keeping in mind "My query will get killed if I do something obnoxious, so I might as well do it the 'right' way up front"
- It encourages users to leverage the "blessed" data sources that are pre-published to Tableau Server and vetted by IT, because users know they "just work" and are risk-free.
Hope this helps! Good luck.
1 of 1 people found this helpful
Some details about the usage: we are a big organization (more than 80k employees)
- we have multiple "teams" - and they are not really related, so they will have their Site (i.e. HR, Finance, Marketing)
- Some are serving a large population of users and already organized with IT / Data specialists and internal process for deployment of their reports - they are not the issue
- Some are business / regular users and they sometimes have access to "Custom SQL" (and they like it...). Some of them load huge file into Extracts, very slow. They are my main concern.
- We have too many databases to control at the Database Level - I'm not sure how many databases exist but it's more than 200.
We already have a server with more than 1000 users - and around 25 sites: and it's going well. Except for controlling users without skills.
I managed to monitor all reports "response time" (average) to detect slow reports to improve. But it's hard to get people to improve them: they already are consumed by the audience and I'm constantly running after people to request improvements.
In future environments, I want to restrain Live Connections and control what is happening before it's too late.
My team is responsible of the Server, managing access, projects and security - we are also supporting the community of users (more than 500 developers, and it's growing fast)
With this context, I have still my 2 questions:
1) How to monitor content and make sure only efficient dashboards are uploaded on production?
2) How to block publishers for Live Connections - opening this option only when the connection is fast / verified / documented?
Based on your previous post, I have the feeling that I will have to prepare a manual monitoring...
If authors are using Desktop and not publishing to the Server then you won't be able to block Live connections
Yes, Custom SQL option can get in the way. I always tell my users that unless they are total experts for the SQL dialect they are connecting to they will not have a fast workbook compared to using Tableau's drag-n-drop query building. Even if an expert there typically will be performance hits.
I don't want to block Tableau Desktop connecting to SQL Live. I want to avoid Live Connections on the Server (only).
If a user push a dashboard taking 300 seconds to load - it's impacting all my users; I want to control the connection that will be activated on the server only.
1 of 1 people found this helpful
For monitoring help check out Michael Chen's blog post: New Views for Tableau Server Administrators— BI on BI
Item #4, Extract Error Monitor, is the one you'll likely be interested in.
Here's the conversation about it here in the forums: New Views for Tableau Server Administrators — BI on BI
Yes - this is the way I was planning to monitor (if nothing else available) - our current monitoring dashboard is very nice (I can already detect "monster dashboards") but it's taking a lot of resources to refresh Postgresql data (and http requests is huge) - so before going 100% this way, wanted to be sure that nothing else can be done.
Would be nice if the role of publisher was split in 2: publisher (data embed only) / publisher (live connection)
Would be easier to control (I would activate the role only when needed)
But thanks for your answer... I will begin to work on a monitoring that is not only weekly but daily (detecting new workbooks right away and inspecting the content / design).
Will be a lot of job still - more than 15,000 views were uploaded in the last 4 months!
Another thought on this subject -- Is a 300-second viz really "bad"? My initial reaction would be "sure", must be. But, I suspect there is a pretty big difference between a viz which is "actively working" the entire 300 seconds (like a chart that needs to render millions of marks or which spins up a data engine which does a lot of work), and a viz which executes a query and then simply sits there and waits for a response.
While neither are good, the first is without-a-doubt "bad". The second? Don't know. We'll certainly be holding on to some resources (RAM) for the vizqlsession itself, and we'll "hold onto" some threads on the CPU longer than normal, but I bet we're not churning the CPU, which is where you're generally going to bottleneck and what will eventually cause your users to complain. What I'm getting at here is render time may be too simple a metric to really attack the problem you're trying to solve.
Tamas Foldi did some work for a Tableau Partner that actually monitors this stuff at a very low level. I wonder if he has any insight on the subject?
In fact, the software he helped create is pretty bad-*** and can monitor CPU usage on a per-user or workbook basis - kind of sounds like something that would be useful for you. (Of course, it means more spend). You might want to check it out: Palette Software
Good point - in fact, workbooks trying to display 84 little worksheets in one view or views trying to display 3 millions marks are popping in my monitoring tool, showing as bad as workbooks trying to open a monster SQL.
All these weird cases are part of the list of "Workbooks to remove or improve" list of fame...
I'm basically measuring the user experience here - and it's closely related to the server performance since a workbook with a poor user experience will require more CPU / VizSQL resources (probably).
I will keep in mind the monitoring at the CPU level (not sure if IT will allow this to be installed - but could be a good thing if we end up with issues).
I will probably share my monitoring dashboard for the server on my profile soon: it's by Site / by Workbook - and showing what site is offering the best "user experience". Then you can drilldown to workbooks.
The fact that this dashboard is accessible to everyone in the company is helping: I see people really working to improve their material...
Thanks for all your answers and guidance, again
Be the Viz with you!