Skip to main content

Manage Sensor Configuration

The Sensor comes pre-configured with appropriate defaults to capture API Traffic (HTTP) from your applications.

The Sensor can be customized via a

Loading...
. Examples of customization include, a) granular filtering of API traffic being captured, b) enabling debugging, c) performance tuning, etc.

Haven't installed the Sensor yet?

This page is about configuring a Sensor you already have. To install one, start at Install eBPF Sensor and pick your platform.


Configuration File Format​

The configuration file is YAML. Every setting already has a sensible default, so you only need to add the ones you want to change. Most settings in the shipped file are commented out with # — uncomment a line to override the default.

The file is organised into these sections:

SectionWhat it controls
Factory SettingsInternal tuning: thread count, BPF object path, proxies. Leave these alone unless support@levo.ai asks you to change them.
Default Application SettingsThe name your API endpoints are grouped under in the API Catalog.
Satellite SettingsWhere the Sensor sends captured traffic, and how often it reports health.
API Trace Export Rate LimitingCaps how many traces the Sensor sends per second, overall and per endpoint.
Metrics SettingsWhether the Sensor logs its own metrics.
TLS SettingsCertificates and verification for the connection to the Satellite.
Process FiltersWhich Linux processes to capture from — or which to skip.
IP FiltersCapture rules based on ports, IP addresses and networks.
URL FiltersCapture rules based on HTTP method, host and URI.
Memory-related settingsThe largest request/response body the Sensor will parse.

Sensors running on Kubernetes have an additional Kubernetes Pod Filters section, supplied through the Helm values file rather than this file. See Kubernetes Pod Filters below.

This is the file the Sensor ships with

The YAML below is the complete default configuration, exactly as installed at /etc/levo/sensor/config.yaml. You can also

Loading...
it.

Note that satellite-url is not in this file — it is normally passed when you start the Sensor. See Satellite Settings.


##############################################################################################
# eBPF Sensor Configuration Settings (YAML Format)
# Copyright: Levo Inc., 2026
##############################################################################################


# --------------------------------------------------------------------------------------------
# Factory Settings: DO NOT MODIFY
# --------------------------------------------------------------------------------------------
#bpf-object-file: /opt/levo/libexec/levo/ebpf-sensor/bpf_progs.bpf.o
#debug: []
#legacy-kernel-btf-path: ""
#single-threaded-mode: false
#worker-threads: 3 # Defaults to 3, or the number of CPUs in the system, whichever is greater
#metadata-resolution-failure-policy: ignore # policy for handling metadata resolution failures
trace-client-traffic: true # enable tracing of client-side traffic generated by the host
#trace-non-k8s-traffic: false # enable tracing of non-Kubernetes traffic when deployed within a Kubernetes DaemonSet
#http-proxy: "" # Proxy used for HTTP requests
#https-proxy: "" # Proxy used for HTTPS requests
#kube-api-rate-limit-time: 10 # Interval between each successful Kube Api call in seconds
# --------------------------------------------------------------------------------------------


# --------------------------------------------------------------------------------------------
# Default Application Settings:
# --------------------------------------------------------------------------------------------
# Auto discovered API endpoints and their OpenAPI specifications are shown in the API Catalog
# grouped under this application name. The application name helps segregate and group API
# endpoints from different environments.

default-service-name: default
# --------------------------------------------------------------------------------------------


# --------------------------------------------------------------------------------------------
# Satellite Settings:
# --------------------------------------------------------------------------------------------

# Use HTTP/2 (gRPC) for communication with the collector. If this is disabled, HTTP/1.1 will be used.
collector-grpc-transport: true

# Interval in seconds between sensor health report API calls to the satellite (default: 30).
#health-report-interval-seconds: 30

# --------------------------------------------------------------------------------------------

# --------------------------------------------------------------------------------------------
# API Trace Export Rate Limiting:
# --------------------------------------------------------------------------------------------
# By default, the sensor rate-limits the overall number of request-response traces it exports
# to the satellite.  It also rate-limits traces on a per-endpoint basis.  Rate limiting can
# be disabled or adjusted, but doing so may affect the performance of downstream Levo
# services.

# enable-export-rate-limiting: true
# max-total-exported-requests-per-second: 100
# max-per-endpoint-exported-requests-per-second: 2
# token-bucket-refresh-period-ms: 1000 # 1 second

# Maximum number of events within a fixed window of time, disabled by default, set to positive number to enable
# bpf-rate-limit-window-size: -1
# Time interval in milli-seconds during which the specified number of events (bpf-rate-limit-window-size) are allowed
# bpf-rate-limit-window-duration-ms: 1000
# --------------------------------------------------------------------------------------------

# --------------------------------------------------------------------------------------------
# Metrics Settings:
# --------------------------------------------------------------------------------------------
# Uncomment and modify to enable the printing of sensor metrics alongside other sensor logging
# messages.

# export-otel-logs: true
# export-metrics-to-log: true
enable-metrics: true
# --------------------------------------------------------------------------------------------

# --------------------------------------------------------------------------------------------
# TLS Settings: Configs for TLS connectivity with Satellite
# --------------------------------------------------------------------------------------------
#ignore-ssl-verify: false # Ignore ssl verify when connecting to the collector
#tls-client-cert-path: "" # TLS Client certificate path
#tls-client-key-path: "" # TLS Client key path
#tls-ca-cert-path: "" # TLS CA Cert path
# --------------------------------------------------------------------------------------------

# --------------------------------------------------------------------------------------------
# Process Filters: process command names/IDs to monitor & capture API traffic.
# --------------------------------------------------------------------------------------------
# Uncomment and modify appropriately to limit capture to specific process names or IDs.
# Both monitored-commands and monitored-pids support list of names & IDs respectively.
# NOTE: monitored-commands and monitored-pids settings are mutually exclusive
# Command names will be truncated to 15 characters, since that is the maximum allowed comm size.
# https://www.kernel.org/doc/html/latest/filesystems/proc.html#proc-pid-comm-proc-pid-task-tid-comm

#monitored-commands:
#  - <process command name. Example: nginx>
#  - <process command name. Example: python3>

ignored-commands:
- proxy-agent
- operator
- metrics-server
- kube-controller
- pod_nanny
- MetricsExtension
- postgres
- kube-state-metrics  # ref: https://github.com/kubernetes/kube-state-metrics
- prometheus  # ref: https://github.com/prometheus/prometheus
- node_exporter  # ref: https://github.com/prometheus/node_exporter
- redis_exporter  # ref: https://github.com/oliver006/redis_exporter
- cloud-node-manager  # ref: https://github.com/kubernetes-sigs/cloud-provider-azure/blob/ce798999ad48f6fb2063a808b9dcedec2fadd49a/examples/out-of-tree/cloud-node-manager.yaml
- kube-proxy
- loki
- argocd-server
- argocd-applicat
- argocd-dex
- argocd-notifica
- argocd-repo-ser
- kubectl-argo-ro
- amazon-ssm-agen
- aws
- awsagent
- aws_k8s_agent
- aws_ebs_csi_dri
- cluster_autosca
- csi_attacher
- csi_node_driver
- csi_provisioner
- csi_resizer
- csi_snapshotter
- datacollector
- datadog_cluster
- teleport
- agent
- process_agent
- trace_agent
- fluent-bit

#monitored-pids:
#  - <pid. Example: 123>
#  - <pid. Example: 45>
# --------------------------------------------------------------------------------------------


# --------------------------------------------------------------------------------------------
# IP Filters: IP/Port/Network address based granular filtering of API traffic.
# --------------------------------------------------------------------------------------------
# IP Filters enable granular capture of API traffic based on various criteria.
# Default values ignore traffic from standard ports that normally do not carry HTTP traffic.
# Refer to documentation on how these can be customized to suit your environment.
ip-filter-list:
default-policy: accept # Default policy is to capture all traffic
entries: # Specific 'entries' can override the default policy
  ### Host Ports ###
  # Host Port is the server listening port, where client connections are accepted.
  - policy: drop
    host-ports: 53 # DNS
  - policy: drop
    host-ports: 2379-2380 # etcd
  - policy: drop
    host-ports: 9092-9093 # kafka
  - policy: drop
    host-ports: 27017-27019 # mongodb
  - policy: drop
    host-ports: 28017 # mongodb
  - policy: drop
    host-ports: 135 # SQL Server
  - policy: drop
    host-ports: 1433-1434 # SQL Server
  - policy: drop
    host-ports: 4022 # SQL Server
  - policy: drop
    host-ports: 3306 # MySQL
  - policy: drop
    host-ports: 33060-33062 # MySQL
  - policy: drop
    host-ports: 5432-5433 # Postgres
  - policy: drop
    host-ports: 5671-5672 # RabbitMQ
  - policy: drop
    host-ports: 15672-15675 # RabbitMQ
  - policy: drop
    host-ports: 25672 # RabbitMQ
  - policy: drop
    host-ports: 35672-35682 # RabbitMQ
  - policy: drop
    host-ports: 61613-61614 # RabbitMQ
  - policy: drop
    host-ports: 6379 # Redis
  - policy: drop
    host-ports: [2181, 3888, 3888] # ZooKeeper
  - policy: drop
    host-ports: [4317, 4318, 9999] # Levo's Satellite services
  - policy: drop
    host-ports: 8126 # datadog
  ### Peer Ports ###
  # Peer Port is the client port used in communication with the server listening port.
  - policy: drop
    peer-ports: 53 # DNS
  - policy: drop
    peer-ports: 2379-2380 # etcd
  - policy: drop
    peer-ports: 9092-9093 # kafka
  - policy: drop
    peer-ports: 27017-27019 # mongodb
  - policy: drop
    peer-ports: 28017 # mongodb
  - policy: drop
    peer-ports: 135 # SQL Server
  - policy: drop
    peer-ports: 1433-1434 # SQL Server
  - policy: drop
    peer-ports: 4022 # SQL Server
  - policy: drop
    peer-ports: 3306 # MySQL
  - policy: drop
    peer-ports: 33060-33062 # MySQL
  - policy: drop
    peer-ports: 5432-5433 # Postgres
  - policy: drop
    peer-ports: 5671-5672 # RabbitMQ
  - policy: drop
    peer-ports: 15672-15675 # RabbitMQ
  - policy: drop
    peer-ports: 25672 # RabbitMQ
  - policy: drop
    peer-ports: 35672-35682 # RabbitMQ
  - policy: drop
    peer-ports: 61613-61614 # RabbitMQ
  - policy: drop
    peer-ports: 6379 # Redis
  - policy: drop
    peer-ports: [2181, 3888, 3888] # ZooKeeper
  - policy: drop
    peer-ports: [4317, 4318, 9999] # Levo's Satellite services
  - policy: drop
    peer-ports: 8126 # datadog
  - policy: drop
    peer-network: 169.254.169.254 # AWS / Azure Metadata Service
# --------------------------------------------------------------------------------------------


# --------------------------------------------------------------------------------------------
# URL Filters: API parameter based granular filtering of API traffic.
# --------------------------------------------------------------------------------------------
# URL filters allow granular filtering of API traffic based on the 'API endpoint Method' (operation),
# the 'API Host' (Host Header), and the 'API endpoint's URI'.
# Refer to the documentation for instructions on configuring URL filters.
url-filter:
default-url-action: trace # Trace all API endpoints by default
rules:
  - action: ignore
    request-uri: /stats/prometheus


# --------------------------------------------------------------------------------------------
# Memory-related settings
# --------------------------------------------------------------------------------------------
# The maximum request or response body size the sensor will parse.  Request or response bodies
# larger than this limit will be ignored by the sensor.
# max-msg-body-size-bytes: 512000
# ---------------------------------------------------------------------------------------------

Factory Settings​

These settings control logging, debugging, and performance tuning functions. DO NOT modify these settings, unless specifically asked by support@levo.ai.

SettingWhat it does
worker-threadsHow many threads process captured traffic. Defaults to 3, or the CPU count, whichever is greater.
single-threaded-modeForces everything onto one thread. Diagnostics only.
trace-client-trafficCapture traffic the host sends as a client, not just traffic it receives. On by default.
trace-non-k8s-trafficOnly meaningful inside a Kubernetes DaemonSet — capture traffic from processes that are not part of a Pod. Off by default.
metadata-resolution-failure-policyWhat to do with traffic from a service whose metadata the Sensor cannot resolve. Defaults to ignore, meaning that traffic is not captured while the Sensor keeps retrying resolution. Set it to trace to capture immediately instead of retrying.
kube-api-rate-limit-timeSeconds between calls to the Kubernetes API. Defaults to 10.
bpf-object-file, legacy-kernel-btf-pathPaths the Sensor uses to load its eBPF programs.
debugTurns on debug logging — see Enable debug logging.

HTTP/HTTPS Proxy​

You may configure an HTTP/HTTPS proxy for requests made by the Sensor to the Satellite, e.g.

http-proxy: "http://your-proxy:8080" # Proxy used for HTTP requests
https-proxy: "http://your-proxy:8080" # Proxy used for HTTPS requests

The two values are usually the same, and that is intentional:

  • The setting name picks which requests use the proxy. http-proxy applies when satellite-url is http://…, and https-proxy applies when it is https://….
  • The value is the proxy's own address. Most networks run a single proxy for both, so both point at it.
  • https-proxy normally starts with http:// too. The Sensor reaches the proxy over plain HTTP and asks it to open a tunnel (CONNECT) to the Satellite. TLS still runs end to end between the Sensor and the Satellite, and the proxy only relays the encrypted bytes.

Use different values only if your network has separate proxies for HTTP and HTTPS traffic. Set just the one that matches your satellite-url, and leave the other empty.

These map to the standard http_proxy / https_proxy environment variables, so a proxy that works with curl from the same host will work for the Sensor.


Default Application Name​

Auto-discovered API endpoints and their OpenAPI specifications are displayed in the API Catalog, grouped by application name. The application name helps organize and segregate API endpoints from different environments, similar to how folders work in a file system.

This is the default-service-name setting, and it ships as default. Change it to something that identifies your application, for example payments-api.

It is only a fallback. On Kubernetes — and anywhere else the Sensor can work out which service traffic belongs to — endpoints are attributed to the real service automatically, and this name is not used.


Satellite Settings​

These settings control where the Sensor sends what it captures, and how it reports in.

Set satellite-url to your own Satellite's gateway address (HAProxy, port 80 by default), or to https://satellite.levo.ai if Levo hosts the Satellite for you.

One URL for everything — and it must be HAProxy

The Sensor takes a single satellite-url and uses it for both of its connections: traces over gRPC, and health and configuration over REST. There is no separate Collector URL to set.

Only HAProxy routes both kinds of traffic, so point the Sensor at HAProxy:

Where the Satellite runssatellite-url
Same Kubernetes clusterlevoai-haproxy (the Helm default)
Docker Compose / VMhttp://<satellite-host>:80
Hosted by Levohttps://satellite.levo.ai

Do not use the Satellite's 9999 or the Collector's 4317 directly. With 9999 the Sensor registers and reports healthy but exports no traces. With 4317 traces flow, but health and configuration calls fail.

SettingWhat it does
satellite-urlWhere traces are sent. Usually passed on the command line or through /etc/default/levo-ebpf-sensor rather than set in this file.
collector-grpc-transportUse HTTP/2 (gRPC) to talk to the Satellite. On by default; turn it off to fall back to HTTP/1.1.
health-report-interval-secondsHow often the Sensor reports its health. Defaults to 30 seconds.
organization-idYour Levo Organization ID. Required when Levo hosts the Satellite for you.

For encrypting this connection, see Setting up TLS from Sensor to Satellite.


API Trace Export Rate Limiting​

The Sensor allows rate limiting the overall number of traces it exports to the Satellite (max-total-exported-requests-per-second).

Rate limiting may also be done on a per-endpoint basis (max-per-endpoint-exported-requests-per-second).

Rate limiting is optional and may be toggled with the enable-export-rate-limiting setting.

The default values for these settings are listed below.

enable-export-rate-limiting: true
max-total-exported-requests-per-second: 100
max-per-endpoint-exported-requests-per-second: 2
token-bucket-refresh-period-ms: 1000

The per-endpoint limit is much lower than the overall limit, so that a single busy endpoint cannot consume the whole budget and crowd out traffic from quieter ones.

Raising these values may affect the performance of downstream Levo services, so increase them gradually and watch the Satellite's load.

Process & IP Filters​

These settings allow granular control over what API traffic is captured by the Sensor. Please see detailed section on API Traffic Capture Filters.

Process filters decide which Linux processes the Sensor watches:

SettingWhat it does
ignored-commandsProcesses to skip. Ships with 38 entries — Prometheus, Datadog, ArgoCD, the CSI drivers, kube-proxy and similar infrastructure that generates a lot of non-API traffic.
monitored-commandsIf set, capture only these processes. Empty by default, meaning capture everything except ignored-commands.
monitored-pidsThe same idea, by process ID instead of name.
Two things that catch people out

monitored-commands and monitored-pids are mutually exclusive — set one or the other, not both.

Process names are compared on their first 15 characters, because that is the maximum Linux stores in /proc/<pid>/comm. You can write entries either way:

  • Already shortened, like argocd-applicat in the shipped list.
  • In full, like MetricsExtension or kube-state-metrics. The Sensor shortens these itself at startup and logs WARNING: Truncating ignored command 'MetricsExtension' to 15 characters. That warning is expected and harmless.

Two names that share the same first 15 characters are indistinguishable to the Sensor, so listing one also matches the other.

IP filters decide which connections are captured, by port, address or network. The Sensor already drops traffic on 20 well-known non-HTTP port ranges — databases, message queues, DNS, and Levo's own Satellite ports — each excluded both as a host port and as a peer port. See Default Excluded Ports for the full list.


URL Filters​

These settings allow granular control over what API traffic is captured by the Sensor, based on API parameter filters. Please see detailed section on API Traffic Capture Filters.

Rules match on HTTP method, host, and URI, and are evaluated in order — the first matching rule wins, so put the most specific rules first. default-url-action decides what happens when nothing matches.

The Sensor ships with default-url-action: trace and one rule, which drops Envoy's Prometheus scrape endpoint:

url-filter:
  default-url-action: trace
  rules:
    - action: ignore
      request-uri: /stats/prometheus

Kubernetes Pod Filters​

These settings allow granular control over what API traffic is captured by the Sensor based on Kubernetes metadata (e.g., namespace name, deployment name, etc.).

Please see detailed section on API Traffic Capture Filters.

These come from Helm, not from config.yaml

k8s-pod-filter-list is not part of the default config.yaml shown above. It is supplied through the Helm values file when you install on Kubernetes.

The chart ships with default-policy: trace and a set of rules that ignore observability and platform namespaces — kube.*, istio.*, levoai, datadog, monitoring, prometheus, grafana, kubecost, observability, argocd, argo_rollouts, calico.*, tigera.*, openebs, logstash, lacework — plus any Pod owned directly by a Node.

So on Kubernetes the Sensor already skips most infrastructure traffic before you configure anything. Edit the Helm values if you need to trace one of those namespaces.


TLS Settings​

These control how the Sensor verifies the Satellite when connecting over HTTPS.

SettingWhat it does
ignore-ssl-verifySkip certificate verification. Leave this false. Setting it to true disables the check that the Satellite is who it claims to be.
tls-ca-cert-pathPath to the CA certificate the Sensor should trust. Use this when the Satellite presents a private or self-signed certificate.
tls-client-cert-path / tls-client-key-pathClient certificate and key, for mutual TLS (mTLS) only.

Full walkthrough: Setting up TLS from Sensor to Satellite.


Memory Settings​

max-msg-body-size-bytes caps how much of a request or response body the Sensor will parse. It defaults to 512000 (500 KB).

Bodies larger than this are skipped entirely — the Sensor does not truncate them, it ignores them. If your APIs exchange large payloads and you are not seeing them in the Catalog, raise this. Raising it increases the Sensor's memory use.


Applying Configuration Settings​

Running on Kubernetes​

Configuration is specified via a Helm Values file.

  • Modify the default
    Loading...
    file to suit your requirements.
  • Save the configuration values file to your current working directory.
  • Note down your Satellite URL (see Satellite Settings).
  • Apply the new configuration by executing the below command from the directory where you saved the config-values.yml.
# <satellite-url> is the Satellite's HAProxy address:
#   - Sensor in the same cluster as the Satellite: levoai-haproxy
#   - Sensor in a different cluster: the address where levoai-haproxy is exposed
#   - Levo-hosted Satellite: the hosted Satellite URL
#
# Specify the 'Application Name' chosen earlier in the config-values.yml file.
#
helm upgrade levoai-sensor levoai/levoai-ebpf-sensor \
  --install \
  --namespace levoai \
  --create-namespace \
  --set sensor.satelliteUrl=<satellite-url> \
  --values config-values.yml

You may also specify specific configuration values using helm --set. For example,

helm upgrade levoai-sensor levoai/levoai-ebpf-sensor \
  --install \
  --namespace levoai \
  --create-namespace \
  --set "sensor.config.monitored-commands={python3,java}"

Please check the Sensor logs to ensure that the specified configuration values do not have any syntax errors, and the Sensor is running with the applied configuration.

Running via Docker​

  • Modify the default
    Loading...
    to suit your requirements.
  • Save the configuration file to your current working directory.
  • Shutdown/uninstall the Sensor if running.
  • Note down your Satellite URL (see Satellite Settings).
  • Reinstall the Sensor by executing the below command from the directory where you saved config.yml. config.yml is mounted into the Sensor container as read only.
# <satellite-url> is the Satellite's HAProxy address, e.g. http://<satellite-host>:80
sudo docker run --restart unless-stopped \
  -v /sys/kernel/debug:/sys/kernel/debug -v /proc:/host/proc \
  -v $PWD/config.yml:/etc/levo/sensor/config.yaml:ro \
  --privileged --detach \
  levoai/ebpf_sensor:latest \
  --host-proc-path /host/proc \
  --satellite-url <satellite-url> \
  --organization-id <OrgID> \
  --env <application-environment>

Please check the Sensor logs to ensure the configuration file does not have any syntax errors, and the Sensor is running with the applied configuration.

Running on Linux Host​

Make your modifications to /etc/levo/sensor/config.yaml and save the file. Restart the sensor for the settings to take effect.

Please check the Sensor logs to ensure the configuration file does not have any syntax errors, and the Sensor is running with the applied configuration.

Troubleshooting and Maintenance​

Enable debug logging​

Debug logging is controlled by the debug setting in the

Loading...
. It takes a list of debug flags. Add it, then restart the Sensor:

debug:
  - all

all turns on every debug flag. To keep the volume down, enable only the subsystems you are investigating:

debug:
  - span-builder

Which flag to pick depends on where the problem is:

SymptomStart with
Traffic is captured but the spans look wrong — bad method, URI or bodyspan-builder
Nothing reaches the Satellite, or exports are failingotel, otel-info
No traffic captured at all, or probes are not attachingebpf-subsystem, libbpf
Endpoints attributed to the wrong servicemetadata-resolver

Available flags:

AreaFlags
Everythingall
Satellite export (OTel)otel, otel-info
eBPF subsystemebpf-subsystem, ebpf-lifecycle-event, ebpf-data-event, libbpf, libbpf-info, libbpf-warn, elf-file, uprobe
Traffic processingevent-router, event-data-container, span-builder, instrumented-connection
Metadata / schedulingmetadata-resolver, task-meta-scheduler
Protobufprotobuf, protobuf-warn, protobuf-err, protobuf-fatal

The value must be a list. A bare string fails at startup with Configuration error: value for debug must be a list of debug flags.

The same flags can be passed on the command line with --debug (short form -d), repeated once per flag:

levo-ebpf-sensor --debug otel --debug event-router
Do not leave debug logging enabled in Kubernetes

In Kubernetes, debug logging creates a positive feedback loop that saturates the Sensor:

[debug logging events] -> [more kube logging API traffic] -> [more eBPF events] -> [more debug logging events] -> ...

Enable it only for as long as you need a diagnosis, then turn it off again.

Disable debug logging​

Debug logging is off by default. To turn it off again, remove the debug setting from the

Loading...
(or drop the --debug flags from the command line) and restart the Sensor.

View Sensor logs​

sudo journalctl -u levo-ebpf-sensor.service -b -f --since "15min ago"

# If journalctl is not showing logs, check syslog instead:
sudo tail -f /var/log/syslog | grep levo

Verify the Sensor can reach the Satellite​

The Sensor logs the result of its first connection attempt on startup:

sudo journalctl -u levo-ebpf-sensor.service -b | grep "Initial connection with Collector"

A successful connection logs Initial connection with Collector was successful. A failure logs Initial connection with Collector failed with status_code ....

If the connection fails, check that the Satellite's gateway is reachable from the Sensor host:

curl -sS -o /dev/null -w "%{http_code}\n" http://<Satellite-Host>/healthz

A 200 response means the gateway is reachable. Anything else usually means a firewall rule or cloud security group is blocking port 80 between the Sensor host and the Satellite host.

Check the applied configuration​

After any configuration change, restart the Sensor and check its logs to confirm the file parsed cleanly and the Sensor started with the settings you expect. A YAML syntax error or an invalid value is reported at startup and the Sensor will not run with the new settings.

Installing the Sensor​

Installing a Sensor for the first time, or adding one on another host? Start here:

Or go straight to your platform:

PlatformGuide
KubernetesSensor on Kubernetes
AWS ECSSensor on AWS ECS using Terraform
DockerSensor via Docker
Debian / UbuntuSensor via APT Package
RHEL / Amazon LinuxSensor via YUM Package
Linux host (systemd)Sensor as a Systemd Service
Was this page helpful?