Laravel Log function not reporting about sentry-laravel HOT 8 CLOSED

@rsands2801 I'm not sure this was ever reported. We didn't capture log messages -- only exceptions (through Laravel's handler):

https://github.com/getsentry/sentry-laravel#laravel-5x

If you have more information that suggests it is actually changed behavior we can dig, but I dont know how it would have been possible.

from sentry-laravel.

Whats the point of Sentry if it doesn't capture log error messages, thats back to server logging and defeats the purpose

We used package jenssegers/laravel-raven but I didnt realise that was not part of your team. It always captured Log:: messages.

If we do Log::critical sentry wont capture any of it? This should be easily implemented.

from sentry-laravel.

It's something we support optionally but not out of the box in Laravel (sentry/Sentry has a monolog handler). We don't do this by default because Sentry isn't a log aggregator, and is primarily used to capture unhandled exceptions. Even more important is the fact that you won't have an error object, thus no stacktrace, and no useful debug information.

from sentry-laravel.

Seems like a weird decision. Sentry is advertised with:

Users and logs provide clues

Know when things break

If things break, you’ll know where errors are happening, how often they happen, and who is affected.

Know what’s breaking and how to reproduce the problem, without waiting for user reports.

We use Log::critical and Log::error to track things happening. We handle the exceptions and let the users continue, if we have an uncaught exception Sentry is going nothing useful but saying your code was poorly written. We decide via the Log:: whats important to detect and fix.

Seems a mad decision to ignore a basic Laravel function that has been in it since Laravel was invented

from sentry-laravel.

@rsands2801 Sentry does far more than Laravel (and has been around a lot longer than it), and we're very focused on our mission. The point of the statement is "users and logs [only] provide clues, [sentry's error capturing] provides answers". Our mission doesn't always align with what people think we should do, and we're ok with that.

Again, without the exception object you get no stacktrace. Without a stacktrace, you get no context and you get no reasonable aggregation. You can send logs to Sentry, but it's not going to work that well. You should generate errors and send them to Sentry in whatever manner makes sense for your app. If you're already doing things like try {...} catch ($ex) {...} it becomes pretty easy to add an abstraction that does app('sentry')->captureException($ex).

Also, as a 15 year veteran of building widely used applications, I promise you that Sentry's error capturing is far more than "you wrote poor code". You don't always have logs, and often those logs don't have any information on what actually triggered the error.

from sentry-laravel.

Yes but what if we want to watch for something happening. It is a package built to handle Laravel so surely it should handle how Laravel does things i.e. use Log::

What happens if we want to capture an exception inside a function. So we capture it, call Log::error(); and then either redirect or do something inside the function.

Its a duplication to put app('sentry') everywhere beisde Log::(). And that is also very silly considering it means filling our code full of sentry specifics...what happens if we wanted to change provider (by looks of it we are going to have to anyway)...our code is now littered with Sentry specifics.

Instead we can change the package that is listening for Log:: and it does not mess up our code.

If i did a pull request with it properly working as it should be, will it be declined?

from sentry-laravel.

Maybe I'm not being clear, so let me try this one last time with examples:

Log::error($ex->getMessage());

is greatly different than:

$app->handleError($ex);

One only has access to plaintext strings, which are next to useless. The other has access to anything it wants. That's the one Sentry needs to be useful.

In your app you could easily do:

function handleError($ex)
{
    app('sentry')->captureException($ex);
    Log::error($ex->getMessage());
}

Now we're not opposed to adding functionality to capture logs (opt-in), but if you're not doing something along the lines of what I'm suggesting you haven't even begun to experience what Sentry is capable of.

from sentry-laravel.

I know what Sentry is capable of. That is not what I am getting at. We use Laravel in a load balanced system, many servers running the traffic. So sometimes we need to Log::info() that is helpful for us. We don't wrap all our code in exceptions and throw them everywhere. We sometimes just do Log::info() when something we want to monitor happened. We are software engineers - we know how to stack trace ourselves - so what may seem useless to you in a string is very useful to us. What Sentry does is allow us to see the things happening that could cause a user problems. It is an error sometimes, not worthy of an exception. We get more than enough informaton by just doing this:

public function subscribeLog(Writer $log)
    {
        $log->listen(function ($level, $message, $context) {
            $context['level'] = $level;
            $this->client->captureMessage($message, [], $context);
        });
    }

The message being Log::info($message);

from sentry-laravel.