Closed Mario-Hofstaetter closed 8 months ago
Push
@breed808
I could also try asking the same question the other way around in the OTEL collector repo / slack, to see if anyone could adopt and fully integrate the windows_exporter features into the hostmetricsreceiver.
I'm also very interested about this subject. I'm a user of both windows-exporter and otel-collector-contrib, I prefer use windows-exporter instead of hostmetricsreceiver because :
But if we could integrate windows exporter as third party lib of otel collector that could be awsome... ! Windows exporter also has a lot more experience on windows metrics collect and their tradoffs.
Currently Windows seems to be the ugly duck in the OTEL collector community and is a little less supported / used. Also, when I last looked at least, some things were still ruff at the edges (hostmetricsreceiver violating prometheus metric name conventions being one of the very annoying one)
But the otel project is orders of magnitude more active and bigger than this repo here, which had phases of hardly any development and is certainly understaffed & underfunded.
Given the perspective of "one exporter to rule them all" I don't see a high probabilty of not using otelcol in the future.
Windows is the ugly duck in the DevOps world for some good reasons ^^ But that's a good reason to use existing / epproved softwares like windows-exporter instead of reinventing the wheel with hostmetricsreceiver in my opinion. Until it's in beta version the discussion is probably open...
This topic should also deserve an equivalent ticket on OtelCollectorContrib issues side.
For OTEL, this maybe is the way to go:
This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.
Dear maintainers, you may or may not be familiar with the OpenTelemetry projects and it's collector component.
It's recently picking up speed and developing fast. It's supporting many protocols / formats to read (receivers), process the data, and export to various formats (exporters). Of course it also supports receiving and exporting in prometheus format.
From our perspective as user, it would be nice to have feature parity between windows_exporter and OTEL Collector, and only use the latter from some point on. Our usecase for otelcol for METRICS is currently, on every windows machine:
Why?
OTEL Collector already supports gathering data like windows_exporter via its hostmetricsreceiver but is still lacking data and has some issues (currently not strictly following prometheus naming conventions etc.).
What I want to ask:
I do understand this project had / has a much smaller scope and is tailored to the prometheus ecosystem, but both projects are somewhat overlapping, and both are written in Golang.
Also this projects is tailored to windows systems, why OtelCol is multi-plattform, but supporting windows. It could/should also deprecate node_exporter imho.
From what the OTEL project claims or tries to do, it is the "Future of Observability" and will superseed other exporter projects and agents. As a user, it is not unwelcome to reduce the amount of different tools required to gather all telemetry data.
Example
As an example, when looking at MS SQL metrics, there is currently much less data in otelcol compared to windows_exporter: MSSQL collector vs sqlserverreceiver