Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Units inconsistencies in logs #36896

Closed
ycombinator opened this issue Dec 20, 2018 · 5 comments
Closed

Units inconsistencies in logs #36896

ycombinator opened this issue Dec 20, 2018 · 5 comments
Labels
:Core/Infra/Logging Log management and logging utilities

Comments

@ycombinator
Copy link
Contributor

ycombinator commented Dec 20, 2018

Currently (master) in the Elasticsearch server log we see lines like these:

[2018-12-19T09:14:11,136][INFO ][o.e.m.j.JvmGcMonitorService] [es1_1] [gc][2375] overhead, spent [260ms] collecting in the last [1s]

Notice the durations in these lines, 260ms and 1s. Would it be possible to normalize the unit here, perhaps to ms? That would make parsing these durations a lot easier.

@ycombinator ycombinator added the :Core/Infra/Logging Log management and logging utilities label Dec 20, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

@jasontedor
Copy link
Member

I am not in favor of this. I think that Beats should aim to support the same units that Elasticsearch can output here, both for time values and for byte size values.

@ycombinator
Copy link
Contributor Author

Thanks Jason. Perhaps this issue becomes moot when #31244 is implemented?

@jasontedor
Copy link
Member

@ycombinator Yes, if we can reach agreement on how to proceed there. It would help with this issue though indeed as then these values could be mapped as duration types.

@jasontedor
Copy link
Member

@ycombinator Is it okay to close this issue then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Logging Log management and logging utilities
Projects
None yet
Development

No branches or pull requests

3 participants