Currently, seqcli log and seqcli ingest allow additional properties to be specified in -p Name=Value format:
seqcli log -m "Hello, {Name}" -p Name=User
This relies on sniffing the type of the property value to construct string, numeric, or Boolean property values in a reasonably intuitive manner.
However, there's no way to override the type used for the representation of a value, and no way to specify complex values such as service: {name: 'Test'} or tags: [1, 2, 3].
This PR is a proof-of-concept showing how we could use Seq.Syntax to construct strongly-typed property values:
Each member in the result of evaluating --properties is added to the log event. A tricky "object spread" is used behind the scenes so that in the seqcli ingest case, properties on the original event being ingested can be removed with {someProperty: undefined()}.
Posting this here as a spike; some more work is needed on tests, and there's a bit of an unpleasant split in seqcli log due to the current implementation no longer relying on LogEvent behind the scenes.
Currently,
seqcli log
andseqcli ingest
allow additional properties to be specified in-p Name=Value
format:This relies on sniffing the type of the property value to construct string, numeric, or Boolean property values in a reasonably intuitive manner.
However, there's no way to override the type used for the representation of a value, and no way to specify complex values such as
service: {name: 'Test'}
ortags: [1, 2, 3]
.This PR is a proof-of-concept showing how we could use Seq.Syntax to construct strongly-typed property values:
Each member in the result of evaluating
--properties
is added to the log event. A tricky "object spread" is used behind the scenes so that in theseqcli ingest
case, properties on the original event being ingested can be removed with{someProperty: undefined()}
.Posting this here as a spike; some more work is needed on tests, and there's a bit of an unpleasant split in
seqcli log
due to the current implementation no longer relying onLogEvent
behind the scenes.