getsentry
Allow relay through SNS and/or EventBridge and/or SQS
Problem Statement
I'm using Sentry to instrument AWS Lambda functions that run inside a private VPC and therefore don't have a route to the Internet. I'd like to be able to relay Sentry traces and errors either through SNS or EventBridge or SQS. The SNS topic or the EventBridge event bus or the SQS queue would serve as a buffer that accepts messages from the private VPC and would allow a different process, one with access to the public internet, to pick up those messages and forward them to sentry.io.
Solution Brainstorm
- Allow the Sentry SDK to forward errors/traces to an AWS SNS topic instead of to sentry.io
- Allow the Sentry SDK to forward errors/traces to EventBridge (or CloudWatch Events) instead of to sentry.io
- Allow the Sentry SDK to forward errors/traces to an AWS SQS queue
- Find other ways to relay messages from a private VPC to the public Internet without requiring me to stand up an always-on event listener that is connected to both the private VPC and to the public internet.
Sentry Relay won't work for this, I think, because Relay would have to be in the same VPC as the lambda function in order for traces/errors to be sent to the relay, which would then leave me with the same problem: relay would be in a private VPC with no connection to the internet through which to send messages to sentry.io.
ok @matthewmucker-vizio so if you want an immediate usable solution for this, I'd suggest you write a custom transport. A minimal skeleton would look like the following.
import boto3
from sentry_sdk.transport import Transport
class SqsTransport(Transport):
def __init__(self):
self.sqs_client = boto3.client("sqs")
url = sqs_client.get_queue_url(QueueName="my-new-queue")
self.queue_url = url["QueueUrl"]
def capture_event(self, event):
self.sqs_client.send_message(self.queue_url, json.dumps(event))
def capture_envelope(self, envelope):
self.sqs_client.send_message(self.queue_url, envelope.serialize())
sentry_sdk.init(transport=SqsTransport)
Caveats here are that this won't have much of the logic from our normal HTTP transport, namely
- rate limiting (this will have to be handled on the other side, i.e. whatever pulls from your SQS queue and does the actual sending to Sentry)
- client reports (statistics for dropped events / reasons)
- background worker (though this is unnecessary in an AWS lambda setting)
For the longer term, we can see about adding SQS support properly into the SDK. (cc @smeubank) But I don't know how we can standardize the other side that pulls from SQS and forwards to Sentry, that will still be a very user-specific implementation that you will have to roll yourself either way.
Just out of curiosity:
Is it possible to use open telemetry [1] for this? If Sentry could send trace data in an open telemetry compatible format to an open telemetry collector could this collector then send the trace data to SNS/SQS/EventBridge/whatever?
Do you know more about this @matthewmucker-vizio
1: https://opentelemetry.io/
@antonpirker, I'm afraid I'm the wrong guy to ask. It does seem that there would be some low-friction places where Sentry and OpenTelemetry could integrate, but I lack the background to provide any value to the discussion.
Ok, thanks @matthewmucker-vizio. So we forget about otel for the time being. ;-)
One thing about proper SNS/SQS/EventBridge support. One can probably set meta information for events send through those services, so we maybe can set/grab Sentrys trace ID when using those services so Sentry can stitch together everything in one big trace.
As a workaround with a custom transport was suggested we will close this issue.