Vertex

Vertex is a forking/rewrite of Vector, and it is inspired by OpenTelemetry too.

Vertex is used for collecting and processing observability data(metrics, logs and traces). it can be used to replace some part of your monitor infra, like node_exporter, fluent-bit, jaeger-agent and etc.

Component is the generic term for sources, transforms, sinks and extensions. Components ingest, transform, route events and extension Vertex. Users could compose components to craete topologies.

A source defines where Vertex should pull data from, or how it should receive data pushed to it. A topology can have any number of sources, and as they ingest data they proceed to normalize it into events. This sets the stage for easy and consistent processing of your data.

A lot prometheus exporter has already been ported.

A transform is responsible for mutating events as they are transported by Vertex. This might involve parsing, filtering, sampling or aggregating. You can have any number of transforms in your pipeline, and how they are composed is up to you.

A sink is a destination for events. Each sink's design and transmission method is dicated by the downstream service it interacts with.

An extension is

Note: Only x86_64-unknown-linux-gnu(or musl) is supported.

• Rust, to install Rust, we recommend using rustup.
• make
• protobuf
• docker
• cross

make build

build for x86_64-unknown-linux-musl

make x86_64-unknown-linux-musl

• Strip your binary, of course

strip /path/to/your/binary

• Custom your Vertex is recommended, build a lite version of vertex to collect host metrics, and export them via a HTTP server just like node_exporter.

cargo build --release --no-default-features --features=sources-node,sources-selfstat,sinks-prometheus_exporter

NOTE: If you build with x86_64-unknown-linux-musl, you should specify an allocator, cause the default one is bad at performance.

Let's see this node_exporter alternative configuration

sources:
  selfstat:
    type: selfstat
  node:
    type: node
    # default value is 15s
    # interval: 15s

transforms:
  add_hosts:
    type: relabel
    operations:
      - type: set
        key: foo
        value: bar
      - type: set
        key: host
        value: ${HOSTNAME} # environment variables
    inputs:
      - selfstat
      - node

sinks:
  prom:
    type: prometheus_exporter
    # default listent to 0.0.0.0:9100
    endpoint: 0.0.0.0:9100
    inputs:
      - add_hosts

There are some keywords

• type is used to represent component type
• inputs is an array used to build the Topology(DAG)

• Hot reload from files or HTTP endpoint
  • File watch needs inotify, so only Linux supported.
  • HTTP support get or get-and-watch style(like Kubernetes), WebSocket is not supported.

There are dozens of components, configuration could be very difficult. Therefore, a decent example could be very help, you can always run vertex sources|transforms|sinks|extensions to list available components, and vertex sources|transforms|sinks|extensions [name] to generate an example.

For example,

# List all sources
$ ./target/release/vertex sources
bind
chrony
consul
elasticsearch
exec
generate
grpc_check
haproxy
http_check
internal_logs
internal_metrics
internal_traces
jaeger
journald
kafka
kafka_metrics
kmsg
kubernetes_events
kubernetes_logs
libvirt
memcached
mysql
nginx_stub
node
ntp
nvidia_smi
prometheus_remote_write
prometheus_scrape
redis
selfstat
syslog
tail
zookeeper

$ ./target/release/vertex sources node
# The Node source generates metrics about the host system scraped
# from various sources. This is intended to be used when the collector is
# deployed as an agent, and replace `node_exporter`.

# procfs mountpoint.
#
# Optional
proc_path: "/proc"

# sysfs mountpoint.
#
# Optional
sys_path: "/sys"

# Duration between each scrape.
#
# Optional
interval: "15s"

There are more example configurations under examples/config to help you know what's Vertex capable of.

Compare to node_exporter, Vertex use less CPU and memory

But, still high performance

Binary size, no compression

By default, vertex will spawn X worker threads(the cpu core number), and spawn Y blocking threads, used for blocking operation like fs operations. X + Y + 1 is the total number of threads vertex will spawn, this value might be a little bigger than we want or needed.

For the node_exporter alternative situation, the memory usage can be under 17M by

./vertex -c dev.yaml  --threads 2 --max-blocking-threads 2

you can do it too by setting environment

VERTEX_WORKER_THREADS=2 VERTEX_MAX_BLOCKING_THREADS=2 ./vertex -c dev.yaml

Profile-Guided Optimization is a tech to collect data about the typical execution of a program and use this data to inform optimizations such as inlining, machine-code layout, register allocation, etc.

• Install cargo-pgo
• Build Vertex with cargo pgo build
• Run cargo pgo run -- -- -c config.yaml and wait for some time to collect enough information from your workload. Usually, waiting several minutes should be enough(your case can be different).
• Stop Vertex kill -s SIGTERM [pid].
• Run cargo pgo optimize to build Vertex with PGO optimization.

A more detailed guide on how to apply PGO is in the Rust documentation.