Infrastructure monitoring

The viewing side of the Infrastructure app — how host, container and Kubernetes data is explored after the agent collects it. The collection side (which readers, which indexes) is in host-monitoring.md; this page is about what the app’s three pages show and how the Kubernetes auto-discovery is configured.

The three pages

The app opens into Host, Containers and Kubernetes Analysis, all built from the same metric repos the collection side writes (infrastructure_monitoring_metrics / _meta / _events).

Host

The host inventory, in two modes switchable at the top:

List — every host with its state. Fields: host name (sortable by CPU usage), IP, status (Active / Inactive — Inactive means no data for more than 5 minutes), system type, tags, CPU usage, memory usage, load 1/5/15, agent version, single-core load, boot time, last updated. Custom display fields, export to dashboard or CSV, and a total count.
Map — the host “cellular” view: each host a cell, colored by a chosen metric with configurable thresholds, grouped by a chosen field. Cells can be added to a dashboard.

Both modes share the top search bar (K-V or keyword search; Save as Report persists the criteria and custom fields). The chart icon opens the custom-chart visual analysis — pick a field, a calculation (average default; min/max/rate/count/distinct-count/latest/P50–P99 for numeric fields, distinct-count for strings, count only over all events), grouping fields, and an interval.

Containers

The same two modes over containers. List fields: container name, status (created, running, exited, paused, stopping, dead, restarting, unknown — filterable), namespace, pod name, host, image, image tag, runtime, CPU usage and cores, CPU limit, memory usage and limit, disk IO read/write rate, network read/write rate, container ID, host IP, container type. Map mode mirrors the host cellular view, grouping by namespace or pod.

Kubernetes Analysis

Cluster, node, pod and workload views: the base info pages (cluster, nodes, pods, namespaces, PVs) and the workload pages (deployment, statefulset, daemonset, job, cron job, ingress, service, access control) plus cluster events. Each is a fragment driven off the same _tel/_ntel k8s metrics the collection side writes.

The app’s strings are English (an en_US dictionary ships with 838 keys, 217 of them the k8s fragment labels); the app title resolves to Infrastructure.

Kubernetes auto-discovery

The agent’s discovery service watches the cluster and attaches collection to pods as they start and stop — without it, every pod restart would need its log path re-registered by hand. Configured under the agent’s discovery block:

discovery:
  kubernetes:
    enabled: true
    kubeconfig: ""
    nodename: ""
    container_runtime: docker
    runtime_endpoints:
      - unix:///var/run/docker.sock
    docker_version: "1.38"
    containerd_namespace: ""
    crio_version: ""
    pod_log_dir_prefix: ""
    proc_dir_prefix: ""
    events:
      collect_log: true

container_runtime — docker, containerd or crio. Defaults to auto-detection when unset.
runtime_endpoints — the runtime’s socket; default unix:///var/run/docker.sock, unix:///var/run/containerd/containerd.sock, or unix:///var/run/crio/crio.sock per runtime.
docker_version — the Docker protocol version used for the runtime conversation (default 1.38); an older Docker server may need it lowered.
containerd_namespace / crio_version — the containerd namespace and CRI-O protocol version.
pod_log_dir_prefix / proc_dir_prefix — where the host keeps pod log files and proc data, for the mount-into-container mapping.
events.collect_log — whether the agent also collects cluster events.

The runtime sockets must be reachable from inside the agent. When the agent runs in a container, the host’s runtime socket and log directories have to be mounted in with the same paths the agent expects — the classic failure is logs that “should” collect but never appear because /var/lib/docker/containers inside the agent is not the host’s. The mapping is a one-time mount decision made at agent deploy.

The env-var names in older documentation are stale. Older documentation shows this config as discoveryKubernetes: with KETAD_KUBERNETES_CONTAINER_RUNTIME / KETAD_KUBERNETES_RUNTIME_ENDPOINTS / KETAD_KUBERNETES_DOCKER_VERSION env vars. The shipped agent reads the YAML block above (discovery.kubernetes) and the platform API (AgentKubernetes) — the env-var spellings will not be read. The auto-discovery rule page in the product (Kubernetes → rules) mounts the platform’s collection container at kubernetes/kubernetesRule; it is the same rule-management surface documented under collection.