Part 5: Building Observability Dashboards with KQL

From Queries to Dashboards

After mastering KQL queries, I learned that the real power comes from building dashboards that provide continuous visibility into system health. In this part, I'll share my experience creating production observability dashboards using Azure Workbooks and visualization techniques.

Understanding Azure Workbooks

Azure Workbooks transform KQL queries into interactive, visual dashboards. Think of them as parameterized, shareable notebooks combining queries, text, and visualizations.

Why I Use Workbooks:

  1. Interactive parameters - Users can filter without editing queries

  2. Multiple visualizations - Charts, grids, tiles, and more

  3. Reusability - Share across teams and subscriptions

  4. Real-time data - Queries run on-demand

  5. Version control - Save and track changes

Creating Your First Workbook

Let me walk you through building a workbook from scratch.

Step 1: Access Workbooks

Navigate to your Log Analytics workspace β†’ Workbooks β†’ New

Step 2: Add Parameters

Parameters make dashboards interactive. Here's how I structure them:

Parameter configuration:

  • Name: ResourceGroup

  • Display name: "Resource Group"

  • Parameter type: Drop down

  • Allow multiple selections: Yes

  • Default value: All

Step 3: Building Query Components

Each visualization starts with a query. Here's my standard structure:

Visualization Types I Use

Perfect for showing metrics over time.

Visualization settings:

  • Chart type: Line chart

  • Y-axis: AvgCpu

  • X-axis: TimeGenerated

  • Series: Computer

2. Bar Charts - Comparisons

Great for comparing values across categories.

3. Pie Charts - Distribution

Show proportional data clearly.

4. Tables/Grids - Detailed Data

Essential for detailed information and drill-down.

Grid settings:

  • Enable column formatting

  • Add conditional formatting for health status

  • Make columns sortable

5. Tiles - Key Metrics

Display important numbers prominently.

Tile settings:

  • Title: "Error Rate (Last 5 min)"

  • Subtitle: "%"

  • Use color thresholds:

    • Green: < 1

    • Yellow: 1-5

    • Red: > 5

Production Dashboard: Application Health

Let me share a comprehensive application health dashboard I built:

Dashboard Structure:

  1. Parameters Section

    • Time range

    • Application name

    • Environment

  2. Overview Tiles

    • Request rate

    • Error rate

    • Average latency

    • Active instances

  3. Charts Section

    • Request volume over time

    • Response time percentiles

    • Error rate trend

    • Dependency health

  4. Detail Tables

    • Recent errors

    • Slowest operations

    • Top dependencies

Implementation:

1. Parameters:

2. Request Rate Tile:

3. Error Rate Tile:

4. Response Time Chart:

5. Top Errors Table:

6. Dependency Health:

Infrastructure Monitoring Dashboard

Here's my standard infrastructure dashboard:

Dashboard Components:

1. Server Health Overview Tile:

2. CPU Usage Heat Map:

3. Memory Pressure Table:

4. Disk Space Monitoring:

5. Network Traffic Chart:

Kubernetes Monitoring Dashboard

For AKS clusters, I use this dashboard structure:

Cluster Health Overview:

Container Resource Usage:

Error Log Analysis:

Alert Query Patterns

Queries designed for Azure Monitor alerts need to return a single value or time-series.

Pattern 1: Threshold Alert

Pattern 2: Anomaly Detection Alert

Pattern 3: Missing Data Alert

Dashboard Design Best Practices

From my experience, here's what makes dashboards effective:

1. Information Hierarchy

Top section (always visible):

  • Critical health indicators (tiles)

  • Overall system status

  • High-level KPIs

Middle section (primary focus):

  • Time-series charts showing trends

  • Key metrics over time

  • Comparison visualizations

Bottom section (details):

  • Detailed tables

  • Drill-down data

  • Advanced analytics

2. Color Coding Standards I Use

3. Query Performance

Keep dashboard responsive:

  • Use time filters on all queries

  • Limit result sets (take, top)

  • Cache expensive calculations with let

  • Use summarization instead of raw data

Example optimization:

4. Parameter Strategy

Essential parameters:

  • Time range (always include)

  • Resource filter (subscription, resource group, resource)

  • Environment (prod, dev, test)

Optional parameters:

  • Severity level

  • Status filter

  • Custom dimensions

5. Documentation Within Dashboards

Add markdown blocks to explain:

  • What each section shows

  • How to interpret visualizations

  • Links to runbooks for common issues

  • SLA targets and thresholds

Sharing and Collaboration

Workbook Templates

Save workbooks as templates for reuse:

  1. Gallery template - Public, for common patterns

  2. Custom template - Private, for team use

  3. ARM template - For deployment automation

Access Control

Control who can view and edit:

  • Reader access - View only

  • Contributor access - View and edit

  • Owner access - Full control

Version Control

Track changes:

  • Use meaningful version descriptions

  • Test changes in a copy first

  • Document breaking changes

Exporting and Integration

Export Options:

  1. Excel - For offline analysis

  2. Power BI - For advanced analytics

  3. ARM templates - For automation

  4. Workbook Gallery - For sharing

Integration with Azure Dashboards:

Pin workbook visualizations to Azure dashboards for executive views:

  • Navigate to visualization

  • Click "Pin to dashboard"

  • Select or create dashboard

Key Takeaways

  • Azure Workbooks transform queries into interactive dashboards

  • Use parameters to make dashboards flexible

  • Choose visualization types based on data characteristics

  • Follow information hierarchy: KPIs β†’ trends β†’ details

  • Standardize color coding for consistency

  • Optimize queries for dashboard performance

  • Document dashboard purpose and interpretation

  • Save as templates for reusability

In Part 6, we'll focus on KQL best practices and performance optimization techniques that ensure your queries run efficiently at scale.

Last updated