Before Lab 4.2 — Logs, Metrics, Traces, and Diagnostic Settings

Mitch Mommers06/06/2026About 4 min

Before Lab 4.2 — Logs, Metrics, Traces, and Diagnostic Settings

Before you can query data, you need to understand where data comes from and how it reaches Log Analytics.

Azure Monitor data model

Azure Monitor is the umbrella service that collects all telemetry. It has three main data types:

Data Type	Description	Example Sources
Logs	Structured text records with timestamps	Application logs, platform logs, security events
Metrics	Numerical values collected at regular intervals	CPU usage, request count, response time
Traces	Time-ordered records of events in a process	Request lifecycle, dependency calls, exceptions

These three types form the logs, metrics, traces triad that underpins all observability.

Logs

Logs are the most flexible data type. Each log entry is a row in a table with named columns:

Table: requests
Row: { TimeGenerated: 2024-01-15T10:30:00Z, Method: "GET", Url: "/api/health", Status: 200, DurationMs: 12 }

Log Analytics queries use KQL (Kusto Query Language) to filter, group, and aggregate log entries. Logs answer questions like:

"Which requests returned HTTP 500 in the last hour?"
"How many requests came from IP address X?"
"What is the average response time for the /api/data endpoint?"

Metrics

Metrics are single numerical values collected at regular intervals (usually every 1 minute):

Metric: Http5xxCount
Timestamp: 2024-01-15T10:30:00Z
Value: 3

Metrics are lightweight and ideal for dashboards and alerts. They answer questions like:

"Is the HTTP 5xx error rate above threshold?"
"What is the average CPU usage over the last 24 hours?"
"When did response time spike above 500ms?"

Traces

Traces are ordered records that show the sequence of events within a single request:

Trace: Request abc-123
  10:30:00.000 - HTTP request received (GET /api/data)
  10:30:00.005 - Authentication check passed
  10:30:00.010 - Database query started
  10:30:00.050 - Database query completed
  10:30:00.055 - Response sent (200 OK)

Traces answer questions like:

"What happened during request abc-123?"
"Which dependency call caused the timeout?"
"Where in the request lifecycle did the error occur?"

Diagnostic Settings: routing platform logs

Diagnostic Settings is the mechanism that routes platform logs from Azure resources to Log Analytics. Without diagnostic settings, platform logs are lost.

What each resource type provides

Resource	Log Category	What it captures	Security relevance
App Service	HTTP Logs	Every HTTP request (IP, path, status, user agent)	Detects scanning, brute force, suspicious paths
App Service	Console Logs	stdout/stderr output	Application errors, stack traces
App Service	App Logs	Structured application logs	Custom security events, audit trails
Key Vault	AuditEvents	Secret/key/certificate operations	Detects unauthorized access, enumeration
Storage	StorageRead/Write	Table/Blob/Queue operations	Detects data access patterns, exfiltration
Storage	Capacity	Storage utilization metrics	Detects unusual storage growth

Configuring diagnostic settings

Diagnostic settings can be configured in three ways:

Method	When to use	Example
Azure Portal	One-off configuration, exploration	Click "Diagnostic settings" on a resource
Terraform	Infrastructure as code, reproducible	`azurerm_monitor_diagnostic_setting` resource
Azure CLI	Scripting, automation	`az monitor diagnostic-settings create`

For Day 4, diagnostic settings are deployed automatically via Terraform in Lab 4.1. The dev.tfvars file sets enable_diagnostic_settings = true, which flips the count on diagnostic setting resources in main.tf. The daily ingestion cap is configured interactively in the Azure portal during this lab.

Note: Once diagnostic settings are enabled, Defender for Cloud will begin generating security recommendations based on your configuration — including whether monitoring is properly set up.

The data flow: from request to Log Analytics

Understanding the data flow helps you understand where to look when investigating:

Key observations

Two paths: A single request produces data through two separate paths — the OpenTelemetry-based SDK (application-level) and Diagnostic Settings (platform-level).
Different tables: SDK data goes to requests, traces, dependencies. Platform logs go to AzureDiagnostics with different categories (AppServiceHTTPLogs, AuditEvent, etc.) depending on the resource type. You need to query different tables for different data sources.
Different timing: The OpenTelemetry-based SDK streams telemetry near real-time (5-30 seconds). Diagnostic settings typically appear within 30-120 seconds after enabling them on a resource.
Different granularity: The SDK sees inside your code (custom log messages, dependency calls). Platform logs see the request at the HTTP level (IP address, user agent, response code).

Cost considerations

Log Analytics charges by data ingestion volume (PerGB2018 tier). Understanding data flow helps manage costs:

Factor	Impact	Mitigation
High traffic	More log entries = higher cost	Set a daily cap in the portal
Verbose logging	More data per request	Use structured logging, avoid large payloads
Diagnostic settings on all resources	More log categories = more data	Enable only what you need for the lab
Log retention	Data stored longer = higher cost	Use shorter retention for dev (30 days)

The daily cap

The daily cap prevents runaway costs by capping ingestion per day. You will configure this in the Azure portal during Lab 4.2.

Why a daily cap matters: When the cap is reached, new log entries are discarded. This is safe for labs because you generate enough traffic to query and investigate without exhausting the cap.

Critical: Always set a daily cap in shared or learning environments. A misconfigured app that logs heavily could generate hundreds of gigabytes per day, resulting in significant unexpected charges.

Lab 4.2 objectives

Lab 4.2 goals

Verify diagnostic settings deployed by Terraform are working correctly
Identify which log categories are enabled for each resource
Set the daily ingestion cap in the Azure portal
Query platform-level logs using KQL queries
Understand the difference between SDK and platform-level data

Key questions before starting

What is the difference between OpenTelemetry-based SDK data and Diagnostic Settings data?
Why does a single request appear in multiple tables in Log Analytics?
How does the daily cap protect against runaway costs?
If an attacker accesses your Key Vault, which data source will capture it — the SDK or diagnostic settings?

Lab File

Download Lab 4.2 — Diagnostic Settings PDF