Attn: Kiran Kamineni Milind Jalwadi Thamlur Raju Ritu Sood
Introduction
Logging is important for reasons such as
- troubleshooting
- to know historical behavior of the applications
In particular, for K8S based Cloud region support, following reports may be of interest
- Resource bundles that are uploaded - With various types of information such as resource bundle name, description, date/time, user, success/failure, failure reason etc...
- Resource bundles that are deleted - With various types of information such as resource bundle name, description, date/time, user, success/failure, reasons etc..
- Instantiations of resource bundles - Instantatiation name, ID, resource bundle used, profile used, date/time, K8S cluster being used, initiating user, success/failure etc...
- Termination - Instance name, ID, resource bundle used, profile used, date/time, K8S cluster, terminating user, success/failure etc...
- Profile creations
- Profile deletions
- Day2 config template creations
- Day2 config template deletions.
- Day2 configurations
- Day2 configuration updates on running instances
- K8S Cluster registrations
- K8S cluster removals
- K8S cluster updates
And more error related logs and reports.
Using GUI, one shall be able to figure out:
- Various resource bundles.
- Instantiations with some search criteria such as location, resource bundle name, profile name, date/time range, user etc...
- Termination with some search criteria
- Errors with some search criteria
Log package
Current thinking is to go with following:
- Fluentd for log collection
- Elasticsearch for log storage
- Kibana for visualization
Log libraries
Currently, all Microservices that are created to support K8S based Cloud region support are implemented using go-lang. Even the Microservices that are part of ONAP4K8S profile are also developed in go-lang. At this time, the though process is to use following logging libraries
- zerolog
- https://github.com/sirupsen/logrus (used by prometheus, docker, operator sdk etc..)
- https://github.com/uber-go/zap (used in controller-runtime) (Supposed to be very high performance)
It is highly prefered that we decide on one logging framework in any code we develop. That said, we are using third party microservices (for example - vault, consul, MongoDb, etcd, ISTIO, TPM, softHSM etc..) and they are using their own logging libraries. fluentd is very flexible and already many input filters and we are hoping that we don't need to develop any new input plugin in fluentd.
Log format
This section describes the log format for any code being developed in go-lang in ONAP.
Log message is in JSON format. And hence each field shall have key/value paradigm.
Log message fields:
- Common fields:
- date & time
- log level
- log source (module name)
- log type
- Type specific fields.
- Free format string
- string
< TBD: Add right keyword name to represent each field>
Log Messages
This section defined various log message types and define fields needed for each type of log.