Adding scenarios for using the local logging (or other log driver results) effectively

[byjrack]

Probably more a Discussion, but a solid feature would be how to use that content to understand how Docker Desktop is being used and if there are issues that could be popping up in the environment.

Using Windows as an example the %LOCALAPPDATA%\Docker\log.txt seems to aggregate events from all the different features of the product. The challenge is it is trace level so the events can be a a bit low level or difficult to connect to an interaction like a login/refresh, image lifecycle, container lifecycle, or extensibility features of the product.

Given I don't think there is a clear cut event for a human interaction so likely you would need to infer something from one or more events. And given an event like a container create uses the SHA you may not be able to get the context you want (what image in human readable form) was launched.

That type of scenario metadata may not be as simple as a regex, but if there are recommended patterns for parsing events in the daemon logs (or other logs) having those available as a "known good" can help folks add that type of usage or issue telemetry into existing systems of record.

In this case I am not talking about logging from the app running in DD, but the product itself. So it's a bit of a different scenario than the telemetry that may come from a server config. And if there are existing patterns for using something like Filebeat to collect all the content and Logstash to reduce the noise that would be great. If not and there are those known good parsing routines maybe I can get it going and open a PR.

[richardkiene]

@byjrack, it would be great to get your thoughts on 4d7202d. There is still some work and collaboration to be done, but this might be a good start.

[byjrack]

Yup was thinking that would be the same basic pattern for read and load, but whats to stop the same event from being added to the evtlog on the next run? Given you can't find by time since the stamp will follow the event.write and not the parsedTime it feels like you might need to create a hash of the message and prefix/suffix message with that content and do a get-event call to check if not exists. It would be great if there was a real metadata model on events, but 100% its limited.

The other is noise reduction in the eventlog. The docker logs are pretty verbose and have tons of noisy activity that someone may not want so likely a param for the posh would include some method of filtering out material events from general noise in the log. This is more what i was getting at with "parsing" the log file versus just the string data format parsing. Also the more noise the heavier the cost will be for that message hash check routine.

I will open an item on the roadmap backlog for a windows driver proxy. local driver can write into the filesystem, but i imagine the host process has some pipe into daemon. So if there was a winevtproxy driver for daemon that can trigger something in the host process (electron or other DD host process) which writes the evt to event log realtime. now there will be some drift between the daemon event and when it would be added to the host evtlog, but it should be pretty small. Or another option might be a syslog server process in DD so use the same driver, but it handles the push into windows evtlog. Feels like there should be a oss project on that, but its buried under all the evtlog to syslog efforts.