While we put a lot of work into providing libraries to produce ecs-logs compatible logs, sometimes modifying the code isn't efficient (think about a third part service for example).
ecs-logs provides basic support for this use case, basically if it doesn't recognize the log format it just considers that lines sents to stdout are INFO messages and lines sent to stderr are ERROR messages.
This is fine for basic cases but quickly shows its limits when deeper analyses of the logs are required.
One way to address this issue would be to have a shim process that captures the standard input and output of the process, and is configurable to parse the service logs and format them in a way that extracts meaningful information.
The interface could look like this:
logshim [options ...] -- [command ...]
The shim would act as a simple process manager for the command, piping stdout and stderr and applying a set of configurable rules to convert unstructured logs into an ecs-logs compatible format.
While we put a lot of work into providing libraries to produce ecs-logs compatible logs, sometimes modifying the code isn't efficient (think about a third part service for example).
ecs-logs provides basic support for this use case, basically if it doesn't recognize the log format it just considers that lines sents to stdout are INFO messages and lines sent to stderr are ERROR messages. This is fine for basic cases but quickly shows its limits when deeper analyses of the logs are required.
One way to address this issue would be to have a shim process that captures the standard input and output of the process, and is configurable to parse the service logs and format them in a way that extracts meaningful information.
The interface could look like this:
The shim would act as a simple process manager for the command, piping stdout and stderr and applying a set of configurable rules to convert unstructured logs into an ecs-logs compatible format.