Sensor Overview
The Telovix Sensor observes Linux runtime activity with eBPF and sends structured security evidence to the Telovix Console. Deploy one Sensor on each Linux host or Kubernetes node that you want to monitor.
The Sensor operates without an inbound management port. Enrollment, telemetry delivery, policy updates, certificate renewal, and supported upgrades use outbound connections to the Console.
Where to start
| Goal | Guide |
|---|---|
| Install on a VM or bare-metal host | Sensor: VM or Bare Metal |
| Deploy a Kubernetes or K3s DaemonSet | Sensor: Kubernetes |
| Deploy short-lived cloud instances | Sensor: Ephemeral VM |
| Choose Standard or Telecom | Sensor Flavors |
| Diagnose stale, degraded, or offline sensors | Sensor Health |
| Plan a fleet upgrade | Upgrading Sensors |
What the Sensor observes
Both Sensor flavors provide the normal Telovix runtime security capabilities:
- process execution, exit, ancestry, users, and execution context;
- file activity and integrity evidence;
- network connections, listening services, flows, and DNS activity;
- HTTP, gRPC, and supported TLS plaintext visibility for API Security;
- containers and Kubernetes workload attribution when that context is available;
- runtime detections, policy evidence, and enforcement outcomes;
- host resource, delivery, and capture-health metrics.
Evidence varies by kernel, workload, protocol, encryption library, permissions, and network path. The Console reports missing or degraded visibility instead of treating unavailable evidence as healthy.
The Telecom flavor includes all Standard capabilities and adds supported 3GPP, 5G Core, EPC, IMS, and O-RAN protocol and network-function visibility. See Standard vs Telecom Flavor for the detailed comparison.
Identity and attribution
Each enrolled Sensor receives its own identity and client certificate. Events retain the observed host and process identity. When the Sensor runs on Kubernetes, it also attaches known cluster, namespace, workload, pod, container, and service context.
Telovix does not assign Kubernetes metadata to a process that was not observed in Kubernetes. Unresolved destinations remain explicitly unresolved until reliable evidence identifies them.
Delivery during normal operation
The Sensor uses a live outbound stream for low-latency events and a periodic heartbeat for health, inventory, control responses, and delivery recovery. The Console shows queue depth, suppressed evidence, capture loss, and other coverage signals in Sensor health views.
If Console delivery is temporarily unavailable, eligible security events can use a bounded local spool. The spool is limited by both event count and disk usage; it is not a complete packet archive. API request or response content, query evidence, and extended-capture content are not written to this spool. This keeps outage handling bounded and avoids accumulating high-volume API payloads on the node.
Do not treat local buffering as a substitute for reliable Console connectivity. Sustained queue growth or delivery pressure means that the Console path must be restored.
Resource behavior
The Sensor is event-driven. Its active CPU use depends on observed process, file, network, API, DNS, TLS, and telecom traffic. Features that capture or inspect additional evidence can increase active CPU and memory use even when idle overhead remains low.
Before a broad rollout:
- Measure the target node's idle and peak baseline.
- Deploy one canary Sensor with the intended flavor and policies.
- Compare CPU, memory, event loss, queue depth, and application latency.
- Expand only after the canary remains within your operating envelope.
Use the limits and Kubernetes defaults in Requirements as deployment starting points, not as guaranteed consumption for every workload.
Deployment models
| Deployment | Installation and lifecycle |
|---|---|
| VM or bare metal | Console-generated installer and a host service. Supported installations can use managed fleet upgrades. |
| Kubernetes or K3s | Helm-managed DaemonSet with one Sensor per selected node. Upgrade through Helm. |
| Ephemeral VM | Fleet enrollment from cloud-init or an image template. Replace instances through the normal infrastructure lifecycle. |
| Air-gapped network | Transfer the Console release and license into the network, then use the internal Console to install Sensors. |
Use the deployment command generated by your Console. It contains the Console address, deployment type, flavor, and enrollment settings expected by that instance.
Standard and Telecom flavors
Choose the flavor when generating the deployment command:
- Standard for general Linux, container, Kubernetes, API, and runtime security.
- Telecom for the complete Standard feature set plus telecom protocol, network-function, RAN, user-plane, and O-RAN visibility.
Changing flavor requires replacing the installed Sensor binary or Kubernetes image. Re-enrollment is normally unnecessary when the existing Sensor identity and state are preserved.
Trust and control
The Console issues and renews Sensor certificates after enrollment. Runtime policy changes and operator actions are authenticated and recorded by the Console. A revoked Sensor identity cannot continue using its former trust relationship.
Runtime enforcement is separate from observation. Assigning a detection policy does not silently enable blocking. Review Enforcement Mode before enabling actions that can affect workloads.
Operating the Sensor
Use Sensors > Fleet to review fleet-wide version, health, trust, and delivery state. Select a Sensor for host details, performance, coverage, policies, deployment-specific upgrade instructions, or uninstall guidance.
Investigate these conditions before relying on the affected Sensor's evidence:
- stale or offline heartbeat;
- trust or certificate failure;
- runtime initialization failure;
- BPF event loss;
- sustained delivery pressure or a growing queue;
- unsupported capture path or protocol;
- resource pressure on the monitored node.
The Health States and Heartbeat guide explains the status and coverage indicators shown in the Console.