5 Replies Latest reply on Dec 9, 2016 8:42 AM by Edward Gregory

    What risks or downsides are there with installing VizAlerts?

    Matt Coles

      Several people have asked what are the potential risks (security and otherwise) of using VizAlerts. The great thing about this being a free and open source project is that we don't have anything to sell, so there's no real pressure to convince anyone to use our tool! This discussion endeavors to compile reasons VizAlerts may not be something you'd want to install and use on your Tableau Server instance.




      1. Users can often be confused about the disabled subscription schedules you must set up in Tableau Server. They'll subscribe to them, thinking they are normal subscription schedules. The extra schedules also tend to clutter up the schedules list, depending on how many you create.
        1. Mitigation: Name your schedules such that it's obvious what they're for.
      2. Helping people understand how to set up a VizAlert for their own content can take some effort. Some folks read the User Guide and are off, others think that VizAlerts is magical and will automatically alert them when their data "changes"--which it won't.
        1. Mitigation: Build a monitoring dashboard that shows you subscriptions to Tableau Server schedules, and use a URL action with a mailto: link to send them an introduction email with helpful tips and links to the documentation (the current data in the PostgreSQL repository database for Tableau Server unfortunately isn't conducive to building this into a VizAlert   )
      3. Additional effort is required on the part of the Administrator to manage this service. What if the host you're running VizAlerts on goes down? What about when alerts go out late? What about when a new version of VizAlerts is released? It's all additional work.
        1. Mitigation: Not sure there really is one for this...



      1. The main risk from a security standpoint is that someone will author an Advanced Alert that automatically emails the wrong data to the wrong person--worst case, outside your organization.
        1. Mitigation: Use the allowed_recipient_addresses field in the configuration viz to limit the addresses / domains that each user can send to. Potentially, disallow any email action by all users as a default (default_action_enabled_email parameter), then grant access for individual users on an as-needed basis (action_enabled_email field).
      2. If you do not use encryption to connect to Tableau Server, nor to your SMTP server, the data VizAlerts is pulling, and then emailing, can be intercepted. Additionally, it's possible to intercept and redeem the generated trusted tickets, which could then be used to pull data from another, more secured viz.
        1. Mitigation: Use...encryption.


      1. Because schedules in Tableau Server don't have permissions, virtually anyone can subscribe to a VizAlert on any custom schedule you create, more Tableau Server resources will be consumed. In particular with Tableau 10's "subscribe others" functionality (which is great, btw), someone may build an alert and subscribe a large number of others. VizAlerts will then run the alert for each person individually, refreshing all of the data in the viz each time.
        1. Mitigation: Set timeouts on the more frequently-running schedules to prevent Server resources from being misused. Encourage popular alerts to convert to an Advanced Alert, which can use up less Server resources if built correctly. You can also require approval before a user is allowed to use VizAlerts, if you so desire.



      1. VizAlerts is an open-source tool that comes with no warranty or promises of support. At the time of this writing, there are only two contributors who answer questions and fix bugs as they have time and inclination to do so. And they're not great at Python, either!
        1. Mitigation: It's open source. Know how to code? Come help.
      2. A future Tableau Server product change could break VizAlerts (for example, if disabled subscription schedules no longer showed in the drop-down picker when a user went to subscribe to their view).
        1. Mitigation: Okay, not so much a mitigation, but it may make you feel better--internally at Tableau, we adopt early Betas of Server and run them on our production environment. This means we're testing VizAlerts on newer versions of Tableau Server ourselves before the product ships. Will we run VizAlerts for forever? Probably not, but for at least the foreseeable future.


      Thanks to Jonathan Drummey for answering this question here as well.


      Feel free to add responses to this if you can think of additional risks or problems that can be introduced by using VizAlerts.

        • 1. Re: What risks or downsides are there with installing VizAlerts?
          Edward Gregory

          Matt - Thanks for this information as we were looking into possibly using VizAlert but our administrator said the following when I asked if we could install VizAlert:


          "We have an external facing site and this requires a Python installation to run, we can't do it. Other Tableau admins have expressed reservations about server security/stability as well."


          Are there any viable options to address these concerns? Also, do you know if a compiled windows installation in the works? They would install it if there was a compiled windows install.



          • 2. Re: What risks or downsides are there with installing VizAlerts?
            Matt Coles

            I've recently started playing with compiling to an exe and got something working--ostensibly with the next major release, I should hope! Having that will definitely make the install process easier, too.


            Currently my Server instance is processing 100 unique alerts (views) with VizAlerts, with 170 subscriptions to them. Stability on our Server has not been an issue--but we are also a very large installation, with six physical hosts powering things. Timeouts on schedule frequencies have kept heavy-hitting alerts from running too often, which is configurable in VizAlerts.


            We've actually improved the stability of our server, and underlying ETL systems, by running VizAlerts. It's been a canary in a coal mine, because it runs every minute, and each time it does it's testing VizQLServer processes. Just last week we saw errors start hitting us from our Singapore instance, and sure enough, one of our VizQLServer processes had gone down and stayed down. Additionally, we've found problems with our data during hours that people typically don't look at the data, and found some problems with bulk processing of updates in our SQL Server instance. We would not have found that problem and been able to fix it without VizAlerts.


            So, that's what I can say from my own experience. If you're not willing to run our code against your Server instance, and instead are looking for some simple alert functionality that's supported in the product, I'd check out Conditional Subscriptions, new in the 10.1 Beta that has been released. It's very similar to what VizAlerts does, with the Simple Alert feature anyway (doesn't do the fancy stuff we can do, though).

            • 3. Re: What risks or downsides are there with installing VizAlerts?
              Edward Gregory

              Thanks so much for the information Matt, much appreciated.

              • 4. Re: What risks or downsides are there with installing VizAlerts?
                Matt Coles

                Updated for new 2.0.0 features.


                Also FYI Edward Gregory, I was unable to ship a single executable for VizAlerts in the last release, primarily due to one of the libraries we use not working well with it. I am hoping we have a solution for that for 2.1.0, but it'll depend on others stepping up to assist.

                • 5. Re: What risks or downsides are there with installing VizAlerts?
                  Edward Gregory

                  Thanks Matt for the update, I appreciate you letting me know the status of Viz Alerts.