System Identity Metrics Explained

What Are System Identity Metrics?

System identity metrics provide essential information about each server's fundamental characteristics — its operating system, hardware architecture, virtualisation environment, and monitoring agent status. These metrics form the foundation for fleet management, security compliance, and infrastructure inventory tracking.

Unlike performance metrics that change constantly, identity metrics remain relatively stable over time. A server's OS version might change monthly during updates, its kernel version weekly during maintenance windows, but its architecture and virtualisation type typically remain constant throughout the server's lifecycle.

Server Scout collects seven key identity metrics daily, providing administrators with a comprehensive view of their infrastructure landscape without the overhead of constant polling.

The Seven System Identity Metrics

Operating System (os)

The os metric captures the complete operating system name and version, such as "AlmaLinux 10.1", "Ubuntu 24.04 LTS", or "Debian 12 (bookworm)". This information comes from parsing /etc/os-release, the standardised file that Linux distributions use to identify themselves.

This metric proves invaluable for:

• Security compliance: Quickly identify servers running end-of-life distributions
• Update planning: Group servers by OS version to coordinate maintenance windows
• Licence management: Track commercial distributions like RHEL across your fleet
• Application compatibility: Ensure applications are deployed on supported OS versions

The dashboard's filtering capabilities allow you to instantly answer questions like "How many Ubuntu servers do we have?" or "Which servers are still running CentOS 7?"

Kernel Version (kernel)

The kernel metric records the complete kernel version string, such as "6.12.0-124.35.1.el10_1.x86_64" or "6.8.0-45-generic". This comes from the uname -r command, which reports the currently running kernel.

Kernel tracking serves several critical purposes:

• Security patching: Identify servers that haven't received recent kernel updates
• Reboot detection: Servers showing old kernel versions likely need rebooting after updates
• Performance troubleshooting: Certain kernel versions may have known performance issues
• Hardware compatibility: Newer kernels often include updated drivers for recent hardware

A common scenario involves package managers installing new kernels without automatically rebooting. The kernel metric helps identify servers where reboot_required might be true, indicating the need for maintenance scheduling.

Architecture (arch)

The arch metric identifies the CPU architecture, typically "x86_64" for modern Intel/AMD servers, "aarch64" for ARM64 systems, or occasionally "i386" for legacy 32-bit systems. This comes from uname -m.

Architecture information becomes crucial in:

• Container deployments: Ensuring Docker images match the underlying architecture
• Binary distribution: Deploying the correct executable versions across mixed fleets
• Performance analysis: ARM and x86 processors have different performance characteristics
• Cost optimisation: ARM-based cloud instances often offer better price/performance ratios

As ARM-based servers become more common in cloud and edge deployments, tracking architecture helps prevent deployment mistakes and optimises infrastructure costs.

Virtualisation Technology (virtualization)

The virtualization metric identifies the underlying virtualisation platform or reports "none" for physical hardware. Common values include "kvm", "vmware", "xen", "lxc", "docker", or "none". This information comes from systemd-detect-virt, which examines various system indicators to determine the virtualisation environment.

Understanding virtualisation context helps interpret other metrics:

• CPU steal time: cpu_steal is only relevant in virtualised environments
• Hardware metrics: cpu_temp is typically unavailable in virtual machines
• Performance expectations: Physical servers generally offer more consistent performance
• Licensing: Some software licenses have different terms for physical vs virtual deployments

This metric also aids in:

• Migration planning: Identify physical servers that could be virtualised
• Performance troubleshooting: Virtual machines may experience noisy neighbour effects
• Resource allocation: Containers and VMs have different resource management approaches

Hostname (hostname)

The hostname metric records the server's configured hostname, which should match DNS records and system configuration. This provides a human-readable identifier for each monitored server.

Hostname tracking helps with:

• Configuration verification: Ensuring hostnames match naming conventions
• DNS consistency: Identifying servers with mismatched hostnames and DNS entries
• Troubleshooting: Correlating Server Scout data with logs and other monitoring tools
• Fleet organisation: Grouping servers by hostname patterns (e.g., web-01, web-02)

Device Type (device_type)

The device_type metric typically shows "server" for standard Linux servers monitored by the Server Scout agent. This field allows the platform to distinguish between agent-monitored servers and other devices that might be monitored via SNMP or IPMI polling.

While most users will see "server" consistently, this metric enables:

• Mixed infrastructure monitoring: Differentiating servers from network equipment or storage arrays
• Reporting accuracy: Ensuring dashboards display appropriate metrics for each device type
• Feature availability: Some monitoring features only apply to specific device types

Agent Version (agent_version)

The agent_version metric tracks the installed Server Scout agent script version, such as "2.1.4" or "2.2.0-beta". This enables the platform to manage agent updates and ensure compatibility.

Agent version tracking facilitates:

• Update management: The dashboard can trigger automatic updates for outdated agents
• Feature compatibility: New dashboard features may require minimum agent versions
• Troubleshooting: Version information helps diagnose agent-related issues
• Fleet maintenance: Identify servers that missed automatic updates

Collection Methodology and Timing

All system identity metrics belong to the Daily tier, collected once every 24 hours. This frequency balances data freshness with system efficiency, as these values change infrequently compared to performance metrics.

The daily collection schedule makes sense because:

• Minimal change frequency: OS versions and architectures rarely change
• Command overhead: Tools like systemd-detect-virt require process forking, which is acceptable daily but wasteful at 5-second intervals
• Network efficiency: Reducing data transmission for static information
• Resource conservation: The agent maintains its sub-100ms CPU usage per cycle by avoiding unnecessary work

The agent collects this information using standard system commands and files:

Fleet Inventory and Management Uses

System identity metrics transform Server Scout into a comprehensive fleet inventory system. Rather than maintaining separate spreadsheets or CMDBs, administrators can answer infrastructure questions directly from the monitoring dashboard.

Common Fleet Questions

Operating System Distribution

• "How many Ubuntu vs CentOS servers do we have?"
• "Which servers are running end-of-life OS versions?"
• "Are all production servers on supported distributions?"

Update Status Tracking

• "Which servers haven't received recent kernel updates?"
• "How many servers are running kernels older than 6 months?"
• "Do any servers need rebooting after kernel updates?"

Architecture Overview

• "What's our x86 vs ARM distribution?"
• "Which applications are running on ARM servers?"
• "Are we ready for ARM-based deployments?"

Virtualisation Analysis

• "How many physical vs virtual servers do we manage?"
• "Which hypervisors are in use across our infrastructure?"
• "Are any legacy physical servers candidates for virtualisation?"

Dashboard Filtering and Reporting

The Server Scout dashboard allows filtering by any identity metric, enabling focused views of infrastructure subsets. For example:

• Filter by os containing "Ubuntu" to see only Ubuntu servers
• Filter by virtualization equals "none" to view physical servers
• Filter by arch equals "aarch64" to examine ARM-based systems
• Filter by kernel matching older patterns to identify update candidates

These filters work alongside performance metrics, so you can ask questions like "Show me CPU usage for all physical servers" or "Display memory utilisation for Ubuntu 22.04 systems only."

Integration with Performance Monitoring

System identity metrics provide crucial context for interpreting performance data. Understanding a server's virtualisation environment, architecture, and OS version helps explain performance patterns and guide troubleshooting efforts.

Virtualisation Context

The virtualization metric directly impacts how you interpret CPU metrics:

• Physical servers (virtualization: none) should show cpu_steal near zero
• Virtual machines may experience cpu_steal during host contention
• Containers (virtualization: docker, lxc) share kernel resources differently than VMs

Temperature monitoring behaves differently based on virtualisation:

• Physical servers typically report cpu_temp from hardware sensors
• Virtual machines rarely have access to temperature data
• Container hosts may show host hardware temperatures

Architecture Considerations

The arch metric influences performance expectations:

• ARM servers (arch: aarch64) may show different performance characteristics than x86
• Memory usage patterns can vary between architectures
• Network performance may differ based on processor architecture

Operating System Impact

Different operating systems handle resource management uniquely:

• Memory allocation strategies vary between distributions
• Process scheduling differs between kernel versions
• Network stack optimisations change between OS releases

Practical Administrative Workflows

System identity metrics enable several practical administrative workflows that improve fleet management efficiency.

Security Update Management

1. Vulnerability Assessment: Filter by os and kernel to identify systems running vulnerable versions
2. Update Prioritisation: Group servers by OS version to plan sequential updates
3. Reboot Scheduling: Cross-reference kernel versions with reboot_required flags

Migration Planning

1. Physical-to-Virtual: Use virtualization: none to identify P2V candidates
2. Architecture Migration: Track ARM deployment progress with arch filters
3. OS Standardisation: Plan migrations by identifying OS diversity with os grouping

Agent Maintenance

1. Update Monitoring: Filter by agent_version to identify outdated installations
2. Feature Rollout: Ensure minimum agent versions before enabling new dashboard features
3. Troubleshooting: Correlate issues with specific agent versions

Best Practices for Identity Metric Management

Naming Conventions

Consistent hostname patterns make fleet management easier:

• Use descriptive prefixes: web-01, db-primary, cache-eu-west
• Include environment indicators: prod-web-01, staging-app-02
• Consider geographic markers: us-east-web-01, eu-west-db-01

Update Strategies

Plan OS and kernel updates systematically:

• Group servers by os version for coordinated updates
• Monitor kernel versions to identify servers needing reboots
• Use virtualization context to plan maintenance windows appropriately

Documentation Integration

System identity metrics can supplement configuration management:

• Export fleet inventory data for auditing purposes
• Cross-reference with asset management systems
• Maintain deployment documentation based on actual infrastructure state

System identity metrics provide the foundation for effective infrastructure management. By collecting this information daily, Server Scout enables administrators to maintain accurate fleet inventories, plan updates systematically, and understand the context behind performance metrics. These seven simple metrics transform raw monitoring data into actionable infrastructure intelligence.