1 of 1 people found this helpful
Thanks for bringing up this topic!
I work with Trevor so I of course echo all of those points.
To expand a little on #1-3 from Trevor: each day we see our backgrounders fully saturated with priority 0 extract refresh tasks from around 4am all the way through 2-5pm, which effectively breaks the subscription functionality for us and also makes it impossible to "fast-track" a high priority refresh in the middle of the day. A quick(er) fix would be to allow tabcmd to pass a priority parameter with its refresh commands. An ultimate "would be great to eventually have" solution would be a built-in server admin dashboard that allowed full, real-time control over the pending tasks queue, including the ability to:
- Remove any pending task from the queue
- Kill any in-progress task
- Adjust the priority order of the pending tasks queue (drag-and-drop would be great)
Something else that would be great to have is more control/dynamic configurability of the Tableau Server process threads in order better utilize the available hardware based on expected load patterns. As a simple example let's say we are currently configured with 4 vizql threads and 4 backgrounder threads. Currently we would just be stuck with that ratio all day and all night. It would be better if we could build a schedule-based configuration such as the following:
- 12am-6am: 1 vizql thread, 7 backgrounder threads
- 6am-8am: 2 vizql threads, 6 backgrounders
- 8am-8pm: 4 vizql threads, 4 backgrounders
- 8pm-12am: 2 vizql threads, 6 backgrounders
Next, extended (or configurable) duration of stored PostgreSQL/Repository activity data would be great too. A few times in the past we have had to resort to restoring a full PostgreSQL prod backup to our dev machine just to find context surrounding a single event since the table of interest happened to truncate off after 7 days. If we could define the truncation point as 30 or 90 days instead it would go a long way in reducing the chances of having to take such drastic measures.
Lastly--and this one might be a little nit-picky--it would be nice if the built-in Tableau Server Status reports were given a bit of love. In particular we will access the "Background Tasks for Extracts" page multiple times per day. By default it filters to a max runtime of around 9000 seconds which hides any of the longest-running tasks from immediate view. It also defaults to the last 24 hours only. It would be great if we could configure default filters for this (and all other) built-in status pages instead of changing them every single time. Also specific to this report, it'd be great to be able to see a per-extract run-time histogram to help quickly identify outliers or potential new performance issues caused by a recent development change. I realize we could build something like this ourselves, but it might help overall client adoption if the baked in reporting had more features.
While these provide yet another source of info they still lack guidelines or "rule of thumb". For example, if setting up a primary node in a multi-node environment and the primary only runs the gateway, repository, and search/browse processes then how many cores/RAM/drive space should it contain at a minimum? What if those hardware items were increased? Or when should they be increased?
Hi Tableau Admins,
Have anyone experienced somthing like this:
Our backup runs every day and is about 80GB size. In the past 6 days it have grown to 128GB and the users have NOT started to store additional TDE files....
I looked on our 2 workers and a lots of big TDE files are being left behind. A user does a refresh everyday of his datasource and there's a TDE file
for the past 6 days left on the two workers. I did not think the "revision" history was ment to save TDE extract files, only workbook information and maybe datasource metatadata
information. I have opened a case with Tableau.
1 of 1 people found this helpful
As well as the ability to clone an existing user/group it would be good to be able to "log in as" as specified user to see what they can and cannot see. Often you get a support ticket saying something is not working correcrtly. Although later versions of server make it easier to see the assigned permissions this doesnt help if something like user filters have been used. In this case it would be great to be able to login to server as that user and see the server through their eyes.
I agree this would be very nice, however, there could be security concerns with it: HR and Finance come to mind.
2 of 2 people found this helpful
Agree with integrating TabMon. However, I'd like to see integration with Logshark as well. Too many answers come from logs that are very difficult to parse and understand.
But wouldn't you have to have access to that data regardless if you were diagnosing an issue as a server or site admin?
Yes, as an admin, you already have access to that data/workbook.
Yes, if you were diagnosing and the Owner gave the appropriate permissions. The ability to access any data via impersonation as anyone is a security issue. Several of my [HR] authors like the fact that even I cannot see other's data (row-level security in-effect).
One thing I would like to see is when you are permissioning the projects is to allow us the ability to define our own custom roles so that we can just select them from the drop down knowing that we have already defined the proper security for each project, workbook or data source permission.
Please hold these sessions during APAC business hours – I would like to participate live but I am asleep during this time.
couple of things from me. I hope it is not too late to cover it
1. More flexability for embedded data sources while publishing/ refreshibg. I have couple of datasources in workbook and extracted some data. During the publushing, for some of them the refresh schedule will work and set it. but uf I have just one that will fail - all extracts refresh will be failed because of that one. Also for sone of tham I want to include external files for some not.
-set refresh schedule for each embedded data source
-set and choose include external files for each embedded data source
2.Improve processes alerts. Sometimes Tableau Server processes can stick or freeze. In that case Tableau Server will not send alert and application is still unavalible.
-scan i/o or any othere OS metrics and send alert that the process is stuck
3. Improve intallation process. During the install of Tableau Server there is no option to restore from back up in installation wizard. You have to install it, configure and run it, also add admin account... But these settings were on last installation. Why should I do it again from scratch? ;(
- add option to restore from back up while clean install (from scratch) and pick up config files and settings
4. Improve parallelism on distributed envs. Found that some tabadmin commands are done machine-by-machine. Like ziplogs, configure... I think that can be improved to speed up them.
-improved parallelism for rabadmin commands for cluster env
5. Clean up All Users group.
if you have sync process with AD then All Users group will have all of them, even when is deleted (deactivated) from AD groups.
-add availability to clean up All Users group
6. Options for case sensetive protections for usernames.
That would be great if Tableau Server will have case options for usernames. It could be general settings for whole server or per AD group. Now, we have an issue that for some users username on Tableau Server is lower case and some have uppercase latters. AD group has all of them in lower case. We are under investigation. But as far as I understand username can be in lower case or uppercase. Snd there in no control on app site ;(
-make Tableau Server usernames case insensitive and have options to force it in settings.
As a tableau server admin, you already have access to everything anyway.
Have you tried to clean log files? You can use "tabadmin cleanup" command. It usually reduce the backup size.
One issue that we have been dealing with lately is Desktop deployment, I believe that could be integrated well within Tableau Server. Give Tableau Server the ability to interact with the Customer portal and allow it to manage the distribution of the desktop licenses within the enterprise. For instance, once you install Tableau Desktop, give the user the option to enter a license key the traditional way, or allow them to log into Tableau Server, if their account has been added to an AD group or a local group of Tableau Desktop users, then allow server to grant that desktop a key. You could give the admins an option to set a weekly login to server to maintain the key and could allow for the flexibility to change users by removing the license from desktop after a week of no connection to the server. We only have about 10 licenses now, but I can imagine this is an issue for many Server and Desktop admins.