Dashboards are part of the content packs. There are some best practices that apply when creating dashboards.
When creating dashboards, the following best practices apply
Content packs usually contain a minimum of three dashboards. The best practice is to start with an overview dashboards to provide high-level information about the events for a particular product or application. In addition to the overview dashboards, dashboards should be created based on logical groupings of events. The logical groupings are product-specific or application-specific, but some common approaches are performance, faults, and auditing. It is also common to create dashboards for a component, like disk and controller. With the component approach, it is important to note that it is only effective if queries can be constructed to return results from specific components. If this is not possible, then the logical approach is recommended.
When you name dashboards, make the title generic and avoid adding product-specific or application- specific names unless being used in a component specific fashion. For example, in the VMware - vSphere content pack, there is a dashboard groups called ESX/ESXi instead of VMware ESX/ESXi.
Dashboards must contain a minimum of three dashboard widgets and a maximum of six dashboard widgets. With any less than three dashboard widgets the amount of knowledge that can be attained by dashboards is minimal. In addition, having a lot of dashboards with only a limited amount of dashboard widgets requires a user to switch between different pages and does not provide information in a coherent way.
Conversely, any more than six dashboard widgets for dashboards can have negative impact. You might get too much information that might be confusing. Too many widgets require intense usage of your system resources, as each widget is a query that must be run against the system.
When you include more than six dashboard widgets in dashboards, you must separate the information and create multiple dashboards. If a dashboard widget is applicable to one or more dashboards, create the widget in each applicable dashboards.
Dashboard filters can be used to drill down to specific events. The filters function similar to the filters on the Interactive Analytics page and leverage fields to drill down. Every dashboard should have at least one dashboard filter, typically with the hostname field, but up to five fields can be added to each dashboard.
The field added should be used by the majority of widgets on a given dashboard so that if the dashboard filter is used, most of the widgets return results. Examples of dashboard filters could include a severity field, a user field, or even a component field.
The field and the operator used by the dashboard filter will be saved in an exported content pack. Any value used by a dashboard filter will not be saved during export as the value is likely to be specific to an environment and not generic to all environments.