Repository: restic/restic

Issue #1804: Add support for structured logging in JSON
Created: 2018-05-23T16:29:42Z
Some users including myself have suggested adding support for structured logging in JSON for non-interactive logging. These days many tasks and applications have their logs streamed to systems like logstash, fluentd, AWS CloudWatch, Splunk, Google Stackdriver, Elastiscsearch/Kibana, Azure Logging, Datadog. Operators view, search, and monitor logs with these system, rather than looking at the text output of the individual applications.
What all these systems have in common is they all support better filtering, searching, and monitoring of log entries using JSON queries. It your logs are structured, and in JSON format, or convertible to JSON format, then your power to search and monitor applications is greatly enhanced.
Logs that aren't in JSON need to resort to regex matches or writing conversion rules/patterns to try and convert the text log lines into JSON, in order to get better filtering and matching.
This is a suggestion that restic add first-class structured log support in JSON. It would be optional, enabled with a --json option, and if so all messages would be structured JSON, including things like end of run totals.
Discussed in #1063, #1284, #1455

Duplicate issue #4947: Consider adding a slug/code/number to JSON errors
Created: 2024-07-28T00:03:57Z
Output of restic version
restic 0.16.4 compiled with go1.22.2 on linux/amd64
What should restic do differently? Which functionality do you think we should add?
When using --json, it would be nice if error messages could include a consistent-over-time indicator that consumers could key off of.
Having the error text is one thing! That's great for showing to users. But if you want to drive Restic at a policy layer, it helps to have a way to detect specific errors in a way that is resistant to string or locale changes.
I don't know the best approach to this! It's complicated. There's stuff like errno codes that could be surfaced? But then there's also custom errors that Restic generates. And a whole class of weird errors that might bubble up to Restic - how can it apply a consistent view of those to a consuming app? But I'd like it to. 😄
What are you trying to do? What problem would this solve?
I maintain a backup GUI called Deja Dup, which supports Restic. It is interested in detecting certain situations like "no space left on device" (and then offer / automatically delete snapshots to make room) or I dunno - some other sort of error in the future.
I can check the error string. But that's not as robust as I'd like. The string might change in the future. Or it might be translated based on locale.

Closing comment (2024-07-28T09:20:45Z): Related to #1804 .

And a whole class of weird errors that might bubble up to Restic - how can it apply a consistent view of those to a consuming app? But I'd like it to.

The only robust way I can think of right now, would require restic to internally annotate certain known errors with specific error codes and dumping everything else into an "unknown" category. But as errors also pass through multiple layers, this might get rather complicated. I guess we'll need a strategy how to rework the logging / error reporting before we can give this a try.