Add support for serving files (or named pipes)

[ebikt]

Serve contents of static file (or named pipe).

Static file serving can be used for client-side managed alert thresholds (just pushed as another metric) or as alternative to pushgateway, where client script writes metrics to file instead of pushing them to some service outside.

Rationale: We use exporter-exporter as (authenticating) proxy when monitoring physical servers. We do not want to run pushgateway on localhost just for storing results of cron scripts. We also want to configure some alert thresholds on client side, without touching configuration of monitoring servers. Serving static files seems as easiest and most elegant solution to our problem.

[britcey]

When would you use this vs. the textfile collector for node_exporter and windows_exporter?

[ebikt]

We want these files to be scraped independently of scraping node exporter, mainly for purposes where we want different scraping interval. So our intended usage can be achieved by running separate instance of node exporter for each scraped file. That seems superfluous to us.

[tcolgate]

There are a few more bits to fix, but I'll merge this and make the changes. Thanks for the contribution!

[tcolgate]

As a heads up:

• I've dropped the use of option to use the mtime as the metric time stamps. That will have extremely odd effects that I don't want to have to support (after a while, prom will just ignore the metrics).
• I dropped IsGlob, since it wasn't used. It could be though, and would be a reasonably follow-up PR.
• I dropped the default 5 minute timeout.
• The metrics at the top were copied from Exec, but you forgot to rename the actual metric. Also, one of them wasn't used at all.

[ebikt]

Setting timestam of measurement is IMHO the thing that also pushgateway does. And exporter_exporter also passes time of measurement if passed on measurement line. It has same caveats as using pushgateway. My goal was to let operator choose what is correct time associated with the values - in some cases it should be time of measurement (i.e. mtime of the file) and in other it should be the time of collection. Using mtime of file was only shortcut, so that processes that writes metric file to disk do not need to do this explicitely.

[tcolgate]

For the push gateway it makes more sense, as it allows you to time align a bunch of things you are pushing to the same timestamp. expexp will pass on the timestamp if it is set, and I don't think that is particularly surprising. For the file case, if the user wants and explicit timestamp, they can write it when the write the metrics, or they can use the more usual default of the time of the scrape. The option of using the file mtime as a force scrape timestamp feels to me like something that might sound attractive to a user that doesn't understand metric scrape timestamps, but that is completely unnecessary to a user that does.