Log format customization

[klauern]

Is your feature request related to a problem? Please describe.

From what I can tell, the format for logs from Kritis are in the format of glog, which is not in an easily-digestable format.

Describe the solution you'd like

I would like there to be an option to specify the output format, such as JSON, that can be used generically by log aggregators without customization. Additionally, if that were not possible, a formal specification of the glog log output format would be helpful for developing log parsers for the tools that we use to collect them.

Describe alternatives you've considered

I don't see any way to format the log output, and from what I can see, there's not a lot of documentation outside of Google that explains what glog's format is or how it is expected to be digested.

Additional context

I've looked a bit here: https://github.com/google/glog/blob/master/doc/glog.html

But I don't see much explaining the format there, either. More of a 'how to use this library' doc, and not for consumers of logs.

[aysylu]

Hi @klauern, thanks for filing the GH issue. I'd like to better understand your use case: how are you planning to use the logs from Kritis? i.e. what process will be consuming the logs? It sounds like kubectl logs -l app=kritis-validation-hook is not a sufficient way to consume them in your case.

glog just uses C++-style formatting. How would you like to be able to format your logs?

[klauern]

Hello @aysylu. We have some log ingest tooling that we would be using to create metrics off of the runtime operations of Kritis itself. This is part of a bigger set of questions around event tracking and metrics itself, but since Kritis' logs have a lot of the context, we would be happy to parse those out as a short-term solution.

For instance, right now, we have Kritis deployed to our staging environment, but we don't have an easy way to determine:

• which deployments are being blocked, and the reason for it (which CVE, policy, etc., is enforcing the block)
• the time it takes to do lookups against Grafeas or GCR for validation (as an SLI for monitoring)
• The number of blocks, lookups, etc., (general metrics on use)
• Which deployments are being let through using the "break glass" functionality (so we can monitor for one-offs, patterns of behavior, suspicious use-cases, etc).

Some of these can be gathered out-of-band, or outside of Kritis itself, but if these were emitted as a metric (Statsd, Prometheus, etc), it would make aggregating and monitoring the overall health of Kritis and our Kubernetes environment a whole lot easier.

[aysylu]

Hello @klauern, thanks for clarifying your use case. In my Monitorama PDX talk (slides, video), I discussed ways to extract this kind of information into Grafeas-structured metadata format. We could use the existing Deployment note and occurrences, and add any other metadata kinds that we need. Is this something that'd help address your needs?