Vector puts collection, transformation, and routing in one process
Vector pipelines have three component types. Sources receive logs or metrics, transforms change or filter events, and sinks send the result onward. Each component has an ID, and sink inputs define the graph between them. The same binary can run as an agent on each host, a sidecar beside one workload, or an aggregator receiving data from other collectors. Mixed topologies let teams keep simple work near the source and centralize expensive processing or external delivery.
That consolidation is useful when an organization pays several vendors or wants the freedom to change destinations. A transform can remove sensitive fields, normalize schemas, convert logs to metrics, enrich records, sample noise, or route events by content before any billable ingestion. The tradeoff is ownership. Once Vector becomes the shared path for production telemetry, configuration review, capacity planning, buffer storage, upgrade rollout, and failure drills belong to the platform team.
VRL replaces chains of parser plugins
Vector Remap Language, or VRL, is the main tool for parsing and reshaping events. The quickstart uses one parse_syslog! call to turn a message into structured fields. The exclamation mark makes parse failure explicit. More involved pipelines can add fields, delete them, normalize types, branch on content, and emit metrics. Configuration can be validated before rollout, and tests can live with transforms so sample events exercise expected results.
VRL is also a commitment. Existing Logstash or Fluent Bit rules do not become VRL automatically, and subtle parsing differences can change labels, timestamps, or routing. A sensible migration captures representative events, including malformed and oversized records, then compares old and new outputs field by field. Start with passthrough collection before introducing cost-reduction filters. Dropping data early saves money only when operators can prove that the discarded events are not needed during an incident.
What happened when we ran it
Our Rust sandbox installed 1,311 packages in 86 seconds at commit e778b21. The build did not complete before the 900-second limit. The checkout contained 13,463 files, roughly 424,411 lines of source, and 53.8 MB. The environment had 3 CPUs and 12 GB of RAM. This result says source compilation is expensive on a modest machine; it is not a throughput measurement for the packaged Vector binary.
The test command ran for 708 seconds and failed with exit code 101. The supplied tail showed a truncated Rust compiler command followed by warning: build failed, waiting for other jobs to finish. It did not include the original diagnostic or a test summary, so there is no honest passed or failed test count to report. We cannot identify the crate, compiler error, or environmental requirement from that tail alone.
Our scan found 46 CI workflow files and a tests directory, but no Dockerfile. The project publishes container images and several package formats despite that repository signal. We did not start a source, send events through a sink, fill a disk buffer, measure memory, or compare throughput. The README's performance table comes from Vector's separate harness and is not a result from our run. Adoption should use a replay of the buyer's own telemetry, destinations, and transformations.
Delivery depends on component support and buffer settings
Vector supports end-to-end acknowledgements for many, not all, sources and sinks. With acknowledgements enabled, a compatible source waits until every connected sink reports delivery or persists the event to a durable buffer. If a sink lacks acknowledgement support, Vector considers the event delivered when it hands the event to that component, before the destination accepts it. Operators must inspect the guarantee badge for every source-to-sink route rather than applying one claim to the whole topology.
At-least-once delivery across restarts requires disk buffers on the sink. Such delivery can produce duplicates, and the documentation explicitly says exactly-once is unavailable. Best-effort components may lose data because of their underlying protocol and can still duplicate events in extreme cases. These distinctions matter when logs feed billing, security actions, or business processes. Diagnostic logs may tolerate occasional loss; an audit stream often needs a different path or stronger downstream deduplication.
Logs and metrics are current, traces are not
The README describes logs as supported and metrics as beta, while traces remain listed as coming soon. That makes Vector a poor sole collector for a team standardizing now on all three OpenTelemetry signals. OpenTelemetry Collector Contrib is the more direct choice when trace receivers, processors, and exporters are required. Vector can still sit in the log path beside an OpenTelemetry trace pipeline, but running both removes some of the consolidation benefit.
Component stability labels need equal attention. Stable means the Vector team believes the interface has had community use and no major open bugs; beta and alpha features carry less confidence. A production design should inventory every source, transform, and sink with its stability and delivery status. One alpha component inside an otherwise stable route can define the practical risk of the whole chain.
Version 0.58.0 is current and actively maintained
Vector v0.58.0 was published on August 26, 2026, the same date as the last recorded push. GitHub showed 22,458 stars and 2,530 open issues and pull requests. The project is maintained by Datadog's Community Open Source Engineering team and uses the Mozilla Public License 2.0. Nightly, integration, end-to-end, and component-feature workflows are visible from the repository, though our selected build and test commands did not finish cleanly.
Vector is worth adopting when observability data needs serious processing before it reaches storage. Its agent and aggregator roles, VRL, disk buffers, acknowledgement model, and destination range form a coherent system for logs and metrics. The 900-second build timeout and 708-second test failure make source contribution unattractive on a small machine, so most teams should begin with the signed package or published image. Prove loss and duplicate behavior under sink failure before replacing an existing collector.