Azure Monitor and Log Analytics for Small Businesses in Berlin

ByAnthony Stewart

Running workloads in Azure without a monitoring strategy is operationally blind flying. You do not know when a virtual machine’s disk is filling up until an application fails. You do not know that a database has been hammering CPU at 95% for the past two hours until a user calls to say the application is slow. You do not know that a failed Function App trigger has been silently dropping messages for three days until reconciliation reveals the data gap. Azure Monitor and its integrated Log Analytics workspace solve this: a unified platform for metrics, logs, alerts, and dashboards that covers every Azure resource, on-premises servers, and Microsoft 365 signals in a single pane of glass.

This guide explains how Azure Monitor and Log Analytics work, how to write useful KQL queries, how to configure actionable alerts, and how Berlin businesses can build a monitoring baseline without a dedicated DevOps team.

Architecture: Two Data Channels

Azure Monitor collects two categories of data:

  • Metrics: numeric time-series data emitted at regular intervals by Azure resources. CPU percentage, disk read/write IOPS, network bytes in/out, SQL DTU consumption, App Service response time. Metrics are stored natively in Azure Monitor Metrics and retained for 93 days. They are visualised in the Azure portal resource overview and are the primary source for threshold-based operational alerts
  • Logs: structured or semi-structured event records. Resource diagnostic logs (Key Vault access events, NSG flow logs, storage account audit events), application logs from Application Insights, Windows Event logs from VMs, Azure Activity log (who did what to which resource and when). Logs are sent to a Log Analytics workspace — a centralised log store with a SQL-like query engine (KQL) that allows joining, filtering, aggregating, and searching across all ingested data

The Log Analytics Workspace

The Log Analytics workspace is the hub of your Azure observability infrastructure. Every diagnostic log source, every VM agent, every connected service writes to a workspace. Key characteristics:

  • Schema: each log source writes to a named table. AzureActivity (Azure control plane events), SigninLogs (Entra ID sign-ins), KeyVaultLogs (vault access events), AzureDiagnostics (multi-resource diagnostic logs), SecurityEvent (Windows Security event log), Heartbeat (VM agent liveness)
  • Retention: configurable from 30 days to 730 days. Interactive retention (fully queryable) defaults to 30 days; archival retention (lower cost, queryable but not in real-time dashboards) extends to 7 years for compliance purposes
  • Cost: ingestion is charged per GB. The Azure Monitor free tier includes 5 GB/month; beyond that the pay-as-you-go rate is approximately €2.30/GB. Commitment tiers (100 GB/day, 200 GB/day, etc.) reduce per-GB cost by 15–33%. For most small businesses, monitoring costs are €5–20/month
  • Microsoft Sentinel integration: Sentinel runs on top of a Log Analytics workspace, extending it with SIEM detection rules, incident management, and SOAR playbooks. The workspace is shared, so data ingested for Sentinel is also queryable as raw logs in Log Analytics

KQL Basics

Kusto Query Language (KQL) is the query engine for Log Analytics. It reads left-to-right with pipe operators, making queries readable even without SQL experience. Useful queries for Berlin small businesses:

Find all failed sign-in attempts from outside Germany in the last 24 hours:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| where Location !startswith "DE"
| summarize FailedAttempts = count() by UserPrincipalName, Location, IPAddress
| order by FailedAttempts desc

Show Key Vault secret access events for the last 7 days:

KeyVaultLogs
| where TimeGenerated > ago(7d)
| where OperationName == "SecretGet"
| project TimeGenerated, CallerIPAddress, identity_claim_upn_s, ResultSignature
| order by TimeGenerated desc

Azure Activity log — who deleted or modified resources today:

AzureActivity
| where TimeGenerated > ago(24h)
| where ActivityStatus == "Success"
| where OperationNameValue contains "delete" or OperationNameValue contains "write"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Resource
| order by TimeGenerated desc

Alert Rules

Azure Monitor alert rules trigger when a metric threshold is breached or when a log query returns results. Alert rule components:

  • Scope: the resource or workspace being monitored
  • Condition: the metric threshold (CPU > 90% for 5 minutes) or KQL query (any result for “failed auth from outside Germany”)
  • Action group: what happens when the alert fires — email, SMS, Teams webhook, Azure Function, Logic App. Action groups are reusable across multiple alert rules
  • Severity: 0 (critical) to 4 (informational) — used for alert prioritisation in dashboards

Essential alert rules for every Azure environment:

Alert Condition Severity
VM CPU critical CPU percentage > 95% for 10 minutes 1
VM disk space low Available disk space < 10% 1
SQL DTU cap approaching DTU consumption > 85% for 15 minutes 2
App Service 5xx errors Http5xx > 10 in 5 minutes 1
Key Vault throttling ServiceApiThrottled > 0 2
Azure Activity: resource deletion Log query: AzureActivity with delete + Success 2
VM agent heartbeat lost Heartbeat absence for 5 minutes 1

Workbooks: Operational Dashboards

Azure Monitor Workbooks are parameterised dashboards built from KQL queries and metric charts. Microsoft provides built-in workbooks for common scenarios: VM performance, Azure AD sign-in analysis, storage account overview, SQL performance. Custom workbooks can combine multiple data sources — metrics from a VM, logs from an application, Entra sign-in data — into a single operational view that refreshes automatically.

For a small business running a web application on Azure, a useful custom workbook combines: App Service response time and error rate (metrics), application exceptions from Application Insights (logs), Entra sign-in events for the application (SigninLogs), and Key Vault access events for the application’s secrets (KeyVaultLogs) — giving the on-call person a single URL to open when something goes wrong.

Diagnostic Settings: Enabling Log Collection

Azure resources do not send logs to a workspace by default — each resource requires a Diagnostic Setting that specifies which log categories to send and where. For small businesses, the most important resources to configure diagnostic settings for:

  • Azure Key Vault: enable AuditEvent logs (all secret/key/certificate access events)
  • Azure SQL: enable SQLSecurityAuditEvents and SQLInsights
  • Azure App Service: enable AppServiceHTTPLogs and AppServiceConsoleLogs
  • Network Security Groups: enable NetworkSecurityGroupEvent (NSG rule hits)
  • Entra ID: configure SigninLogs and AuditLogs via the Diagnostic settings blade in the Entra admin centre

Cost Management

Log ingestion costs can grow uncontrolled if all diagnostic log categories are enabled for all resources. Cost optimisation strategies: enable only security-relevant log categories (AuditEvent, not all diagnostic categories), set a daily data cap on the workspace to prevent runaway ingestion from a misconfigured resource, use archive tier for logs older than 30 days but within the retention requirement, and exclude noisy low-value tables (like verbose Application Insights dependency tracking) from ingestion.

Deployment Steps for Berlin Small Businesses

  1. Azure portal → Log Analytics workspaces → Create → select Germany West Central for data residency → choose the same resource group as your primary workload
  2. Set workspace retention: workspace → Usage and estimated costs → Data Retention → set to 90 days (balances compliance and cost)
  3. Configure diagnostic settings on Key Vault, SQL, App Service, and NSGs: each resource → Diagnostic settings → Add → send to the workspace
  4. Connect VMs: Azure Monitor → Virtual machines → enable the Azure Monitor Agent and configure the Data Collection Rule to send Windows Security events and performance counters to the workspace
  5. Configure Entra ID log export: Entra admin centre → Monitoring → Diagnostic settings → add setting → send SigninLogs and AuditLogs to the workspace
  6. Create the first alert rule: workspace → Alerts → Create → log search alert → KQL query for failed authentications → action group sending email to the security lead
  7. Review and deploy relevant built-in workbooks: Azure Monitor → Workbooks → Public Templates → deploy VM performance and Azure AD workbooks

The Log Analytics workspace created for Azure Monitor is the same workspace used by Microsoft Sentinel — enabling Sentinel on the workspace extends it with SIEM detection rules and incident management at no additional data cost, since logs already ingested for operational monitoring are reused for security detection.

Similar Posts