SonarQube server json log format - inconsistent time, missing zeros make it hard to parse

Must-share information (formatted with Markdown):

  • which versions are you using SonarQube 10.1.0-community
  • how is SonarQube deployed: Docker
  • what are you trying to achieve: parse server logs with fluentbit
  • what have you tried so far to achieve this : see below


I have one issue when parsing json logs of SonarQube using fluentbit. A small issue to be honest.

Things mostly work but the time format does not include trailing zeros when there are only zeros.


{"process":"web","timestamp":"2023-08-17T09:50:57.999Z","severity":"INFO","logger":"org.sonar.server.platform.web.MasterServletFilter","message":"Initializing servlet filter org.sonar.server.platform.web.WebServiceReroutingFilter@7ad8fb8f [pattern=UrlPattern{inclusions=[/api/components/update_key, ...], exclusions=[]}]"}
{"process":"web","timestamp":"2023-08-17T09:50:58Z","severity":"INFO","logger":"org.sonar.server.platform.web.MasterServletFilter","message":"Initializing servlet filter org.sonar.server.authentication.DefaultAdminCredentialsVerifierFilter@2ae6cce1 [pattern=UrlPattern{inclusions=[/*], exclusions=[*.css, ...]}]"}
{"process":"web","timestamp":"2023-08-17T09:50:58Z","severity":"INFO","logger":"org.sonar.server.platform.web.MasterServletFilter","message":"Initializing servlet filter org.sonar.server.authentication.InitFilter@5fc4896c [pattern=UrlPattern{inclusions=[/sessions/init/*], exclusions=[]}]"}
{"process":"web","timestamp":"2023-08-17T09:50:58.001Z","severity":"INFO","logger":"org.sonar.server.platform.web.MasterServletFilter","message":"Initializing servlet filter org.sonar.server.authentication.SamlValidationRedirectionFilter@4

you can see


So what, should you ask ?

Issue is, when trying to parse the time, I have to set a time format using strptime strptime(3) - Linux man page

see also Configuring Parser - Fluent Bit: Official Manual

so I set : %Y-%m-%dT%H:%M:%S.%L%z

but … it will fail to parse 2023-08-17T09:50:58Z

Would be very nice to have .000 added in this situation.

Kind regards,

1 Like

Hi there @squalou,

Welcome to the community :partying_face:

From what we can gather, fluentbit utilizes the strftime(3) library, but as we saw in the official docs, fluentbit added functionality for supporting fractional seconds resolution (the %L format option):

In addition, we extended our time resolution to support fractional seconds like 2017-05-17T15:44:31*.187512963**Z*. Since Fluent Bit v0.12 we have full support for nanoseconds resolution, the %L format option for Time_Format is provided as a way to indicate that content must be interpreted as fractional seconds.

In addition, we observed that the strptime documentation allows for leading zeroes.

In case a number is to be matched, leading zeros are permitted but not required.

It seems that the addition of the %L parameter did not take into account the absence of leading zeroes, which is causing the issue.

Have you tried to reach out to fluentbit with this problem?

Kind Regards

1 Like


thank you for this analysis !

I’ll reach them asap with these info (I already have some other issues opened there :slight_smile: ),
and update here accordingly.

Also there may be an issue with the absence of dot. I’ll ask too.
(I mean : %S.%L without 0 the dot is also absent which in my case fails to match, but maybe I’m setting the pattern wrong)

Kind regards

You can check here

So far, a Ruby implem and a Golang implem fail to parse too when .000 is missing.
(using the Time.strptime for ruby)

Again, even if the “zeros” are optionnal, there is anyway still the issue of the separator (with is dot but could be comma). Missing separator will always fail to be parsed IMHO.

Hi there again @squalou,

Many thanks for taking this further with your bug tickets.

Upon further investigation on our side, we do feel that this is also a bug, hence this ticket being created.

Many thanks to you for bringing this up with us, and we hope to see you in the community again!



thank you !

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.