Skip to main content
The Filetrace agent can serve a page of metrics in the Prometheus text format: bytes that sockets sent and received per process, file bytes sent per transfer method and confidence, transfers started and in progress, open connections, lost events, and the agent’s own CPU time and memory. This page shows how to turn the page on and scrape it, lists every metric and label, gives PromQL examples, and explains how the number of series stays bounded.

Turn on the metrics page

1

Enable the page in the configuration file

Add the [prometheus] section to /etc/filetrace/config.toml:
2

Restart the agent

The agent reads the file only when it starts:
The agent’s log then reports serving metrics on http://127.0.0.1:9464/metrics.
3

Fetch the page

Listen address

listen is an address and a port. The address is numeric: an IPv4 address, or an IPv6 address in brackets such as [::1]:9464. localhost stands for 127.0.0.1; no other host name is resolved. The page is served over TCP only, so a unix: path is refused. The default, 127.0.0.1:9464, accepts connections from the same machine only. For a Prometheus server on another machine, set listen to an address of an interface that server can reach.
The page is served without authentication and without TLS. Anyone who can reach the address can read process names and traffic volumes. Keep it on the loopback address or on a network that only your monitoring can reach.
The agent checks the address when it starts. An address that is not in one of these forms is a configuration error (exit code 6), and an address the agent cannot listen on, for example because the port is taken, stops the agent with exit code 8 and the message Cannot serve metrics on followed by the address and the reason. See exit codes.

HTTP behaviour

  • A query string is ignored: /metrics?name=value returns the page.
  • The page is built from the agent’s state at each request; nothing is cached between scrapes.
  • Every response closes the connection (Connection: close).
  • The agent serves at most 8 connections at a time, and a connection that has not received its response within 5 seconds is closed. A request whose headers exceed 2 KB is dropped.

Scrape configuration

A minimal Prometheus scrape job for an agent on the same host:
Prometheus requests /metrics unless metrics_path says otherwise, so the job needs no path. To scrape several hosts, list each host’s listen address under targets. The host_name label of target_info names the host each target runs on.

Metrics

The last two process_ metrics describe the agent itself, not the processes it observes. The metrics and attributes reference gives the OpenTelemetry name and unit of each metric. A complete page:

Labels

A label value that is not valid UTF-8 is written with ? in place of the offending bytes. Attribution and confidence explains the methods and confidence levels.

Query examples

More queries that use only the metrics and labels above:
Other targets can export process_cpu_time_seconds_total and process_memory_usage_bytes too, so select the agent’s series by job as in the last query.

Series limit

Three counters carry a process name and therefore grow with the number of distinct processes on the host: filetrace_network_io_bytes_total has one series per process, transport and direction, and filetrace_file_sent_bytes_total and filetrace_transfers_started_total have one per process, method and confidence. [limits] metric_series bounds the label sets of these three counters together. The default is 2048, and the setting accepts 64 to 4194304:
Once the limit is reached, a new label set does not get a series of its own. Its amounts are added to one overflow series per metric, which has the single label otel_metric_overflow="true", as OpenTelemetry SDKs do. Series that already exist keep counting, and nothing is evicted, so a sum over all series of a metric stays correct. The other metrics have fixed label sets and do not count against the limit.

Counter behaviour

  • Counters start at zero when the agent starts. A restart of the agent is a counter reset, which rate() and increase() handle.
  • A counter never goes backwards while the agent runs. Counters are kept apart from the agent’s tables, which forget their least recently used entries, and a label set stays on the page for as long as the agent runs.
  • Bytes of a read-write transfer are counted once the transfer is reported, from its first byte. Until the association reaches the reporting thresholds it adds nothing to filetrace_file_sent_bytes_total; then the counter takes all of its bytes at once. filetrace_transfers_started_total counts each transfer once, when it is first reported.
  • Byte counts are what the local socket accepted from the process or delivered to it. They are not bytes on the wire and not what the remote end acknowledged.

No paths or addresses in labels

No metric is labelled with a file path, an IP address or a port: those belong to events. To see which files went where, use the OTLP log records, the gRPC API, or filetrace files.

Exclude the agent’s own traffic

The agent’s own network traffic, such as its responses to Prometheus scrapes and its OTLP requests to a collector over TCP, loopback included, is counted like that of any other process. To leave it out:
exclude_processes applies to everything the agent records, not only to metrics: the excluded process no longer appears in the commands, the log records or the API either.