Closed marcofucci closed 7 years ago
I am interested in accepting this pull request, but I'd prefer to have this behavior change explicitly enabled at config with a flag like "treatErrorsAsExceptions" (true/false) or maybe allowing to set the level to track as exception. Exceptions are unexpected conditions in the code, while errors are not necessarily unexpected and may be legitimate state of an operation. I.e. to make things clear, exceptions should be fixed by the developer (and eventually handled as errors), while errors may just be logged/notified stating a valid result of an operation. This probably also explains why exceptions in AI are not the same as errors. If the reason of treating errors as exceptions is because errors are not visible enough in AI, then it is more a problem with AI's interface or the user query/search in AI.
@marcofucci do you think you could consider adding some settings to enable/disable/configure this via logger's options and submit a new PR?
Thanks!
@bragma I agree, different languages also give different meaning to errors/exceptions which doesn't help. Adding a flag "treatErrorsAsExceptions" makes perfect sense, I'll add that and rebase this PR.
@bragma I've made the changes and rebased this PR. Please feel free to have a look and let me know what you think.
Thanks!
Published as 1.1, thanks a lot! :)
When the log level is >=
error
, the transport will also treat it as an app insights Exception. This allows you to see it clearly in the Azure Application Insights instead of having to access trace information manually and set up alerts based on the related metrics.How it works:
winstonLogger.log('error', 'error message');
will trigger an app insightstrackException
withError('error message')
as argumentwinstonLogger.log('error', new Error('error message'));
will trigger an app insightstrackException
with the Error object as argumentwinstonLogger.log('error', 'error message', new Error('error message'));
will trigger an app insightstrackException
with the Error object as argument