Add new sink component for Sentry (sentry.io)

[AbhiPrasad]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

Hey, I work at Sentry. Sentry now supports sending logs.

We at Sentry would love to contribute a Sentry sink to Vector so that users can send their logs via Vector to Sentry. I'd be happy to implement this, and the Sentry team would by happy to own it.

Attempted Solutions

Functionally the sentry logs schema is a superset of the OpenTelemetry one, so the transform should be fairly simple (just have to route it to Sentry ingestion).

Sentry also supports traces, but we can add that as a follow-up due to the alpha nature of tracing in Vector.

Proposal

The component will be stateless. The component needs state to maintain rate limiting information. See Sentry docs here

The API should look something like so:

sinks:
  my_sink_id:
    type: sentry
    inputs:
      - my-source-or-transform-id
    dsn: ${SENTRY_DSN}

The dsn (Data Source Name) references the which org/project should receive the logs in Sentry.

The only unknown in the implementation is dealing with rate limiting. Sentry has a detailed spec on how clients should respond to being rate limited by Sentry (see docs here), and I'm not sure the finely-grained category based rate-limiting will work with Vector. Suggestions are welcome! Was tested, should be fine.

Sentry can be run self-hosted (and is available on GitHub completely source available: github.com/getsentry/sentry) so adding more complicated integration or e2e tests should not be too complex.

References

Issue tracking in Sentry repo: getsentry/sentry#92400

Version

No response

[pront]

Hi @AbhiPrasad, thank you for creating this.

We at Sentry would love to contribute a Sentry sink to Vector so that users can send their logs via Vector to Sentry. I'd be happy to implement this, and the Sentry team would by happy to own it.

We would be happy to review a PR. Also, happy to hear the component will be stateless (reduces complexity). Let me know if you have any further questions.

[AbhiPrasad]

I started to take a look at this, and I unfortunately I don't think we can keep it stateless because the sink will need to keep track of rate limiting information (this should be abstracted behind a transport in in the Sentry Rust SDK: https://github.com/getsentry/sentry-rust/tree/master/sentry/src/transports)

Otherwise it should be fire and forget, we do not keep any state around the log items themselves, only the response to requests to Sentry.