Clarification on custom fields about cf-nodejs-logging-support HOT 6 CLOSED

Hi,

the specification you linked is for request logs only. There is a similar file for logs written by the application. However, the property custom_fields is not contained in either of those. This is due to its special nature. custom_fields is supposed to hold a map of key-value pairs. Values are expected to be strings. If you use custom fields without registration, they are intentionally put on the root level. Custom fields is a special feature to allow specialised parsing of the fields in this structure.

Best Regards,
Karsten

from cf-nodejs-logging-support.

Thanks Karsten,

1. I'd suggest adding them to the specification so that it is the ultimate source of truth regarding what a log entry would contain. The library will still be compliant. So, you say the values of the properties in the custom_fields should always be strings (also #12 seems related)? It would be useful to be documented in the spec as someone may need numeric data in there.

2. What are the use cases of the properties being added on root level? If it is documented somewhere, this would also help. Are these also always converted to strings? What will happen if an application uses a property whose name is the same as a standard property (by standard property I mean a property defined in the spec)? Which one will be present in the logs?

And, in general, when to use which of these 2 features? I mean if I can take any property to root level, why would I need to use custom_fields?

Many thanks
Petar

from cf-nodejs-logging-support.

I will update the specification to reflect the current state.

I can understand, that the custom fields feature seems somewhat strange at a first glance. It was design with the Application Logging Service in SAP CloudPlatform CloudFoundry as the target system in mind. This Service restricts field at root level to those mentioned in the specification. You can add other fields, but they will not be indexed by the Log Parser of that Service. However, this service will index arbitrary key-value pairs under custom_fields, interpreting all values as strings. This library tries to smoothen this difference by providing a unified approach when generating log messages. There is no difference between root level and custom fields when emitting a log message. For this to be possible the registration of custom fields when creating the log context was introduced.

from cf-nodejs-logging-support.

Thanks Karsten,

1. If the additional properties on root level are not indexed, can they be of any use?
2. Does it make sense to remove them from the output (and just stick to the custom_fields property)? If not, then in what situations should the root-level props be used?

Thanks again
Petar

from cf-nodejs-logging-support.

Additional properties on root level can be of use when the logs are sent to other logging services, that have different parsing. This includes our Cloud Logging Service. By default all fields registered as common fields are removed from the root level. For compatibility reasons it is possible to retain a custom field also on root level. This comes in handy when a former custom field is "promoted" to root level, as it was done with tenant_id.

from cf-nodejs-logging-support.

Thanks for the info

from cf-nodejs-logging-support.