Usage report opt-out and lower usage report verbosity.

[aureq]

Is your feature request related to a problem? Please describe.

Following #5062, Loki is now phoning home and sending stats. However, looking at #5361, I haven't found a way to opt-out or disable such reporting, nor I have found a documentation explaining what is currently being sent.

For now, I'm DNS blocking stats.grafana.org as a way to opt-out, but this has the side effect of generating a lot of unnecessary logs every minute:

2022-04-26T03:09:37.647023649Z stderr F level=info ts=2022-04-26T03:09:37.646915508Z caller=reporter.go:299 msg="failed to send usage report" retries=0 err="Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"
2022-04-26T03:09:39.152524999Z stderr F level=info ts=2022-04-26T03:09:39.152359372Z caller=reporter.go:299 msg="failed to send usage report" retries=1 err="Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"
2022-04-26T03:09:42.338765883Z stderr F level=info ts=2022-04-26T03:09:42.338598592Z caller=reporter.go:299 msg="failed to send usage report" retries=2 err="Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"
2022-04-26T03:09:46.957093238Z stderr F level=info ts=2022-04-26T03:09:46.956929353Z caller=reporter.go:299 msg="failed to send usage report" retries=3 err="Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"
2022-04-26T03:09:55.931536437Z stderr F level=info ts=2022-04-26T03:09:55.93134964Z caller=reporter.go:299 msg="failed to send usage report" retries=4 err="Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"
2022-04-26T03:09:55.931602771Z stderr F level=info ts=2022-04-26T03:09:55.931426102Z caller=reporter.go:278 msg="failed to report usage" err="5 errors: Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused; Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused; Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused; Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused; Post \"https://stats.grafana.org/loki-usage-report\": dial tcp 0.0.0.0:443: connect: connection refused"

Describe the solution you'd like Here is a few ideas in order of preference:

• Have a clear opt-out option available, included in the Helm Chart deployment
• Have a configurable back-off period
• Have a "giving up after X attempts" option where stats aren't sent at all if failure is repeated after X attempts

Additionally, I think the Loki users should be explained what is collected and how the data is used and/or (not) shared.

Describe alternatives you've considered So far, DNS blocking seems the be a good choice compared to a firewall approach that would drop the outbound traffic. Dropping outbound traffic may lead to sockets staying in SYN_SENT state until a timeout is reached, which may consumed too much resources over time.

I didn't find a solution to limit the error messages in the logs though.

Additional context n/a

[alanhe]

I find how to disable it by setting analytics.reporting_enabled: false, https://grafana.com/docs/loki/latest/configuration/#analytics

I missed the config in the initial setup.

It's in release note: https://github.com/grafana/loki/pull/5865/files I think it need to be highlighted it in the installation guide too, https://grafana.com/docs/loki/latest/installation/

[stale[bot]]

Hi! This issue has been automatically marked as stale because it has not had any activity in the past 30 days.

We use a stalebot among other tools to help manage the state of issues in this project. A stalebot can be very useful in closing issues in a number of cases; the most common is closing issues or PRs where the original reporter has not responded.

Stalebots are also emotionless and cruel and can close issues which are still very relevant.

If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.

We regularly sort for closed issues which have a stale label sorted by thumbs up.

We may also:

• Mark issues as revivable if we think it's a valid issue but isn't something we are likely to prioritize in the future (the issue will still remain closed).
• Add a keepalive label to silence the stalebot if the issue is very common/popular/important.

We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task, our sincere apologies if you find yourself at the mercy of the stalebot.

[icc-garciaju]

Thanks for the tip @alanhe. I think european regulations require explicit consent for reporting back application usage, so it must be cristal clear in the documentation.