Allow logging to local file

[breed808]

Resolves #979

[breed808]

That's a good point, I'll update the docs too :+1:

[Mario-Hofstaetter]

This is a nice feature to have, not everybody is comfortable having apps writing to event application log by default.

@carlpett

We should probably explicitly mention that we dont't do log rotation and leave that responsibility of the user

Question: How does the user handle file rotation on windows then?

This is a big pain with many tools (especially ones coming from the linux world, for example https://github.com/traefik/traefik has no log rotation on windows despite having over 9000 features, because windows is the ugly duck). But this is after after all a windows_exporter.

We are in the process of converting several tools to use https://github.com/winsw/winsw because it supports log rotation (and file logging) by using stdout / stderr of the process. windows_exporter was next in line because of #979 (I created a custom MSI installer for our needs)

@breed808 : With file logging, is it possible to use a relative file path for the log file?

This is the next pain on windows, the working directory of services is C:\Windows\system32, so log files using a relative path are create there (doh!). This drove me insane when setting up https://github.com/open-telemetry/opentelemetry-collector and was another reason that drove us to winsw service wrapper, because then the working directory of the child processes is their actual location.

[carlpett]

Question: How does the user handle file rotation on windows then?

@Mario-Hofstaetter Well, everyone has their own favorite :) One of the reasons not to try to do it is that everyone wants it done slightly differently, and then you end up having to support dozens of different configurations for rotation, which isn't really a core feature of the exporter itself.

If you want to log to disk, you most likely have some sort of log collector for centralized logging? Those tools commonly have rotation features (and sometimes Event Log integrations directly, which would be the suggested solution in that case!). Otherwise there are a couple of Windows ports of logrotate, as well as samples for doing stuff with scripts in scheduled tasks. I'm aware that none of those are ideal, but I'm skeptical that we'd want to take on the complexity inside the exporter.

Regarding relative paths and working directory, I hadn't thought about that (since we mostly didn't do anything file related). Wouldn't be a bad idea to start the program with setting it to the directory of itself, would you be open to do a PR on that?

[Mario-Hofstaetter]

would you be open to do a PR on that?

I'd be open for it, unfortunately I am no go dev, so I am unable to contribute until I start learning go I'm afraid.

I'm aware that none of those are ideal, but I'm skeptical that we'd want to take on the complexity inside the exporter.

My perspective as a naive user is: Even theoretically filling the harddisk with logs (been through that several times), or getting a logfile so huge no editor is able to open it, is not acceptable for any app on production.

Not wanting additional complexity in this project is a fair point. Many other programs follow the philosophy to log to stdout and not care more. However with Windows Services this is also impossible because console output redirection is not a thing afaik.

Using something like logrotate is not common practise on windows (?), also using some unofficial windows port which is not maintained (https://sourceforge.net/projects/logrotatewin/ for example?) is also no option, outside of maybe a home lab.

So basically there is only one option left: Use NSSM or winsw (or any other that provides logrotation and other features) as a service-wrapper around windows_exporter, instead of running it as service itself.

But it seems so far this was a non-issue to the community, so maybe I have too high expectations.

[mansikulkarni96]

Any update on this? It would be nice to have this feature with documentation on how to use it.