Case 1: Wrong use of logger.error for aggregator logger
Rule complete description
Text
{When running an application, loggers in error severity shouldn't be run in the main body of a method. In production, an application with many users can result in a very large amount of logs and costly in performance. Incorrect use of loggers and their severity can result in too many network calls and memory overflow of splunk servers.
So, It's recommented to use the error severity of your logger in a catch or failure zone of the program.}
Even if it seems to be something for ecoCode in this rule, I can see several problems:
We do not have anything (document, measure or other...) that show us the impact in term of energy for the rule
The rule is oriented to talk about "performance". Even if it can be related to energy, it is not the same thing. At least the rule should be reworded.
The rule is to generic for me "loggers in error severity shouldn't be run in the main body of a method" and in the exemple we are in a "if", seems contradictory.
\newpage
Best practice use logger.error
Platform
Main caracteristics
Severity / Remediation Cost
Rule short description
Rule complete description
Text
{When running an application, loggers in error severity shouldn't be run in the main body of a method. In production, an application with many users can result in a very large amount of logs and costly in performance. Incorrect use of loggers and their severity can result in too many network calls and memory overflow of splunk servers. So, It's recommented to use the error severity of your logger in a catch or failure zone of the program.}
JAVA Example
Implementation principle
Source for understanding the difference in the use of logger severity: https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html