Replace banner with log statement in a cloud environment

[mpkorstanje]

Feature description

The problem

The current banner implementation is not a log statement. When used in a cloud environment this causes a little bit of grief by default. And while this problem is relatively easy to work around it doesn't feel Natively Cloud Native.

Context

We are currently logging with the ELK stack and using the Logstash Logback Encoder. This means all our logs are effectively in newline delimited json format. So our logs look like this:

kubectl super-deduper-service | head -n 8
 __  __ _                                  _   
|  \/  (_) ___ _ __ ___  _ __   __ _ _   _| |_ 
| |\/| | |/ __| '__/ _ \| '_ \ / _` | | | | __|
| |  | | | (__| | | (_) | | | | (_| | |_| | |_ 
|_|  |_|_|\___|_|  \___/|_| |_|\__,_|\__,_|\__|
  Micronaut (v3.8.3)

{"@timestamp":"2023-02-01T16:22:09.661Z","@version":"1","message":"Established active environments: [k8s, cloud]","logger_name":"io.micronaut.context.env.DefaultEnvironment","thread_name":"main","level":"INFO","level_value":20000}
<and lots more json>

While we'd usually view this in Kibana which will happily ignore anything that can't be parsed, sometimes we have to look into the logs on Kubernetes directly. And to make these readable we'd use jq. For example

kubectl logs super-deduper-service | jq
parse error: Invalid numeric literal at line 1, column 4

That of-course didn't work unless we filter out the first 8 lines.

kubectl logs super-deduper-service | tail -n +8 | jq
{
  "@timestamp": "2023-02-01T16:22:09.661Z",
  "@version": "1",
  "message": "Established active environments: [k8s, cloud]",
  "logger_name": "io.micronaut.context.env.DefaultEnvironment",
  "thread_name": "main",
  "level": "INFO",
  "level_value": 20000
}
<and lots more json>

And this is kinda annoying.

Proposed solution

When a cloud environment is detected the banner should not be printed. Instead it should be replaced with a log statement containing the Micronaut version.

Workaround

As a work around we disabled the Micronaut banner.

[alvarosanchez]

Note that cloud environments will no longer be deduced automatically starting from Micronaut 4. So perhaps a better solution is to restrict banner display if Environment.DEVELOPMENT is running.

That said, disabling the banner is literally a one-liner, so I'd consider this low priority

[mpkorstanje]

It's not quite a one liner. It is a one liner per application, so I'm looking at 25+ of these.

But I would not mind sending a pull request if that takes care of the low priority.

[alvarosanchez]

Would a configuration property help in your case? (eg micronaut.banner.enable = false).

You could set it in a ConfigMap and make it available to all the 25+ services at once.

[mpkorstanje]

A property could be made to work.

Are all properties available before applicationContext.start(); has been invoked? And if not, would printing the banner after the application has already started be much of a problem?

[alvarosanchez]

Are all properties available before applicationContext.start(); has been invoked?

That is what the bootstrap context is for. Have a look at https://micronaut-projects.github.io/micronaut-kubernetes/latest/guide/#config-client