search

honeybadger-io / honeybadger-php

PHP library for reporting errors to Honeybadger.io :elephant: :zap:
https://www.honeybadger.io/for/php/?utm_source=github&utm_medium=readme&utm_campaign=php&utm_content=website-url
MIT License
38 stars 21 forks source link

Insights logging issues #206

Open joshuap opened 3 weeks ago

joshuap commented 3 weeks ago

A few issues that we found today:

  1. When the Insights API is rate limited, the current error message says it's the exceptions API. We should say which API is being rate limited, and also check our other service errors for similar issues now that we have two APIs.
  2. Our service_exception_handler for Laravel currently warns the logger by default, and it includes the error stack trace—which can result in a lot of logging when Insights events are throttled. We should remove the stack trace from these log messages to reduce the amount of data we're logging.
  3. Similar to 2, we should add some throttling to our logging so that we don't spam the logs as much when the errors or Insights events APIs are severely throttled. Vector does it this way according to @stympy.

@subzero10 can you break this up into separate issues when you get the chance? 1 and 2 are the most important. I think 3 could happen after you look into #203.

Front logo Front conversations

subzero10 commented 2 weeks ago

When the Insights API is rate limited, the current error message says it's the exceptions API. We should say which API is being rate limited, and also check our other service errors for similar issues now that we have two APIs.

210

Our service_exception_handler for Laravel currently warns the logger by default, and it includes the error stack trace—which can result in a lot of logging when Insights events are throttled. We should remove the stack trace from these log messages to reduce the amount of data we're logging.

I introduced (https://github.com/honeybadger-io/honeybadger-laravel/pull/142) a new events_exception_handler that would allow more refined control around exception handling from the events api. The default operation is no-op, to avoid accidental noise since many events are being captured automatically.

Similar to 2, we should add some throttling to our logging so that we don't spam the logs as much when the errors or Insights events APIs are severely throttled. Vector does it this way according to @stympy.

211