Suppress metrics error message

[carmine]

When launching a VM I got the following error message; feels like this should be suppressed.

Starting .. -[2018-11-11T17:16:14.537] [error] [metrics] Metrics error: Error transferring https://api.staging.jujucharms.com/omnibus/v4/multipass/metrics - server replied: Proxy Error - Attempting to resend

[gerboland]

Are you behind a proxy?

[Saviq]

Any case, we should probably reduce the severity of those messages to warnings.

[carmine]

Wasn't behind a proxy, but I may have experienced intermittent networking issues. The error message seemed orthogonal to what I was doing (ie launching a VM) - or at least not critical to the requested operation.

If these metrics are just nice-to-have, then a warning in a log file should suffice. If the desire to collect is stronger than that, then caching the data and sending at some other time may be appropriate.

[Saviq]

Yeah that last part definitely happens, which is why Attempting to resend - completely agree it should not be surfaced to the user at the error (or even warning?) level.

[brlin-tw]

I still see metric errors in the system journal of edge multipass:

Metrics error: Error transferring https://api.staging.jujucharms.com/omnibus/v4/multipass/metrics - server replied: Internal Server Error - Attempting to resend

It appears that multipassd is run with the --verbosity debug flag on.

[Saviq]

Yes, it is on purpose to log to journal with debug verbosity, this way we get enhanced history in case of issues.

When looking at the log, you can use the --priority switch and note the text formatting/colouring to see what messages are more important.

[brlin-tw]

When looking at the log, you can use the --priority switch and note the text formatting/colouring to see what messages are more important.

Is there any way to customize it and make the change survive after snap refresh?

[Saviq]

What change? The --priority switch to journalctl? It only affects the display, not what is actually logged. Why would you want to change that?

I noticed we don't pass $@ to multipassd in our launcher. Please file an issue about that, it would then allow you to tweak the options with systemctl edit snap.multipass.multipassd.service.