...
- Currently: varies (no default prescribed by ONAP application logging guidelines.pdf).
- Affects: most ONAP components, superficially.
- Why:
- Reduced complexity.
- Fewer special cases, simplified orchestration.
- Certain components are presently not configurable, e.g. Portal, for which even trivial reconfiguration of logging requires reassembly of its WAR.
- See Support for analytics pipelines.
- Notes:
- This simplifies deployment automation, reconfiguration, etc.
- These paths will normally be local to a container, NOT on a mounted shared volume.
- The exact path can be fine-tuned, but:
- The benefit of an ONAP-wide convention should be obvious.
- This corresponds to the convention implemented (updated for ONAP) by MSO and others.
- It should be aligned with conventions for other component- and subcomponent-specific configuration documents.
One logfile per subcomponent
Logfiles that are machine-readable and report only populated MDCs don't benefit from sorting log entries into multiple files. Writing fewer files reduces complexity.
- Currently: the standard logback configuration writes several files: audit.log, metric.log, debug.log, transaction.log, etc. (In some cases all.log).
- Affects: all ONAP components, but only by way of a configuration change.
- Why:
- This complicates analytics configuration. (It also complicates other kinds of analysis, since output is further fragmented).
- The sorting is arbitrary. There are many other equally valid ways that output could be partitioned.
- There is negligible benefit to justify the additional complexity.
- Notes:
- This is separate to the issue of rollover.
- There is a school of thought which says that logger output should be to STDOUT and STDERR only, and redirected as necessary, for example https://12factor.net/logs. We don't need to go quite that far, but they make an eloquent case for simplicity.
- ONAP components typically consist of one or more subcomponents. Subcomponent generally corresponds to a container.
Configuration overrides
All configuration locations to be overrideable by a system or file property passed to (or read by) the JVM. (No specific convention suggested, because it'll only divert attention from the importance of having a convention).
...