Skip to main content
Edge Infrastructure Services exposes device and application metrics through two independent telemetry sources. Each source uses a different transport, covers a different scope, and requires different configuration to consume. Use this reference to plan your observability pipeline and to know exactly which metric names to expect in your collector or dashboard. Edge Infrastructure Services pushes device and application metrics to your collector using OpenTelemetry Protocol (OTLP) over gRPC. You can also scrape EVE-OS (Edge Virtualization Engine) host metrics directly using Prometheus.

​
EVE-OS Host Collector

EVE-OS runs a node_exporter process on every edge node. You can scrape it from any application instance running on a local network instance. Requires EVE-OS 16.0.0 or later. EVE-OS 16.0 introduced the node_exporter package and the rate-limit properties that govern this endpoint. Releases before 16.0 do not expose it, so plan for a fallback on any fleet that still runs 14.x. Endpoint: GET http://169.254.169.254/metrics Rate limit (defaults): 1 request per second, burst 10, per source IP address. The limiter state for an address resets after 4 minutes of inactivity. EVE-OS rejects requests that exceed the limit with 429 Too Many Requests. All three values are tunable through EVE-OS configuration properties: msrv.prometheus.metrics.rps, msrv.prometheus.metrics.burst, and msrv.prometheus.metrics.idletimeout.seconds. Scope: These are host-level metrics for the entire edge node. No metric is attributed to a specific application instance (with one partial exception described in Per-interface metrics). Expected volume: Roughly 2,500 metric series per scrape on a node with a ZFS persist vault, and about 390 fewer on a node using the default ext4 backend, where the zfs collector produces no series. Treat this as an order of magnitude rather than a fixed figure. The total scales with CPU core count, network interface count, mount points, block devices, and ZFS pools and datasets, so it differs from one hardware model to another. Measure a representative node before you size collector or time-series database capacity.
Version provenance. The collector inventory and series counts in this section describe node_exporter v1.9.1, the version EVE-OS pins in releases 16.0.0 through 17.3.0. EVE-OS runs it with these flags:
No collectors are disabled. The enabled set is therefore the node_exporter default set for Linux (46 collectors) plus cgroups and processes, which is 48 in total. If a later EVE-OS release pins a different node_exporter version, the metric families and counts that follow can change.

​
Collectors that are always present

The following collectors are always active and produce output on every scrape. Counts expressed per core, per interface, per device, or per mount point scale with the hardware. The exporter reads the meminfo and netstat totals from /proc, so they depend on kernel version and build options. Treat both as observed values from a representative node rather than guarantees.

​
netstat series

The netstat collector emits 42 host-wide counters. All are prefixed node_netstat_, carry no labels, and are untyped. Icmp_InErrors, Icmp6_InErrors, Tcp_InErrs, Udp_InErrors, Udp6_InErrors, UdpLite_InErrors, UdpLite6_InErrors, Ip_Forwarding, Ip6_InOctets, Ip6_OutOctets, IpExt_InOctets, IpExt_OutOctets, Icmp_InMsgs, Icmp_OutMsgs, Icmp6_InMsgs, Icmp6_OutMsgs, TcpExt_ListenOverflows, TcpExt_ListenDrops, TcpExt_SyncookiesSent, TcpExt_SyncookiesRecv, TcpExt_SyncookiesFailed, TcpExt_TCPTimeouts, TcpExt_TCPOFOQueue, TcpExt_TCPRcvQDrop, TcpExt_TCPSynRetrans, Tcp_ActiveOpens, Tcp_PassiveOpens, Tcp_CurrEstab, Tcp_InSegs, Tcp_OutSegs, Tcp_RetransSegs, Tcp_OutRsts, Udp_InDatagrams, Udp_OutDatagrams, Udp_NoPorts, Udp_RcvbufErrors, Udp_SndbufErrors, Udp6_InDatagrams, Udp6_OutDatagrams, Udp6_NoPorts, Udp6_RcvbufErrors, Udp6_SndbufErrors

​
cgroups and processes collectors

Important: Despite their names, neither collector provides per-application data. The cgroups collector reads /proc/cgroups (a fixed kernel table) and emits only two series per controller: subsys_name is a controller name such as cpu, memory, or pids. The collector does not walk /sys/fs/cgroup and does not enumerate per-workload cgroups. The processes collector emits six aggregates with no per-process identity. Because the exporter runs in the host PID namespace, counts span every process on the node including workload VMs, but none are attributable to a specific application.

​
Per-interface metrics

Both network collectors are unfiltered, so every interface in the EVE-OS host namespace appears, including bridges and each application’s tap interface. netdev (17 counters, label device): node_network_receive_bytes_total, _receive_packets_total, _receive_errs_total, _receive_drop_total, _receive_fifo_total, _receive_frame_total, _receive_multicast_total, _receive_compressed_total, _receive_nohandler_total, node_network_transmit_bytes_total, _transmit_packets_total, _transmit_errs_total, _transmit_drop_total, _transmit_fifo_total, _transmit_colls_total, _transmit_carrier_total, _transmit_compressed_total netclass (19 gauges, label device): node_network_up, node_network_info{address, broadcast, duplex, operstate, adminstate, ifalias}, _address_assign_type, _carrier, _carrier_changes_total, _carrier_up_changes_total, _carrier_down_changes_total, _device_id, _dormant, _flags, _iface_id, _iface_link, _iface_link_mode, _mtu_bytes, _name_assign_type, _net_dev_group, _speed_bytes, _transmit_queue_length, _protocol_type Note about application interface names: Application tap interfaces follow the pattern nbu<adapter>x<app>, where both numbers are ordinal indices, not stable identifiers. When you delete an application, EVE-OS releases its ordinal and reassigns it to the next free slot. A given interface name can therefore map to a different workload after any delete and recreate cycle. Do not use the interface name alone as a long-lived key in your time-series database. Resolve the interface to an application UUID out of band and re-resolve it after lifecycle events.

​
ZFS metrics

ZFS support in EVE-OS is optional and experimental. The default installation uses ext4 on a single disk. You select ZFS at install time (or imply it by configuring multiple persist disks). A node backed by a ZFS persist vault exposes approximately 390 ZFS series. On a node using the default ext4 backend, the zfs collector produces no series and none of the following families appear. Do not assume these metrics exist without confirming the storage configuration of the node. All are untyped and unlabeled unless noted.

​
Hardware- and configuration-dependent collectors

Some collectors produce output only on specific hardware or in specific storage configurations. Every enabled collector contributes two scrape-meta series even when it emits no metrics of its own, including zfs on an ext4 node: node_scrape_collector_duration_seconds and node_scrape_collector_success. That means 96 scrape-meta series are always present. The exporter also exposes approximately 46 series about itself (go_*, process_*, promhttp_*, node_exporter_build_info).

​
Hardware identifier disclosure

Two metric families carry hardware serial numbers and are accessible to any application instance on a local network instance over unauthenticated HTTP:
  • node_dmi_info: board, chassis, and product serial numbers, plus the SMBIOS UUID.
  • node_nvme_info: the SSD serial number, model, and firmware revision.
This is by design, but review which workloads have access to a local network instance before deploying in environments where hardware identity must be restricted.

​
Edge Infrastructure Services OTLP Export

Edge Infrastructure Services pushes 54 metrics to your configured OpenTelemetry collector over OTLP/gRPC. See Configure the OpenTelemetry Integration for setup instructions. Edge Infrastructure Services emits every metric as an OTLP Gauge, including values that represent cumulative counters. Your collector or query layer must handle rate calculation and reset detection. Attributes on every data point: deviceId, projectId, enterpriseId, projectName, enterpriseName. Application-level metrics additionally include appInstId.

​
Device-level metrics (33)

The network metrics (device_net_*) carry an if_name label and multiply by the number of device network ports. The device_zedcloud_* metrics carry if_name and represent per-management-port connectivity to Edge Infrastructure Services. The device_zvol_* metrics carry volume_uuid and multiply by the number of ZFS zvols.

​
Application-instance-level metrics (21)

Edge Infrastructure Services emits these metrics per application instance (label: appInstId). Network metrics further multiply by the number of application vNICs (label: if_name).
† Set the unit explicitly for these four metrics. The values are byte counts, as listed in the previous table. The unit field on the app_inst_memory_used, app_inst_memory_allocated, app_inst_disk_used, and app_inst_disk_allocated data points does not currently carry bytes. A collector or dashboard that derives axis labels or unit conversions from that field will scale these four metrics incorrectly. Configure the unit for them in your pipeline instead of inheriting it. The device-level equivalents, device_memory_* and device_disk_*, carry bytes as expected.

​
What the Edge Infrastructure Services OTLP export does not include

The OTLP export does not carry the following metrics, even though edge nodes report them to Edge Infrastructure Services:
  • Cellular metrics (RSSI, RSRQ, RSRP, SNR, and modem packet counters). Edge nodes report these, and they are visible in the Edge Infrastructure Services web console and REST API, but Edge Infrastructure Services does not forward them to your OTLP endpoint.
  • 802.1X and EAPOL counters. Edge nodes likewise report these, and they are available through the web console and REST API only.
  • Per-network-instance metrics, per-volume-instance metrics, per-process metrics, Kubernetes cluster metrics, and container-level metrics from inside an application.
  • Bonded-interface (LAG) metrics, flow-log and ACL aggregate metrics.
Per-volume-instance metrics in the preceding list are a different thing from the ZFS zvol bandwidth metrics in the device table (device_zvol_read_bandwidth and device_zvol_write_bandwidth), which are exported. The zvol metrics report I/O on ZFS volumes and carry a volume_uuid label; the volume-instance metrics that the export omits are the volume-instance objects that Edge Infrastructure Services manages.

​
Emission conditions

  • The export omits the application block entirely if the application instance ID is empty.
  • ZFS families are absent on edge nodes that do not use ZFS storage.
  • When EVE-OS matches no /persist partition, the export reports disk metrics as zero rather than omitting them.
  • A project-level setting can suppress metric transmission for all edge nodes in that project. See Control Metric Streaming at the Project Level.

​
Next Steps

Configure the OpenTelemetry Integration

Set up an OTLP collector endpoint and create data streams to receive Edge Infrastructure Services metrics.

Configure the Splunk Integration

Forward platform data to Splunk instead of or in addition to an OTLP collector.

Integrations and Automation

An overview of all integration paths available in Edge Infrastructure Services.