The entries.write API takes a number of optional, non-payload variables for each entry:
resource is a MonitoredResource: AFAICT, we should always be passing it as {"type": "global"} (the others are generated by the various API backends).labels is an arbitrary key-value mapping (distinct from the structPayload).severity is an enumerated value, defaulting to LogSeverity.DEFAULT.insertId for de-duplication (set by the backend if not passed).httpRequest is a struct describing the HTTP request associated with the entry.operation is a struct allowing multiple entries to be grouped into an "operation".
resource and labels can also be passed as top-level defaults.
My question is: how should we expose these options? Should we capture values on the logger itself (e.g., when constructing it)? Should we allow passing them as explicit arguments to the individual log_text/log_struct calls? Some of them should clearly be per-entry (httpRequest, insertId, severity). operation might map best onto a batch-like entity (see #1565). labels and resource (assuming we allow it) seem like they are better associated with the logger.
The
entries.writeAPI takes a number of optional, non-payload variables for each entry:resourceis aMonitoredResource: AFAICT, we should always be passing it as{"type": "global"}(the others are generated by the various API backends).labelsis an arbitrary key-value mapping (distinct from thestructPayload).severityis an enumerated value, defaulting toLogSeverity.DEFAULT.insertIdfor de-duplication (set by the backend if not passed).httpRequestis a struct describing the HTTP request associated with the entry.operationis a struct allowing multiple entries to be grouped into an "operation".resourceandlabelscan also be passed as top-level defaults.My question is: how should we expose these options? Should we capture values on the logger itself (e.g., when constructing it)? Should we allow passing them as explicit arguments to the individual
log_text/log_structcalls? Some of them should clearly be per-entry (httpRequest,insertId,severity).operationmight map best onto a batch-like entity (see #1565).labelsandresource(assuming we allow it) seem like they are better associated with the logger.