3 ms·

> There are a lot of cases when we don’t care. Because of the retries, queues, or it might be an optional step that can be skipped. If this failure is not impor

> There are a lot of cases when we don’t care. Because of the retries, queues, or it might be an optional step that can be skipped. If this failure is not important - then just forget about it. No! Log it and still retry. There are lots of reasons why might want to know later on if something failed the first time and then had to retry, for example when debugging possible timing issues. > And yes, you got it correctly: it sounds like a job for Sentry, not logging. Sentry is a form of logging. Also, sometimes you have potentially private data in local variables that you absolutely cannot risk sending to a service over the network; a log message allows you to be very careful with what information you reveal and what you don't reveal. Which brings me to another use case for logging: sometimes you simply cannot report exact errors to customers (because they might leak the existence or nature of other customer's data), but if the customer contacts support, you absolutely want that information in the logs (even if just to decide if the vague error message was intentional or a bug). Don't get me wrong, I'd love to live in a world where every action straight out succeeds or results in a bug ticket, but the real world is much more complicated, and logs do help making sense of that.

Spivak 7y ago
> No! Log it and still retry. You will likely say this is a form of logging, and you’re right, but I think this is a better fit for a metric rather than a log. “Something something retried at…” isn’t nearly as useful as the “the number of retries peaked at…”
- perlgeek 7y ago
  Both logging and metrics can be useful in such a case. Metrics are useful to get a general picture, and logging is useful when you try to find out in one specific instance what happened. If you have a billion requests per day, you likely don't want logging for retries; if you have a small number of requests, many of them important enough to investigate individual errors, you absolutely want logs on what happened to each request.
hinkley 7y ago
I’m having trouble defining the line between logging and statistics, and things like retries are firmly in the middle here. Record retries: yes. Log them? Mmm, maybe not.

Spivak 7y ago

> No! Log it and still retry. You will likely say this is a form of logging, and you’re right, but I think this is a better fit for a metric rather than a log. “Something something retried at…” isn’t nearly as useful as the “the number of retries peaked at…”

perlgeek 7y ago
Both logging and metrics can be useful in such a case. Metrics are useful to get a general picture, and logging is useful when you try to find out in one specific instance what happened. If you have a billion requests per day, you likely don't want logging for retries; if you have a small number of requests, many of them important enough to investigate individual errors, you absolutely want logs on what happened to each request.

hinkley 7y ago

I’m having trouble defining the line between logging and statistics, and things like retries are firmly in the middle here. Record retries: yes. Log them? Mmm, maybe not.