Host and process metrics including CPU, memory, disk, network, containers, and process-level telemetry. Use when analyzing infrastructure health, resource utilization, process consumption, or host discovery. Also use when building timeseries queries for host metrics that feed into analytical workflo

Infrastructure Hosts Skill Monitor and manage host and process infrastructure including CPU, memory, disk, network, and technology inventory. When to Use This Skill Use this skill when the user needs to: Inventory: "Show me all Linux hosts in AWS us east 1" Agent Inventory: "Which hosts run FULL STACK, INFRASTRUCTURE, or DISCOVERY mode?" / "Show OneAgent version distribution" Monitor: "What hosts have high CPU usage?" Troubleshoot: "Which processes are consuming the most memory?" Discover: "What databases are running in production?" Plan: "Track Kubernetes version distribution for upgrade planning" Cost: "Calculate infrastructure costs by cost center" Security: "Find all processes listening on port 22" Compliance: "Identify hosts running EOL Java versions" Quality: "Check data completeness for AWS hosts" Optimize: "Find rightsizing candidates based on utilization" Cross source join required: If the query must combine host data with logs or other telemetry sources (e.g. "show logs from Linux hosts with their IP addresses") → also read dt dql essentials/references/smartscape topology navigation.md before writing the query. Core Concepts Entities HOST Physical or virtual machines (cloud or on premise) PROCESS Running processes and process groups CONTAINER Kubernetes containers NETWORK INTERFACE Host network interfaces DISK Host disk volumes Metrics Categories 1. Host Metrics dt.host.cpu. , dt.host.memory. , dt.host.disk. , dt.host.net. 2. Process Metrics dt.process.cpu. , dt.process.memory. , dt.process.io. , dt.process.network. 3. Inventory OS type, cloud provider, technology stack, versions 4. Cost dt.cost.costcenter , dt.cost.product 5. Quality Metadata completeness, version compliance Alert Thresholds CPU/Memory/Disk: 80% warning, 90% critical Network: 70% high, 85% saturated Disk Latency: 20ms bottleneck Network Errors: Drop rate 1%, error rate 0.1% Swap: 30% warning, 50% critical Key Workflows 1. Host Discovery and Classification Discover hosts, classify by OS/cloud, inventory resources. OS Types: LINUX , WINDOWS , AIX , SOLARIS , ZOS → For cloud specific attributes, see [references/inventory discovery.md](references/inventory discovery.md cloud attribute reference) 2. Resource Utilization Monitoring Monitor CPU, memory, disk, network across hosts. High utilization threshold: 80% warning, 90% critical Key CPU Metrics: dt.host.cpu.usage — Total CPU utilization (0 100%) dt.host.cpu.idle — CPU idle time (inverse of usage; useful for anomaly detection) dt.host.cpu.user — CPU time in user mode dt.host.cpu.system — CPU time in kernel mode dt.host.cpu.iowait — CPU waiting for I/O (Linux only) → For detailed CPU analysis, see [references/host metrics.md](references/host metrics.md cpu monitoring) → For memory breakdown, see [references/host metrics.md](references/host metrics.md memory monitoring) Disk Free Space — Find Hosts with Most/Least Free Disk 3. Process Resource Analysis Identify top resource consumers at process level. → For process I/O analysis, see [references/process monitoring.md](references/process monitoring.md process io) → For process network metrics, see [references/process monitoring.md](references/process monitoring.md process network) 4. Technology Stack Inventory Discover and track software technologies and versions. Common Technologies: Java, Node.js, Python, .NET, databases, web servers, messaging systems → For version compliance checks, see [references/inventory discovery.md](references/inventory discovery.md technology inventory) 5. Service Discovery via Ports Map listening ports to services for security and inventory. Well known ports (values are numeric — filter with an unquoted integer, listen port == 22 , not "22" ): 80 (HTTP), 443 (HTTPS), 22 (SSH), 3306 (MySQL), 5432 (PostgreSQL) → For comprehensive port mapping, see [references/inventory discovery.md](references/inventory discovery.md port discovery) 6. Container and Kubernetes Monitoring Track container distribution and K8s workload types. Workload Types: deployment , daemonset , statefulset , job , cronjob Note: Container image names/versions NOT available in smartscape. → For K8s version tracking, see [references/container monitoring.md](references/container monitoring.md kubernetes versions) → For container lifecycle, see [references/container monitoring.md](references/container monitoring.md container inventory) 7. Cost Attribution and Chargeback Calculate infrastructure costs by cost center. → For product level cost tracking, see [references/inventory discovery.md](references/inventory discovery.md cost attribution) 8. Infrastructure Health Correlation Correlate host and process metrics for cross layer analysis. Health scoring: Critical if any resource 90%, warning if 80% → For multi resource saturation detection, see [references/host metrics.md](references/host metrics.md resource saturation) 9. Disk Monitoring → For space, I/O, latency, inode, and fill prediction queries, see [references/disk monitoring.md](references/disk monitoring.md). Shared disks. A DISK Smartscape ID identifies a logical storage device — several can map to one physical device. Read disk.remote disk id (a property of the disk, constant across its mounts) straight from Smartscape for the Smartscape disk entities the problem fired on — a shared non zero value means one physical disk mounted in several places. Filter smartscape ids with matchesValue (not in , which rejects the smartscape id type): One row → those mounts share one physical disk (one root cause); mount count is how many of the queried mounts share it. Other mounts may not have alerted — the Fan Out query below enumerates the full set. Multiple rows → genuinely separate disks. Investigate each independently. A disk.remote disk id of 0 (filtered out) is a local, non shared disk. → See [references/disk monitoring.md](references/disk monitoring.md shared disks) for the corrections that follow — cross host attribution, blast radius, and environment wide shared disk discovery. 10. OneAgent Inventory Count and list hosts by OneAgent monitoring mode, version, or cloud region. ONEAGENT entity: OneAgent is a separate smartscape entity type ( smartscapeNodes "ONEAGENT" ). Access it by traversing backward from HOST via the monitors edge (the edge runs ONEAGENT → HOST, so HOST→ONEAGENT is direction: backward ). Key ONEAGENT fields: dt.agent.monitoring mode — monitoring coverage level: FULL STACK / INFRASTRUCTURE / DISCOVERY dt.agent.module.version — installed version string, formatted <major .<minor .<patch .<build Count by mode and version (for upgrade planning) — drop either field from by: for a single dimension breakdown (mode only, or version only): Monitoring modes: FULL STACK (full code level monitoring + infrastructure), INFRASTRUCTURE (infrastructure metrics only, no code level monitoring), DISCOVERY (topology discovery and basic host monitoring) → For listing hosts by mode/version, see [references/inventory discovery.md](references/inventory discovery.md oneagent inventory) Response Construction When the user asks for data retrieval or a DQL query (e.g., "show me top hosts by CPU"), include the DQL query in the response alongside the results. Users want to see and reuse the query — it is the deliverable, not just a means to get results. When the user asks for analysis (anomaly detection, forecasting, seasonality), the analysis results are the deliverable. Focus on presenting findings clearly: Prioritize metric level findings over data collection artifacts. If an analysis tool reports data gaps alongside actual anomalies, lead with the metric behavior the user asked about and mention gaps only as supplementary context. Include host names (not just IDs) using getNodeName(dt.smartscape.host) or the get entity name tool. State the timeframe analyzed and the tools/parameters used. Analytical Workflows Host metric queries often serve as inputs to analytical tools (anomaly detection, forecasting, seasonality analysis). This skill helps construct the right DQL query; the actual analysis is performed by dedicated tools. Anomaly Detection and Pattern Analysis When users ask about "unusual behavior", "anomalies", "spikes", or "sudden changes" in host metrics, the workflow is: 1. Construct the timeseries query using this skill's patterns 2. Pass it to the appropriate analysis tool (anomaly detector, novelty detection) Choosing between detectors: adaptive anomaly detector — use when the user asks about magnitude : "spikes", "abrupt changes", "values that went above normal", "sudden jumps". It answers "did this metric cross an unexpected threshold?" and reports alert durations and peak values. timeseries novelty detection — use when the user asks about behavioral change : "unusual patterns", "something changed", "trends", "new behavior". It answers "did the shape of the signal change?" without implying a specific threshold was crossed. Response format for anomaly results: Include both the host name (resolved via getNodeName(dt.smartscape.host) or get entity name ) and the host entity ID alongside timestamps and values. Entity IDs alone are opaque to users; names alone prevent follow up queries. Novelty type selection rule: When using novelty detection, set analysisNoveltyType to only [SPIKE, CHANGE IN VALUES, TREND IN VALUES] by default. EXCLUDE GAP WITH MISSING VALUES and CHANGE IN MISSING VALUES unless the user explicitly asks about data gaps or monitoring coverage. Data gaps are infrastructure issues, not metric behavior anomalies — reporting them when the user asks about CPU or memory patterns is incorrect. Queries for analysis tools should use simple timeseries format with a single aggregated metric and appropriate time range: Avoid adding filters or field transformations that reduce the data — the analysis tools work best with complete timeseries data. Forecasting When users ask to "predict", "forecast", or "estimate future" host metrics: 1. Construct the timeseries query with sufficient historical data (e.g., 7d for short term, 30d for longer predictions) 2. Pass to the forecasting tool with the desired forecast horizon The forecast horizon (how far ahead to predict) and the historical window (how much past data the model trains on) are independent. A request like "forecast the next 2 hours" sets the horizon to 2h — it says nothing about the lookback. Always use at least 7 days of historical data regardless of how short the forecast horizon is. Too few training data points cause the forecast model to fail and fall back to raw historical values. Seasonality Detection When users ask about "seasonality", "weekly patterns", or "recurring behavior": 1. Use a longer time range (at least 14d for weekly, 30d+ for monthly) 2. Pass to the seasonal baseline anomaly detector Response format for seasonal analysis: When presenting results, include: Whether seasonal anomalies were detected (yes/no) The analysis timeframe and parameters used For each affected host: host name (not just ID), timestamps of violations, violation counts, baseline values vs actual values, and upper/lower bounds Organize results by host if multiple hosts are involved Scope Boundary — Service Level vs Host Level Metrics This skill covers host and process infrastructure metrics only . If the user asks about service level metrics (request rate, response time, error rate, service calls per minute, throughput), use dt obs services instead — even when the questio

dt-obs-hosts