It always surprises me how little the Azure Dashboard feature is used/talked. I think it is one of the greatest feature in Azure Portal and still many of Azure users are just using resource groups / resource listing to find resources they are interested of. With Azure Dashboard, you can bring all the resources of interest directly to the user, display current status of the services and give them quick navigation links directly into resource settings.
Dashboard Best Practices
I have used dashboards for many years and I usually build them at the early stage of the project. This way the usage of dashboards are early adopted and users will get used to them. It is important to build the habit of updating dashboards when something happens in the environment early on. In this post I want to share three practices that I’m using while using the dashboards:
- Build dashboards per environment.
- Use graphs and numbers. Avoid lists and collections.
- Share your dashboards
Build Dashboards Per Environment
Create new dashboard for every environment that your project/product is using. Create own dashboard for development, test, staging, QA, production what ever environments you have. By creating own dashboards per environment you can avoid mishandling of production resources. Own dashboards per environment empowers you to add graphs and statistics specified only for that environment. If your environment is using less than 20 resources you can think of splitting the dashboard per environment.
I usually split these small environments so, that production resources are on top and test resources at bottom (split view in half horizontally). This is because usually you start reading from top and the production resources are more important than test. Next I group dashboard vertically. I put app services on one column (test and prod, in their own halves), databases in own column etc. This way other users can quickly find test database, virtual machines what ever resources types we are having in that project. If I have resources that are rarely used, I usually place them on listings at the right side of the dashboard.
Use Graphs and Numbers
I always prefer graphs and numbers over lists and collections, because they give more insights what is really happening in that environment. Dashboard should give overall look of the environment and it status, so just using list of resources doesn’t help much. However I think it is good to list all the used resources somehow at dashboard. For example if your app/project is using Azure SQL, App Services, Logic Apps, Service Bus and Blob Storage. I will try to append all of these resources somehow into dashboard. For App Services you can use usage statistics, for blob storage you can show amount of data stored etc. It is also good practice to have some sort of navigation way into every resource that app/project is using. This way you don’t have to use search to find related resources.
For App Services I like to view server requests, exceptions and maybe page views / load time. If you don’t have too much requests you can combine these into one multipurpose widget.
Click Metrics chart (while editing the dashboard) and select metrics for resource, that you would like to add into dashboard.
Share Your Dashboards
By default the dashboards you create are private. No other users can access or view them. Remember to create shared dashboards with your team members. You don’t want to hide that precious information inside your own dashboard and let the others create their owns. You can share the dashboard by clicking Share button on top bar at dashboard page.
Each dashboard exists as a manageable item contained in a resource group within your subscription. That means that you can control it’s access right through RBAC. Since individual tiles within a dashboard can enforce their own access control requirements, some users with access to view dashboard may not be able to see information within some tiles. To ensure that users can see data within a certain tile, be sure that they have the appropriate permissions for the underlying resources accessed by that tile. I prefer that all project/app users should have permission to read all the resources that are put into dashboard. This means that you should not control permissions at resource level, but rather at environment level (not all users should have prod access).
If you want to learn from about dashboard sharing/access control, check this excellent Microsoft Learn page.
Summary
Azure Dashboard is a great tool that allows you to build convenient overviews of a project/product’s Azure resources. Use it to give a nice overview of current state of the Azure resources. Use graphs and numbers to improve the visualization and give better overview on resources status. In larger environments build dashboard per environment, but for smaller ones you can group all environments into single dashboard. Just remember to group environment specific resources somehow. For example by using the horizontal/vertical splitting.