filetrace.loss.kind. It also gives the rule that turns an OpenTelemetry name into a Prometheus name. The same names appear on the Prometheus page and in the OTLP export.
Naming
Fields that OpenTelemetry’s semantic conventions cover use those names, such asprocess.pid, file.path and network.peer.address. Everything else is under filetrace..
A Prometheus name is made from the OpenTelemetry name the way an OpenTelemetry Collector makes it, so a query works whichever way the metrics arrive:
- Every character other than a letter, a digit or an underscore becomes an underscore:
filetrace.network.iobecomesfiletrace_network_io. - The unit is appended:
_bytesforByand_secondsfors. A unit in braces, such as{transfer}, adds nothing. - A counter gets
_total.
process.executable.name becomes process_executable_name.
Resource attributes
Every OTLP request carries these resource attributes. On the Prometheus page they are the labels oftarget_info, a gauge whose value is always 1.
OTLP requests also name the instrumentation scope
filetrace, with the agent’s version as the scope version.
Metrics
process.cpu.time and process.memory.usage describe the agent itself. Every value is an integer except process.cpu.time, which is a floating-point number of seconds.
In OTLP, a counter is a monotonic sum with cumulative temporality whose start time is when the agent started, and the other metrics are gauges. On the Prometheus page the types are counter and gauge. Counters start at zero with the agent and never go backwards while it runs.
Metric attributes
Metric attributes are strings.[limits] metric_series (default 2048) bounds the label sets of filetrace.network.io, filetrace.file.sent and filetrace.transfers.started together. A label set beyond the limit is added to one overflow series per metric, as OpenTelemetry SDKs do. No metric has a file path or an address as an attribute.
Loss kinds
filetrace.loss.kind says where events were lost. It is an attribute of the filetrace.events.dropped metric, which has a point for each kind, and of event_loss log records.
Overhead and sizing explains how to size the queue and the tables.
Log records
Events leave as OTLP log records with:
The event types are
process_exec, process_fork, process_exit, socket_connect, socket_listen, socket_established, socket_close, file_seen, network_send, network_receive, file_transfer and event_loss; see event types.
Log record attributes
An attribute whose value is not known is left out of the record.
In the table, “Process” stands for
process_exec, process_fork and process_exit; “Socket” for socket_connect, socket_listen, socket_established and socket_close; “Network” for network_send and network_receive. Socket events carry the process attributes only when the socket has a known owner. file_seen carries no process or socket attributes, and event_loss carries only the loss attributes and filetrace.event.type.
A string that is not valid UTF-8, such as a path or a process name, is sent with ? in place of the offending bytes.