| 2 | Do we need a second appender for errors? | | Meeting Notes 11/12/20 https://docs.onap.org/projects/onap-logging-analytics/en/latest/Logging_Enhancements_Project/logging_enhancements_project.html#id33 The logging enhancement team has proposed to split the log to multiple files: - debug.log
- audit.log
- metric.log
- error.log
Toine has suggested we follow this approach but exclude error logging.
Before making anymore decisions we will investigate this project as we have some concerns about the logging standards in the logging enhancement project. |
| 3 | The application should only logs to stdout and not in files? | By doing so we can leverage Kubernetes standard logging design. If logging to files is provided, It would be good to also have a way to disable it to avoid file space management questions on worker nodes or pvc depending where logs files would be kept. For monitoring, it is more complex to operate applications that are each one using specific logs files. By having all applications logging to stdout, all logs can be collected in a common standard way and published and re-used anywhere that is convenient for any operations team (using filebeat or elk stack for example). See https://kubernetes.io/docs/concepts/cluster-administration/logging/
- Whether user will be using Kubernetes / Azure or single manual deployment, features capability should be the same. We should not enforce to use anything specific to achieve the same service solution.
- Many company enforce to have those separate type of log files by security policy. Usually they store the audits logs ones.
With log properties, you always can change the level log. And also alterate/disable the logs appenders at runtime.
| Meeting Notes 11/12/20 Everything a containerized application writes to stdout and stderr is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to a logging driver, which is configured in Kubernetes to write to a file in json format. - use a log rotation script - We want the logging to be easily configurable and allow for different implementations on how to collect logs. We will expose this configuration in the helm charts.
- Our default logging will be std out as it is easily configurable.
|
| 4 | Is the file location ok? | ../log/${logName}.log
I think this is ok. Logs will be placed in pods once deployed. I think we will need to set a property in our SpringBootApplication class for the log dir. |
|
| 5 | Disk space | <property name="maxFileSize" value="20MB" /> Once the log reaches this value it is zipped. |
|
| 6 | What kind of message should go with which level for logging? | See 'Summary of each logging level' below Could consider a (CPSException) property that differentiate between error/warning and even fatal if we want? |
|
| 7 | Where exactly to log error, at source or a common central place? | - Prevent same error being logged may times (some duplication might be unavoidable though)
- Consider that REST layer is optional (so that is why the current commit is not a good solution for centralized logging)
|
|
| 8 | How should we format our logs? | logger.debug("No of Orders " + noOfOrder + " for client : " + client);
logger.debug("No of Executions {} for clients:{}", noOfOrder , client); |
|
| 9 | Should we use is log.isDebugEnabled()? | I think we should if the cost of performing the log is expensive - for example if we need to build a parameter in the log |
|
| 10 | What logging framework to use?We are currently using slf4j | Should we configure SLF4j to use log4j, log4g2, logback etc.? |
|
| 11 | What kind of information to log? | - Never log sensitive information as plain text
log all important information that is necessary to debug or troubleshoot a problem if it happens. - Always log decision making statements e.g. the application loads some settings from a preference file and is unable to find the file
|
|