Background
Last year I introduced a completely new and custom logging based on JSON log lines. The previous implementation was rudimentary and the reliance on the Apple unified logging system made our work much more difficult than necessary, especially in regards to information retrieval from customers in scope of support requests.
Problem
By now, it is time for the next big step to improve our processes and support. We always receive a lot of information in form of these logs but the sheer amount of messages and the concurrency of their generating processes makes it hard to work with and reason about them.
Goal
I wrote a generic logging package for Swift with our file provider extension in mind to resolve the remaining issues and enable tooling for much more convenient and efficient log analysis.
https://github.com/i2h3/rivers
That logging system is ought to replace the current existing implementation. See there for further information why it is an advancement on several sides. Mosts importantly, it introduces request-based logging, considering the file provider extension like a service, so all messages are always contextualized. Also, it enables tooling like the viewer app I am working on in parallel:
https://github.com/i2h3/riverview
Technical Details
- The whole "Log" source code folder in NextcloudFileProviderKit will be deleted.
- A
FileProviderRequestContext type must be declared and include a logger property.
- The
FileProviderExtension maintains the root logging message from which activities are branched off and passed down the call stack on every call from the system.
Background
Last year I introduced a completely new and custom logging based on JSON log lines. The previous implementation was rudimentary and the reliance on the Apple unified logging system made our work much more difficult than necessary, especially in regards to information retrieval from customers in scope of support requests.
Problem
By now, it is time for the next big step to improve our processes and support. We always receive a lot of information in form of these logs but the sheer amount of messages and the concurrency of their generating processes makes it hard to work with and reason about them.
Goal
I wrote a generic logging package for Swift with our file provider extension in mind to resolve the remaining issues and enable tooling for much more convenient and efficient log analysis.
https://github.com/i2h3/rivers
That logging system is ought to replace the current existing implementation. See there for further information why it is an advancement on several sides. Mosts importantly, it introduces request-based logging, considering the file provider extension like a service, so all messages are always contextualized. Also, it enables tooling like the viewer app I am working on in parallel:
https://github.com/i2h3/riverview
Technical Details
FileProviderRequestContexttype must be declared and include aloggerproperty.FileProviderExtensionmaintains the root logging message from which activities are branched off and passed down the call stack on every call from the system.