make default log timeformat human readable

[ArgTang]

Is your feature request related to a problem? Please describe.
{"level":"info","ts":1632735489.3334155, ...}
the ts field in the logs is not human readable.

Describe the solution you'd like
The logs print timestamp with ex. iso8601 formatting

[ansd]

I think the default time format of the JSON logs should stay a Unix time stamp because

1. That's what's defined in the Kubernetes JSON log format: ts - timestamp as Unix time (required, float)
2. That's the default of the zap production mode logger used in controller runtime.
3. Above 2 points seem to me a very good default because in production, you'll have a logging backend. Every decent logging backend (or even earlier on the log shipper) can convert the time format from unix timestamp to whatever human readable time format you prefer.
4. If you don't run the operator in production, use the --zap-devel command line flag in the operator deployment. It will print more human-readable output, i.e. no JSON and human readable time format, e.g. 2021-09-30T10:08:41.229Z INFO controller-runtime.manager.controller.rabbitmqcluster Finished reconciling ...

[ArgTang]

Since there is no helm chart available and its no configuration section in the readme it is not easy to discover these flags. Can you change the loglevel as well here?

yes we do have some default logging pipeline setup. We have some parsing rules with fluent bit, but we prefer human readable timestamps. We can usually configure it and have not had any apps force epoch before. Another point is when looking directly at the logs in the pod as well make it hard to parse the timestamp. to see what logs is relevant.

[ansd]

Can you change the loglevel as well here?

The command line flags of the zap logger can be found here.

For example, to only output error logs, configure the messaging-topology-operator deployment YAML as follows:

    spec:
      containers:
      - args:
        - --zap-log-level=error
        command:
        - /manager

I agree, we should document these flags.

Another point is when looking directly at the logs in the pod as well make it hard to parse the timestamp. to see what logs is relevant.

You can use kubectl logs --timestamps. This flag will include human readable timestamps on each line in the log output (They might deviate by a few microseconds from the timestamp output by the RabbitMQ logs / Unix time. However, that should be good enough in most cases.)

[ArgTang]

Thanks for the tips. we'll see if we can work around this

[Zerpet]

I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :(