Sentry Structured Logging for Cocoa (iOS)

[AbhiPrasad]

Description

https://develop.sentry.dev/sdk/telemetry/logs/

Sentry is adding support for structured logging. Let's add it to the Cocoa SDKs!

1. Define the logs protocol and log envelope item in the SDK
2. Add the Public API (SDK options and methods) as per the docs
3. Make sure the the SDK follows the documented behavior
4. Attach default attributes to the SDK as per docs
5. Instrument popular logging libraries to send logs to Sentry. SDK maintainers can best decide what they should support, but we should definitely support the same integrations that we do in the SDK today.
6. Create a GH discussion that contains instructions for setting up the SDK in your repo. Eventually this will be moved into the primary docs. See the JS SDK's GH discussion for inspiration.

[philipphofmann]

Potential candidates for logging libraries can be found here https://github.com/matteocrippa/awesome-swift?tab=readme-ov-file#logging and https://github.com/CocoaLumberjack/CocoaLumberjack is very popular.

[philprime]

Another list of potential candidates
https://swiftpackageindex.com/keywords/logging

[rapidlugo]

Just a heads up that our team is incredibly and geek-ily excited to see support for this coming up in Swift, and want to share our appreciation for the efforts. Sentry has been a keystone in our reliability story, and this is a major tool we've been looking for.

To that end, and along the lines of tooling options, I'd also like to suggest https://github.com/apple/swift-log as a source of inspiration or integration, whichever fits best =) Although I'm not a major fan of all the libraries that Apple provides, their bootstrappable system allows a lot of customization and directly supports multiple log 'handlers', multiplexing, and mediation layers that we've found quite useful.

Also, please let me know if this level of comment is not really helpful at this stage. I know it's tricky to manage publicly accessible issue reports and messaging, happy to dial back communication if it's more noisy than helpful. Cheers and thanks again!

[AbhiPrasad]

Hey @rapidlugo - thank you for your interest! We chatted about this internally, sharing one comment that we should keep in mind for the work here:

We probably need both integrations for swift-log and the standard library OSLog API. There’s an OSLog backend for swift-log but we likely need to support both separately because some projects will not use the external swift-log dependency

Also, please let me know if this level of comment is not really helpful at this stage

Comments like this help us a lot in deciding how to prioritize work, we really appreciate any kind of feedback around integrations/API in our SDKs. If there's anything else, please feel free to share. If you prefer chat, you can also reach out via Discord. We have a discord channel specifically for logs discussion.

[freak4pc]

Just a heads up that our team is incredibly and geek-ily excited to see support for this coming up in Swift, and want to share our appreciation for the efforts. Sentry has been a keystone in our reliability story, and this is a major tool we've been looking for.

To that end, and along the lines of tooling options, I'd also like to suggest https://github.com/apple/swift-log as a source of inspiration or integration, whichever fits best =) Although I'm not a major fan of all the libraries that Apple provides, their bootstrappable system allows a lot of customization and directly supports multiple log 'handlers', multiplexing, and mediation layers that we've found quite useful.

Also, please let me know if this level of comment is not really helpful at this stage. I know it's tricky to manage publicly accessible issue reports and messaging, happy to dial back communication if it's more noisy than helpful. Cheers and thanks again!

I agree with this - being able to work together with OSLog APIs will be quite important. I wouldn't mind bringing in swift-log if it makes this task easier, since writing on top of OSLog's weird APIs can be quite annoying.