Host Details

Host Dashboard - Details

The Host Dashboard - Details tab provides an in-depth view of a single host, displaying detailed configuration information, performance metrics, and capacity recommendations. Use this view when you need to investigate a specific host's setup, troubleshoot issues, or review detailed specifications and recommendations.

The Details screen is organized into three main sections: Health, Properties, and Instances. Each section contains cards with metrics and configuration details for the selected host.

Selecting a Host

The Details tab requires you to select exactly one host before displaying data. You have several options for host selection:

Using Filters:

1. Click the Filters button to open the filter panel
2. Navigate to the Host filter section
3. Select a single host from the available options
4. The Details tab will display data for your selected host

Using a View:
If you have a saved View that includes only one host, selecting that View will automatically display Details for that host. Views with multiple hosts require you to narrow your selection to view Details.

From the Overview Tab:
Click any host name in the Overview tab's Host List to add the host as a filter, then navigate to that host's Details view.

Filter Persistence:
Filters you apply persist as you navigate between the Overview and Details tabs, and other screens in WISdom. However, if multiple hosts have been selected, you'll need to narrow your selection to a single host when switching to Details. The filter will automatically prompt you to refine your selection if needed.

Date Selection

The Date Picker in the upper right corner allows you to select any date up to today. The data displayed will vary; some of it is annualized, some monthly, and some based on the selected date.

• Annualized data will be labeled and display data based on up to a year from the current date (or the collection start date)
• Monthly data will be the previous 30 days from today's date
• Configuration data will display based on the last collection date selected in the Date Picker

Health Section

The Health section provides critical information about the host's operational status, alert activity, and performance metrics.

Availability

Displays the host's current Tier of Service classification and availability percentage for the selected time period.

Metrics Shown:

• Tier of Service - The host's assigned tier (e.g., Tier 1, Non-Production)
• Availability - Percentage of time the host was online and responsive during the measurement period

How Availability is Calculated:
WISdom availability is determined by the WMI and the performance metric collection connections that occur every minute. These connection requests determine whether the host is:

• Online and reachable on the network
• Running and responsive to new connections
• Able to return expected query results

Both offline status (host unreachable) and unresponsive status (host reachable but not responding correctly) are factored into the availability calculation. The percentage reflects uptime during the measurement window.

What Good Availability Looks Like:

• Tier 1 Production Hosts: Typically target 99.9% or higher availability
• Non-Production Hosts: May have lower availability targets depending on business requirements

Low availability warrants investigation - common causes include:

• Planned or unplanned reboots
• Network connectivity issues
• Connection Pool exhaustion
• Resource exhaustion (CPU, memory, disk)
• Hardware or virtualization platform problems

Alert Status

Shows the total number of alerts that occurred in the past 30 days, broken down by current status and priority level.

Alert Status Categories:

• Open - Currently active alerts requiring attention
• Closed - Alerts that have been resolved or acknowledged

Priority Levels:

• P0 (Priority 0) - Critical alerts requiring immediate action
• P1 (Priority 1) - High priority alerts requiring prompt attention
• P2 (Priority 2) - Medium priority alerts for planned resolution

What This Tells You:
The alert status summary helps you understand:

• Whether the host has ongoing issues (high open alert count)
• Alert frequency over the past month (total alerts)
• Severity distribution of problems affecting the host

A high number of open alerts, particularly P0 or P1, indicates the host needs immediate attention. Frequent alerts (many total alerts even if closed) may suggest underlying stability or configuration issues worth investigating.

For detailed information about configuring and managing alerts, see the Alerts section in the Monitoring Modules documentation.

Capacity Planning

Provides specific resource sizing recommendations for the selected host based on 30 days of actual performance data.

Resources Evaluated:

• Compute - CPU core recommendations
• Drive Space - Storage capacity recommendations by drive
• Memory - RAM allocation recommendations

Recommendation Format:
Each row shows:

• Resource Type - What resource is being evaluated (Compute, Drive Space, Memory)
• Recommendation - Specific guidance on sizing changes

Understanding Recommendations:

Compute (CPU):

• Negative values (e.g., "-13 Cores") suggest the host has more CPU than needed based on actual usage
• Positive values suggest adding CPU capacity
• "Right Sized" indicates current allocation matches demand

Drive Space:

• Negative values (e.g., "-10,801 GB") indicate you can reclaim unused storage
• Positive values suggest adding storage capacity
• Specific drive letters may be shown when recommendations apply to particular drives

Memory:

• "Right Sized" indicates current memory allocation is appropriate
• Specific GB recommendations indicate suggested memory changes

Why This Matters:
Acting on capacity recommendations helps you:

• Reduce costs by right-sizing over-provisioned resources (especially important for per-core licensing)
• Prevent performance issues by addressing under-provisioned resources before they cause problems
• Optimize resource allocation across your environment based on actual demand

💡 Deep Dive (500 Level):
WISdom's capacity recommendations use statistical analysis of performance metrics over the 30-day window. For CPU, the engine examines processor queue length, CPU utilization patterns, and SQL Server scheduler waits to determine if cores are underutilized or saturated. Memory recommendations evaluate buffer pool pressure, page life expectancy, memory grant wait times, and memory-related wait statistics. Storage recommendations analyze free space trends, growth rates, and alert history to predict when drives will reach capacity. The algorithm includes safety margins to avoid recommending changes that could cause intermittent performance degradation during peak periods. For virtual environments, recommendations consider hypervisor overhead and the cost of adding resources versus the risk of resource contention.

Storage Performance

Displays disk performance measured by storage latency for each drive and mount point on the selected host.

Latency Ranges:

• Optimal (<=5ms) - Excellent disk performance suitable for all SQL Server workloads
• Healthy (5ms to 15ms) - Acceptable performance for most workloads
• Suboptimal (>15ms) - May impact query performance; warrants investigation

How to Use:

• The color-coded horizontal bar chart shows latency distribution across the host's drives
• The Drives column shows how many drives fall into each latency range
• Click any row to see a detailed pop-up listing:
  • Host name
  • Specific drive letters or mount points
  • Disk latency in milliseconds for each drive

Why Storage Performance Matters:
SQL Server is I/O intensive. When the database engine needs to read or write data, it must wait for disk operations to complete. High disk latency directly translates to:

• Slower query execution times
• Longer transaction durations
• Reduced throughput for data-intensive operations
• Poor user experience

Interpreting Results:

• All drives Optimal - Storage is performing well; no action needed
• Mixed latency ranges - Investigate specific drives showing suboptimal performance
• Consistently Suboptimal - Likely indicates storage system limitations requiring infrastructure changes

Common Causes of High Latency:

• Overloaded storage controllers or disk arrays
• Insufficient IOPS capacity for the workload
• Network issues in SAN or cloud storage environments
• Other VMs competing for shared storage resources
• Undersized storage tier for the workload requirements

For information about configuring alerts based on storage performance thresholds, see the Alerts documentation.

💡 Deep Dive (500 Level):
Storage latency is measured from the moment SQL Server issues an I/O request to when that request completes. WISdom measures both read and write latency separately but reports them together for simplicity. The 15ms threshold is based on Microsoft's best practice recommendations - sustained latency above this level typically indicates a storage bottleneck. However, acceptable latency varies by workload type: OLTP systems with frequent small transactions are more sensitive to latency than data warehouse workloads with sequential large reads. When diagnosing latency issues, correlate with SQL Server wait statistics (PAGEIOLATCH_*, WRITELOG, IO_COMPLETION waits) to confirm storage is the bottleneck rather than other factors. In virtualized or cloud environments, latency can vary based on storage tiers, snapshot operations, backups running on shared infrastructure, or "noisy neighbor" effects.

Storage Capacity

Shows free space availability for each drive and mount point on the selected host.

Free Space Ranges:

• 0-5% - Critical; immediate action required to avoid out-of-space conditions
• 5-10% - Warning; plan capacity expansion soon
• 10+% - Healthy free space levels

How to Use:

• The color-coded horizontal bar chart shows the distribution of drives across free space ranges
• The Drives column shows how many drives fall into each range
• Click any row to see a detailed pop-up listing:
  • Host name
  • Drive letter or mount point
  • Total size in GB
  • Free space in GB

Why This Matters:
Running out of disk space can cause:

• Transaction log full errors, blocking all write operations
• Tempdb expansion failures, causing query failures
• Database auto-growth operations to fail
• Backup failures
• SQL Server service crashes in extreme cases

Best Practices:

• Monitor drives below 10% free - These should be on your capacity expansion plan
• Immediately address drives below 5% free - These are at risk of running out of space
• Set alerts for free space thresholds to get advance warning before problems occur
• Review growth trends - Even if space looks adequate today, rapid growth may require attention

Properties Section

The Properties section displays detailed configuration information about the selected host, including hardware specifications, network settings, and monitoring configuration.

Build Details

Shows the hardware and resource configuration of the selected host.

Specifications Displayed:

• Memory - Total RAM installed on the host (in GB)
• Logical Processors - Number of logical CPU cores available to the operating system
• NUMA Nodes - Number of Non-Uniform Memory Access nodes (typically matches physical CPU sockets)
• NICs - Number of Network Interface Cards installed and configured

Understanding the Metrics:

Memory:
Total physical RAM installed on the host. For virtual machines, this is the memory allocated to the VM by the hypervisor.

Logical Processors:
Includes physical cores and hyper-threading/SMT cores. For example, a server with 2 physical CPUs, each with 14 cores and hyper-threading enabled, would show 56 logical processors (2 × 14 × 2).

NUMA Nodes:
Modern servers organize memory and CPUs into NUMA nodes to optimize memory access performance. The NUMA node count typically equals the number of physical CPU sockets. SQL Server's NUMA-aware architecture performs best when properly aligned with hardware NUMA topology.

NICs:
Multiple network interfaces may be used for network redundancy, traffic separation (e.g., dedicated backup network), or load balancing.

💡 Deep Dive (500 Level):
Understanding the relationship between logical processors and NUMA nodes is critical for SQL Server performance tuning. SQL Server creates one scheduler per logical processor, and these schedulers are NUMA-aware. For optimal performance, SQL Server should use local memory within the same NUMA node as the scheduler whenever possible - remote NUMA node memory access incurs significant latency penalties. On servers with multiple NUMA nodes, poorly configured SQL Server instances may experience performance degradation due to remote memory access patterns. Use WISdom's Database Dashboard to monitor wait statistics related to memory allocation (SOS_SCHEDULER_YIELD, CXPACKET) which can indicate NUMA-related contention. For VMs, verify that virtual NUMA topology (vNUMA) is properly exposed to the guest OS - misconfigured vNUMA can severely impact performance on systems with 8+ vCPUs.

Model & Processor

Displays information about the host hardware model and CPU specifications.

Information Shown:

• Model - The physical server model number (for physical servers) or virtual machine type (for VMs)
• Processor Type - Detailed CPU specifications including:
  • Processor brand and model (e.g., Intel(R) Xeon(R) Gold)
  • Clock speed (e.g., 3.00GHz)
  • Number of physical sockets
  • Number of physical cores per socket
  • Total logical cores (includes hyper-threading)

Example Processor Description:
"Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz 2 Socket(s), 28 Core(s), 28 Logical Core(s)"

This tells you:

• CPU model: Intel Xeon Gold 6248R
• Base clock speed: 3.00GHz
• Physical CPUs: 2 sockets
• Cores per socket: 14 (28 cores ÷ 2 sockets)
• Logical cores: 28 (indicating hyper-threading is disabled in this example)

Why This Matters:

• Performance capacity - Processor speed and core count determine computational capacity
• Licensing implications - SQL Server licensing is per-core, so understanding your exact core count is critical for license compliance and cost planning
• Virtualization vs. physical - Virtual machines may have different performance characteristics than physical servers

Network

Displays network-related configuration for the selected host.

Configuration Details:

• Domain Name - The Active Directory domain or workgroup the host belongs to
• Page File Location - File path where Windows page file is stored
• IP Addresses - All configured IP addresses for the host

Why This Information is Important:

Domain Name:
Identifies the security domain and helps you understand authentication context, domain policies, and administrative boundaries.

Page File Location:
Windows uses the page file (virtual memory) when physical RAM is exhausted. The page file location tells you which drive handles paging operations. Best practices suggest:

• Page file should be on a fast, dedicated drive
• Page file should NOT be on the same drive as SQL Server data or log files
• Excessive page file usage (paging activity) indicates memory pressure

IP Addresses:
Lists all network interfaces and their assigned IPs. Multiple IPs may indicate:

• Network redundancy configuration
• Separate networks for different traffic types (client, backup, cluster heartbeat)
• Multi-homing for different subnets

Properties

Displays WISdom-specific configuration and monitoring settings for the selected host.

Configuration Displayed:

• Monitoring - The monitoring level configured (e.g., "Mission Critical - Tier 1")
• RTO (min.) - Not configurable in WISdom
• RPO (min.) - Not configurable in WISdom
• Data Collector - Name of the collector monitoring this host

Understanding RTO and RPO:

RTO (Recovery Time Objective):
Maximum acceptable time to restore service after a disruption. For example, RTO of 60 minutes means the business requires this host to be back online within 1 hour of an outage.

RPO (Recovery Point Objective):
Maximum acceptable amount of data loss measured in time. For example, RPO of 15 minutes means the business can tolerate losing up to 15 minutes of data in a disaster scenario.

RTO and RPO values drive backup frequency, disaster recovery solutions, and high availability configurations. Mission-critical hosts typically have low RTO/RPO values, while development systems may have higher tolerances.

Data Collector:
Identifies which collector is monitoring this host. If experiencing data collection issues, knowing the collector helps you troubleshoot connectivity or agent problems. See Collector Health for monitoring collector status.

Operating System

Displays the Operating System installed on the selected host.

Information Shown:

• Operating System - OS name and edition (e.g., "Microsoft Windows Server 2019 Standard")
• OS Build Number - Specific OS version build identifier (e.g., "10.0.17763")

Why This Matters:

• Support lifecycle - Microsoft's support policies vary by OS version and build
• Feature availability - Newer OS versions support additional SQL Server features and performance improvements
• Security updates - Older OS versions may not receive security patches, creating compliance risks
• Compatibility - SQL Server versions have OS requirements; some SQL Server versions cannot install on older OS versions

The OS Build Number provides granular version information. You can look up the build number to determine:

• Which cumulative update or service pack is installed
• Whether the OS has the latest security patches
• Compatibility with specific SQL Server versions and features

Uptime

Displays information about how long the host has been running since its last restart.

Metrics Shown:

• Uptime - Number of days since the last system restart
• Last System Restart - Date and time of the most recent restart
• Time Zone - The host's configured time zone

What Uptime Tells You:

Long Uptime (60+ days):

• Host has been stable with no required restarts
• May indicate pending Windows updates that require reboot haven't been applied
• Could mean planned maintenance windows aren't being utilized for patching

Short Uptime (< 7 days):

• Recent restart occurred - may indicate:
  • Planned maintenance (expected)
  • Patch installation requiring reboot (normal)
  • Unexpected crash or forced reboot (investigate if unplanned)
  • Power outage or hardware issue

Uptime Best Practices:

• Balance stability with patching - While high uptime indicates stability, it may also mean the host isn't being patched regularly
• Coordinate restarts - Plan system restarts during maintenance windows to minimize user impact
• Investigate unexpected restarts - Short uptime without corresponding maintenance records warrants investigation

Time Zone:
Important for interpreting log timestamps, scheduled jobs, and backup timing. Ensures you're correlating events correctly when troubleshooting issues across multiple servers in different time zones.

Instances Section

The Instances section provides summary information about SQL Server instances running on the selected host.

Metrics Displayed:

• Instances - Total count of SQL Server instances installed on the host
• Databases - Total count of databases across all instances on the host
• Space Used - Total database storage consumed across all instances (in TB)
• Memory In Use - Total memory currently allocated to SQL Server instances (in TB)

What This Tells You:
The Instances section gives you a quick overview of the SQL Server footprint on the host without having to navigate to instance-level views. This information helps you:

• Understand SQL Server density (how many instances and databases per host)
• Assess storage consumption at the host level
• Evaluate memory allocation patterns
• Identify hosts that may be candidates for consolidation or separation

Single Instance vs. Multiple Instances:

• Single instance - Most common configuration; simpler to manage and troubleshoot
• Multiple instances - Sometimes used to isolate workloads, separate applications, or support different SQL Server versions on one host

When to Investigate Further:

• High database count - May indicate consolidation opportunities or complexity management needs
• High space utilization - Compare against available storage to identify capacity planning needs
• High memory utilization - Verify SQL Server max memory settings aren't causing host-level memory pressure

For detailed instance and database information, navigate to:

• Instance Dashboard - Detailed instance-level metrics
• Database Dashboard - Individual database analysis

Related Documentation

• Host Dashboard - Overview - Multi-host aggregated view
• Instance Dashboard - Instance-level details
• Database Dashboard - Database-level analysis
• Collector Health - Data collector monitoring
• Alerts - Alert configuration and management
• Tools - Views, Tags, and Filters documentation