Azure Monitor metrics and logs both describe what is happening in a system, but they are optimized for different questions. Metrics are numerical time-series values collected at intervals and designed for fast aggregation, dashboards and alerting. Logs are timestamped records that can contain much richer context and are designed for investigation, correlation and deep queries. Good observability uses both instead of trying to force every operational question into one data type.<\/p>\n
This distinction appears throughout Azure administration and architecture. It is relevant to AZ-104<\/a> because administrators configure monitoring and alerts, to AZ-305<\/a> because architects design operational visibility, and to security and data roles that use KQL to investigate events. It is also a core cloud-operations idea inside the wider cloud architecture certification landscape<\/a>.<\/p>\n Metrics are numeric measurements associated with time. Examples include CPU percentage, request rate, queue depth, disk operations, response latency or the count of failed operations. Azure Monitor stores platform metrics in a time-series system designed for efficient aggregation over time.<\/p>\n That makes metrics excellent for health signals. An alert can evaluate average CPU over several minutes or trigger when failed requests exceed a threshold. Dashboards can show a trend without scanning millions of individual event records.<\/p>\n Metrics are also compact compared with detailed logs. A single value per minute can describe a system state that would require many raw events to reconstruct. This makes them well suited to continuous monitoring where speed and cost matter.<\/p>\n The tradeoff is context. A metric can tell you that error rate increased, but it usually cannot tell you which user, request payload or dependency caused the failures. That is where logs become necessary.<\/p>\n Logs are event records. They can include timestamps, operation names, resource identifiers, status codes, user or identity information, diagnostic messages and many other fields. Azure Monitor logs are commonly stored in a Log Analytics workspace and queried with Kusto Query Language.<\/p>\n Because logs carry context, they are central to root-cause analysis. If a metric says latency doubled at 14:05, logs can help determine whether the cause was a specific endpoint, a backend dependency, a deployment, a throttling event or a security control.<\/p>\n Logs are also valuable when the question is not known in advance. Metrics normally have defined names and dimensions. Logs can be queried later in ways the team did not anticipate when the event occurred, provided the relevant fields were collected.<\/p>\n That flexibility comes with cost and volume. Detailed logs can grow rapidly, especially in high-traffic systems. Collection policy, retention and workspace design therefore become architecture decisions rather than an instruction to \u201clog everything forever.\u201d<\/p>\n A common monitoring mistake is building every alert from logs because KQL is flexible. If a native platform metric expresses the condition accurately, a metric alert is often faster and simpler. CPU saturation, request count and many resource health thresholds are natural metric signals.<\/p>\n Log alerts are stronger when the condition depends on event context or correlation. For example, a team may need to alert when a particular failure code appears for a sensitive operation, or when a pattern across several records indicates a problem that one numeric threshold cannot represent.<\/p>\n The decision should follow the signal. Use metrics for fast numerical health detection and logs for contextual conditions. Do not choose one technology because the team happens to know it better.<\/p>\n Azure metrics can include dimensions that let operators split a measurement by useful categories. A request metric may be separable by response code, region or another supported dimension. This gives a dashboard more context without requiring a log query for every view.<\/p>\n Dimensions should still be treated as bounded categories. Time-series systems are not designed for unbounded high-cardinality data such as unique request IDs on every measurement. When every event needs its own identity and fields, logs are usually the more natural home.<\/p>\n For architects, this is a schema-design problem. Decide which facts are stable operational measurements and which facts are investigative context. Observability becomes cheaper and clearer when that distinction is made deliberately.<\/p>\n Log Analytics workspaces store and query Azure Monitor logs. They can receive data from many Azure resources and agents, creating a shared investigation surface across applications, infrastructure and security controls.<\/p>\n Workspace design affects retention, access and cost. A single workspace can simplify correlation across systems, but some organizations need separation for data residency, ownership or security boundaries. Too many workspaces can make investigations fragmented. Too few can create broad access and billing complexity.<\/p>\nMetrics answer \u201chow much, how fast, how many?\u201d<\/h2>\n
Logs answer \u201cwhat exactly happened?\u201d<\/h2>\n
Alerts should start with the cheapest reliable signal<\/h2>\n
Dimensions make metrics more useful without turning them into logs<\/h2>\n
Log Analytics workspaces are the center of log investigation<\/h2>\n