5 ms·

This make anyone elses eyebrows raise sky high at this? > Claire replied, asking for the full stacktraces for the log entries, which I was able to also extract

by TylerE 3y ago

This make anyone elses eyebrows raise sky high at this? > Claire replied, asking for the full stacktraces for the log entries, which I was able to also extract from the logs. This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286. House is that not, like, megabytes on every single hit?

k1t 3y ago
Recording stacktraces of errors is a pretty reasonable thing to do. And ideally not every hit causes an error.
TheDong 3y ago
> HTTP 500 errors when viewing an account > Stacktrace for that 500 This is the default ruby on rails behavior. It prints a stacktrace on any 500 or unknown error, and it's just line numbers and filepaths. > megabytes on every single hit I run a rails app that's very poorly designed. I just checked, and the stack trace for a single 500 is 5KiB. It doesn't even add up to 1MiB a day since there's only a 500 error about every hour. > This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286 Having a call stack handy is is actually pretty performant. Java's default exception behavior is to bubble up a stack trace with every exception, whether you print it or not, and java applications run just fine. You have the call stack anyway since you have to know how to return, so the only extra information you need handy is the filename and line number debug symbols, and ruby needs that info anyway just by the nature of the language.
- SV_BubbleTime 3y ago
  >Java's default exception behavior is to bubble up a stack trace with every exception, whether you print it or not, Anyone who has spent 5 minutes in Java knows exactly what this looks like. And also how unwelcoming it is to new programmers.
  - TheDong 3y ago
    I have spent more than 5 minutes in java, and I don't know why having a stack available on an exception is unwelcoming to new programmers. It definitely seems better than the approaches some other languages have, like C's "return code 1, check errno", when most new programmers don't even know what an errno is. Can you explain it to me?
  - vore 3y ago
    Sure, but imagine how unwelcoming to everyone it would be if you didn't get a stack trace.
williamdclt 3y ago
Do you mean you do _not_ capture stacktraces of errors in a live system ? How do you go about understanding where the error comes from ?
- jrockway 3y ago
  I log stacks for every error-level log and have never found it that useful. It's better than just logging "EOF" with no context of course, but manually annotating each frame with information not known to the caller is the way to go. Shifting to Go specifics; stack traces miss things like channel recvs and loops. Consider: for _, datum := range data { if err := DoSomethingWithDatum(datum); err != nil { log.Error(...) } } In that case, the stack trace misses the most important thing: which datum failed. Another common case: type Thing struct { Value any Err error } func Produce() { ch <- MakeThing() } func Consume() { for _, thing := range ch { if thing.Err != nil { log.Error(...) } } } This one is easier to get right; capture the stack when MakeThing's implementation produces a Thing with err != nil. But, a lot of people just log the stack at log.Error which is basically useless. (Adding to the fun, sometimes Consume() is going to be an RPC to another service written in a different language. But you're still going to want a stack to help debug it.) TL;DR stack traces are better than nothing, but a comprehensive way of handling errors and writing the information you need to fix it to the log is going to be more valuable. It is a lot of work, but I've always found it worthwhile.
  - williamdclt 3y ago
    > In that case, the stack trace misses the most important thing: which datum failed. OK we agree that the stacktrace isn't _enough_, but it's still a really useful thing to have to understand what exactly happened (and quite often the single most useful thing). Of course we still expect devs to capture the information that led to the `log.Error`, so that we don't have to play guess games. Rather than manually-annotated logs, I'd prefer getting rid of all logging altogether and use tracing (opentelemetry), which is precisely designed for observability.
oefrha 3y ago
You’ve confused a stack trace with a core dump (or something similar).

by TylerE 3y ago

k1t 3y ago

Recording stacktraces of errors is a pretty reasonable thing to do. And ideally not every hit causes an error.

TheDong 3y ago

> HTTP 500 errors when viewing an account > Stacktrace for that 500 This is the default ruby on rails behavior. It prints a stacktrace on any 500 or unknown error, and it's just line numbers and filepaths. > megabytes on every single hit I run a rails app that's very poorly designed. I just checked, and the stack trace for a single 500 is 5KiB. It doesn't even add up to 1MiB a day since there's only a 500 error about every hour. > This is either deep voodoo magic, or the code or configuration is turning a Xeon into the equivalent of a 286 Having a call stack handy is is actually pretty performant. Java's default exception behavior is to bubble up a stack trace with every exception, whether you print it or not, and java applications run just fine. You have the call stack anyway since you have to know how to return, so the only extra information you need handy is the filename and line number debug symbols, and ruby needs that info anyway just by the nature of the language.

SV_BubbleTime 3y ago
>Java's default exception behavior is to bubble up a stack trace with every exception, whether you print it or not, Anyone who has spent 5 minutes in Java knows exactly what this looks like. And also how unwelcoming it is to new programmers.
- TheDong 3y ago
  I have spent more than 5 minutes in java, and I don't know why having a stack available on an exception is unwelcoming to new programmers. It definitely seems better than the approaches some other languages have, like C's "return code 1, check errno", when most new programmers don't even know what an errno is. Can you explain it to me?
- vore 3y ago
  Sure, but imagine how unwelcoming to everyone it would be if you didn't get a stack trace.

williamdclt 3y ago

Do you mean you do _not_ capture stacktraces of errors in a live system ? How do you go about understanding where the error comes from ?

jrockway 3y ago
I log stacks for every error-level log and have never found it that useful. It's better than just logging "EOF" with no context of course, but manually annotating each frame with information not known to the caller is the way to go. Shifting to Go specifics; stack traces miss things like channel recvs and loops. Consider: for _, datum := range data { if err := DoSomethingWithDatum(datum); err != nil { log.Error(...) } } In that case, the stack trace misses the most important thing: which datum failed. Another common case: type Thing struct { Value any Err error } func Produce() { ch <- MakeThing() } func Consume() { for _, thing := range ch { if thing.Err != nil { log.Error(...) } } } This one is easier to get right; capture the stack when MakeThing's implementation produces a Thing with err != nil. But, a lot of people just log the stack at log.Error which is basically useless. (Adding to the fun, sometimes Consume() is going to be an RPC to another service written in a different language. But you're still going to want a stack to help debug it.) TL;DR stack traces are better than nothing, but a comprehensive way of handling errors and writing the information you need to fix it to the log is going to be more valuable. It is a lot of work, but I've always found it worthwhile.
- williamdclt 3y ago
  > In that case, the stack trace misses the most important thing: which datum failed. OK we agree that the stacktrace isn't _enough_, but it's still a really useful thing to have to understand what exactly happened (and quite often the single most useful thing). Of course we still expect devs to capture the information that led to the `log.Error`, so that we don't have to play guess games. Rather than manually-annotated logs, I'd prefer getting rid of all logging altogether and use tracing (opentelemetry), which is precisely designed for observability.

oefrha 3y ago

You’ve confused a stack trace with a core dump (or something similar).