logdog: a tool for aggregating logs

[webern]

Issue number:

Closes #452

Description of changes:

A rust executable that shells out to multiple programs writing logs into an aggregation tempdir, then tars these and deletes the tempdir.

Testing done:

I built a Bottlerocket AMI and ran logdog on it.
I used SSH to bring the tar to my local machine and inspected the logs.
(The Bottlerocket host joined the EKS cluster as a node.)

The size of the executable on the Bottlerocket host is 173K.
The size of the tarball✻ 138K.
The size of the same tarball when inflated is 1.5M.

✻ on a host that's been running idle for about an hour.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[webern]

A fairly heavy revision based on @tjkirch review. The only suggestions that I didn't immediately embrace were:

• I did not delete the end-to-end test. I would like to keep the test if possible. As a compromise I now use only the echo program during the test.
• I did not move the commands to a toml file. Especially with the current iteration where the commands are listed in a simpler format, I think finding them in the program is more intuitive. Also there is a link in the root README.md to source/logdog/REAME.md which links to the appropriate Rust file, so I think these commands are easy to find.

If I missed anything other than these two bullet point, I apologize, it was due to the amount of code churn.

Once the code stabilizes into its final form, I will redo the tests on a Bottlerocket host.

[tjkirch]

I unresolved a few comments above that still apply. Sorry, I know it was a lot!

[webern]

In case anything goes wrong with diffing, this is the exact diff since the last review.

https://github.com/webern/bottlerocket/compare/9215c05096e4ab18eed4d4960a7d3be9577d20b9..27e9a62143c7f1560457186670f509a0eab709ea

[zmrow]

I believe @tjkirch has nailed down quite a few of the technical issues.

Not a blocker, but I'd like to suggest we add a little bit of logging to the program. The user is presumably running logdog because things are horked. Since we're in a debugging scenario, I think it's perfectly reasonable to log something like "Running: <command here>". This way, if any one of the commands were to fail, the user would know where it failed and be able to give us additional details. (Not to mention logging is fairly comforting)

You could also log where the output tarball is located so the user doesn't have to consult documentation to learn what happened and what to do next.

[webern]

I believe @tjkirch has nailed down quite a few of the technical issues.

Not a blocker, but I'd like to suggest we add a little bit of logging to the program. The user is presumably running logdog because things are horked. Since we're in a debugging scenario, I think it's perfectly reasonable to log something like "Running: <command here>". This way, if any one of the commands were to fail, the user would know where it failed and be able to give us additional details. (Not to mention logging is fairly comforting)

You could also log where the output tarball is located so the user doesn't have to consult documentation to learn what happened and what to do next.

The output filepath was already done, but I have added the logging of each command right before executing it.

[zmrow]

🍭