GitHub user DaanHoogland added a comment to the discussion: logging standards in CloudStack
I like your summary @JoaoJandre except for the error bit: > Error: > > * Include a reason why the system can not execute a user request or > why part of the system is degraded; > > * If the error is happening because a user request cannot be executed, do > not include a stack trace; however, if the system is degraded in some form, > that is, some feature will stop working or some component of the system is > compromised, and the stack trace might bring helpful information, then > include the stack trace. Though it looks good in general there is not a clear distiction if something is caused by a user and how directly: i.e. - Was it because of an API call; clear. - Was it because of a background cleanup job; clear in the other direction (unless it is an expunge of a user resource). - Was it because of a scheduled task; grey area My take on this dilemma is to never add a stack trace to error messages and let them be followed by a debug message with thew stacktrace, so operators can turn them on and off at will. GitHub link: https://github.com/apache/cloudstack/discussions/8746#discussioncomment-8717017 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
