adds duration_ms in int64 to the logs

[rhassanein]

• I added CHANGELOG entry for this change.
• Change is not relevant to the end user.

Motivation

Currently the logged lines contain a duration field that is encoded as a string with varying units. When ingesting these structured logs into a logging system (eg. elasticsearch), the field is parsed as a string which doesn't allow for range queries.

Example from v0.19.0:

{
      "ts": "2021-08-02T11:38:26.928570654Z",
      "cached": 23731,
      "duration": "2.09562852s",
      "tier": "sv",
      "stage": "main",
      "returned": 1567,
      "type": "monitoring",
      "component": "block.BaseFetcher",
      "msg": "successfully synchronized block metadata",
      "caller": "fetcher.go:476",
      "level": "info",
      "partial": 0
}

Adding a dedicated duration_ms integer field solves this problem.

Example:

{
      "duration": "2.09562852s",
      "duration_ms": "2095",
}

In order to avoid schema conflicts and introducing a breaking change, we're adding a new field rather than changing the existing one.

Changes

Adds an integer duration_ms to the logged lines with the duration field.

Verification

@igorwwwwwwwwwwwwwwwwwwww thanks for co-authoring this PR.

[GiedriusS]

This is interesting, I would've just changed duration to always use a fixed unit but this works too and makes sense 🤗 thx

[GiedriusS]

Please rebase your branch on the latest main, the tests should be fixed there.

[rhassanein]

@GiedriusS thanks for reviewing this! I just added a CHANGELOG entry and attempted a main rebase, hopefully that fixes the tests.

[bwplotka]

Thank you!

[vanugrah]

Sweet! I was just thinking about this :D