In the majority of cases, data displayed on such a screen will be non-interactive—people are expected to view it, but not click around. Such a requirement is posed because drilldown usually happens on individual workstations, leaving the main display accessible for others. Additionally, somebody could easily leave the main display in an unusable state, so no direct access is usually provided. This means that data placed on the display must not rely on the ability to view problem details. It should be enough for the level of technical support to gather the required knowledge.

Having to place all information regarding the well-being of the infrastructure of an organization can result in a cluttered display, where too many details in a font that's way too small are crammed on the screen. This is the opposite of the previous challenge—you would have to decide which services are important and how to define each of them. This will require you to be working closely with the people responsible for those services so that correct dependency chains can be built. This is the method used most often to simplify and reduce displayed data while still keeping it useful.

There are some more requirements for a central display. It should open automatically upon boot and display the desired information, for example, a nice geographical map. While this might be achieved with some client-side scripting, there's a much easier solution, which we have already explored.

As a reminder, go to Administration | Users, click on monitoring_user in the ALIAS column, and look at two of the options, Auto-login and URL (after login):

If we marked the Auto-login option for a user that is used by such a display station, it would be enough to log in once, and that user would be logged in automatically upon each page access. This feature relies on browser cookies, so the browser used should support and store cookies. The URL (after login) option allows the user to immediately navigate to a specified page. All that's left is that the display box launch a browser upon bootup and point to the Zabbix frontend URL, which should be simple to set up. When the box starts up, it will, without any manual intervention, open the specified page (which will usually be a screen or slide show). For example, to open a screen with an ID of 21 whenever that user accesses the Zabbix frontend, a URL like this could be used: http://zabbix.frontend/zabbix/screens.php?elementid=21. To open that screen in Zabbix's fullscreen mode, a fullscreen parameter has to be appended: http://zabbix.frontend/zabbix/screens.php?elementid=21&fullscreen=1.

When displaying data on such large screens, explore the available options and functionality carefully—perhaps the latest data display is the most appropriate in some cases. When using trigger overviews, evaluate the host/trigger relationship and choose which should be displayed on which axis.