Support for debug outgoing request from sentry sdk

[illambo]

Hi everyone, I would need help for debug outgoing calls from the sdk.
In fact, for a project I find myself behind a boring firewall and the calls do not appear to arrive to sentry dns.
Does anyone have a small example of how to trace outgoing calls?
Seems the sentry sdk has something related the ability to inject custom http transport but it is complicated for me.

I thought I'd inject something like this:

$stack = \GuzzleHttp\HandlerStack::create();
        $stack->push(
            \GuzzleHttp\Middleware::log(
                with(new \Monolog\Logger('guzzle-log'))->pushHandler(
                    new \Monolog\Handler\StreamHandler(storage_path('logs/guzzle-log.log'))
                ),
                new \GuzzleHttp\MessageFormatter(\GuzzleHttp\MessageFormatter::DEBUG)
            )
 );
$clientHttp = new \GuzzleHttp\Client(['handler' => $stack]);

Do you have any suggestions or better solutions for me?
Thanks

[stayallive]

Hey @illambo, we have the option to attach a logger to the SDK.

We do this ourself in the php artisan sentry:test command:

sentry-laravel/src/Sentry/Laravel/Console/TestCommand.php

Lines 102 to 117 in 041a9df

	// We set a logger so we can surface errors thrown internally by the SDK
	$clientBuilder->setLogger(new class($this) extends AbstractLogger {
	private $command;
	public function __construct(TestCommand $command)
	{
	$this->command = $command;
	}
	public function log($level, $message, array $context = []): void
	{
	if ($level === 'error') {
	$this->command->logMessageFromSDK($message);
	}
	}
	});

.

Maybe running the sentry:test command is enough to surface specific errors so you can debug further.

[illambo]

Unfortunately I cannot access the application instances console if I try to command from a test controller

Artisan::call('sentry:test')

raises the exception "The command "sentry:test" does not exist." (why?)
Also it would be convenient for me to trace the actual outgoing call so that I can understand the possible endpoint that is not enabled on the firewall.
I try to inspect the command he suggested to me, maybe it gives me some ideas.
Thanks.

[stayallive]

I think we only register the command when running in CLI mode.

They best option is then to do register a custom transport but that is quite involved.

But, it's pretty easy to figure out where it's talking to :)

Your DSN looks something like: https://<secret>@o12345.ingest.sentry.io/12345 (but the numbers will be different in your case of course).

The SDK will connect to o12345.ingest.sentry.io on port 443 for the example above.

Does that help already or should we try and cook up a custom transport?

There is also an option to set a HTTP proxy: https://docs.sentry.io/platforms/php/configuration/options/#http-proxy

[illambo]

Thank you, for now I just need your confirmation that the only endpoint is the dns (are all POST calls?) and the test command it is the most comfortable way to verify.
If on the systems side they ask me more in case I ask you for further help.
Thank you, you are very kind.

[stayallive]

Yes, that domain in your DSN is the only outside source we talk too, and it's only POSTs at the moment, but if possible I would try to allow all requests to that endpoint if possible since I cannot guarantee that it will always be only POST requests.

Hope you get it solved, and if not feel free to reach out again!

[illambo]

Hi, @stayallive
by performing the following downgrade it works the dns is reachable:

sentry/sentry-laravel:2.12.1 -> 2.12.0
sentry/sdk:3.20 -> 3.1.1
sentry/sentry:3.6.0 -> 3.3.7

Do you have any idea if is there any new configuration that may impact this?
Thanks and sorry for the trouble.

[stayallive]

Here you can find the changelog between 3.3.7 and 3.6.0 of the Sentry PHP SDK which handles talking with Sentry (the Laravel SDK is but a thin wrapper): https://github.com/getsentry/sentry-php/blob/6d1a6ee29c558be373bfe08d454a3c116c02dd0d/CHANGELOG.md.

The most interesting bit is getsentry/sentry-php#1312 possibly (Set the default send_attempts to 0 (this disables retries) and deprecate the option. If you require retries you can increase the send_attempts option to the desired value.), others seem unrelated (but maybe something else catches your eye).

Is it possibly you are behind a firewall where one of the IPs is whitelisted and thus with retries the request comes through eventually but without it has a much lower chance of working? I am unsure of your restrictions so it's a wild guess :)

[illambo]

Thanks, I'm thinking about it.

[illambo]

Container dns resolution problems solved 😶
... sorry again and thanks.

[stayallive]

No worries, happy it's solved!