I’ve used this before, to great success. Nice and straightforward to configure, the vrl language is just powerful enough for its needs, the cli’s handy “check” feature helps you catch a bunch of config issues. Performance wise it’s never missed a beat and it’s resource efficient, strongly recommend.
We had to push metrics we scrape via Prometheus into DataDog (coincidence that they acquired this) and do a custom transform to map to a set of custom metrics.
Very straightforward in how it runs and the helm chart had all the right things in there
Otel support in Vector is an often requested feature. Across multiple threads. There seems to be good noises & some occasional we'll get to it, but so far there's just otel log ingest support, which has been there for a while now. https://github.com/vectordotdev/vector/issues/17307
I'm excited for these front-end telemetry routers to keep going. Really hoping Vector can co-evolve with and grow with the rest of the telemetry ecosystem. Otel itself has really started in on the next front with OpAMP, Open Agent Management Protocol, to allow online reconfiguration. I'd love to know more about Vector's online management... quick scan seems to say it's rewriting your JSON config & doing a SIGHUP. https://opentelemetry.io/docs/specs/opamp/
Vectors configurability & fast-and-slim promise looks amazing. Everyone would be so much better off if it can grow to interop well with otel. Really hoping here.
In a sense, OTel is a big threat to Datadog, so I can imagine slow-rolling support is one way to manage that without looking actively hostile to it, similarly to how Datadog has other OTel "support" that doesn't play nicely with a lot of their more valuable tools/features.
Datadog has had a number of "come to jesus" moments in the past couple years where they've had to embrace OTel, but yeah, I indeed confess to a inner fear telling me that the Vector acquisition is to prevent tech as much as it is to develop it.
I’m personally still waiting for Otel stuff to just…evolve a bit more? There’s some sharp edges, and a bunch of “bits” in that ecosystem that aren’t clear how we’re supposed to hold them and things don’t _quite_ work well enough yet.
Don’t get me wrong, I want to use OTEL, but it’s a struggle. In the meantime, I’ve still got normal apps and libraries outputting normal logs and normal prom metrics, so I’ve got to stick with that.
What aspects were you missing from OTEL? We swapped the agent side out from New Relic to OTEL in NodeJS, .NET and Python - I’ve not found any major missing feature?
Or are you thinking more on the UI/analysis/collection side?
Oh you need a collector? But maybe you don’t - because some libs will push it? Ok so we got that setup, but now half the traces don’t turn up? Or they do, but they’re missing the ids to link them together? I’ve got 30m traces from an AWS lib we use, but none of ours? Oh also our logs don’t come across? Because logs require some different handling or something and some intermediary didn’t support them yet? Grafana seemed to support some things, and not others. To say nothing of the absolute plethora of config options available on the collectors and exporters: there’s like 3 or 4 different ways to define sampling and filtering, in a different layer each and they all appear to cross interact, so you can accidentally choose configs that prevent you from getting data with no indication of where it’s gone missing.
I’m keen for it to all shake down a little bit, because I’d love to be able to just bang #[instrument] on all our functions, and derive logs and metric from trace data, but seems things are a while off that yet.
