feature/metrics-naming

[loelkes]

As discussed in #33

I'll follow up with some more refactoring and do some tests.

[tg44]

LGTM!

[loelkes]

This is a breaking change, so I recommend releasing a new major version.

[tg44]

Can you rebase this? There was two not so big changes that I merged today, and this branch was already conflicting.

[loelkes]

Done.

I would like to discuss the timer reset after printing. In my opinion it should be removed.

• It depends on your scrape interval.
• Why reset the values at all? If something has been printed, cancelled, etc. the progress remains unchanged unless someone touches it.

This could also be achieved with G4 and G92 commands at the end/beginning of the print, with a dwell time to match your scrape interval. Right now there's no way to opt out of this. If you agree, I would open a new feature branch for this (including documentation).

[hyperair]

I was playing with my Grafana dashbaord recently and found it quite annoying when the print progress didn't get reset properly -- it led to a ballooning of metrics, and was quite cumbersome to implement a simple ETA or Print time left gauge widget because now I had to filter out all the time series that weren't current. Clearing the print progress metrics at the end of each print ensures that there's just one relevant time series running at a time, which results in graphs like so:

The top graph has a properly reset metric, but the bottom graph, due to a bug fixed in #41, didn't get reset properly between the orange and yellow lines, causing them to overlap. This Octoprint session only had a single digit number of prints running, but it accumulates lines and ends up with an increasingly noisy graph unless you add special field overrides in the Grafana widget to filter out irrelevant series.

[tg44]

We need to reset the timers bcs they are starting to overlap if your instance is not reseting. In my opinion, we want to measure a print. A print starts when the label first appear, this is logical, we can't measure a print job that was never created/started in octoprint. But on the other hand we will finish a job at some point in time, so we need to "clear" that job when octoprint success/fail it.

When you have a single printer setup, it is logical that only one line is on the ETA, or the print progress graph. If you have lets say 5 printers, you want to see at most 5 lines on the graph at a time. If we do not reset the progress, than in a single printer setup, you will have N lines where N is the number of jobs ever started on that octoprint instance from its last restart.

It depends on your scrape interval. Yes, if we would have a settings page, probably the "reset interval" should go there...