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

Store Message receive and processing times #18150

Merged
merged 11 commits into from
Feb 14, 2024

Conversation

mpfz0r
Copy link
Contributor

@mpfz0r mpfz0r commented Feb 2, 2024

With #6022 we've started recording per-message receive and processing timestamps.
We didn't add those timestamps as message fields, because we wanted to make sure every index
has a proper datetime format mapping for those fields.

With a bit of delay 😏 we can finally store those fields on each Message.

Fixes #16284

Refs #16163

Forwarder support: https://github.com/Graylog2/graylog-plugin-enterprise/pull/6560

With #6022 we've started recording per-message receive and processing
timestamps.  We didn't add those timestamps as message fields, because
we wanted to make sure every index has the new mapping for those fields.

Fixes #16284
This seems to be more useful to create dashboards
that show the processing performance of various Messages in Graylog.
@mpfz0r
Copy link
Contributor Author

mpfz0r commented Feb 5, 2024

@Graylog2/architecture

I'm wondering if the timestamp fields are actually that useful.
Wouldn't it be better to just store the processing duration instead?
See
e02943f

@bernd
Copy link
Member

bernd commented Feb 5, 2024

@Graylog2/architecture

I'm wondering if the timestamp fields are actually that useful. Wouldn't it be better to just store the processing duration instead? See e02943f

@mpfz0r I think the timestamp fields have their use cases. I agree that the duration is better for dashboards since we can't compute any values in our queries, AFAIK.

We can store the duration as well. Let's call it gl2_processing_duration_ms though.

The new field needs to be added to our index templates. If we don't want to wait again until everyone has the field, we need a migration step that adds the field to all active write indices.

@mpfz0r
Copy link
Contributor Author

mpfz0r commented Feb 5, 2024

@Graylog2/architecture
I'm wondering if the timestamp fields are actually that useful. Wouldn't it be better to just store the processing duration instead? See e02943f

@mpfz0r I think the timestamp fields have their use cases. I agree that the duration is better for dashboards since we can't compute any values in our queries, AFAIK.

Doing that on the fly would involve a painless scripted query, not ideal, no.

We can store the duration as well. Let's call it gl2_processing_duration_ms though.

Ack 👍

The new field needs to be added to our index templates. If we don't want to wait again until everyone has the field, we need a migration step that adds the field to all active write indices.

Is that necessary? The field will automatically be detected as a numerical value.

@bernd
Copy link
Member

bernd commented Feb 5, 2024

Is that necessary? The field will automatically be detected as a numerical value.

@mpfz0r Ah right, it's not a date field like the other two. 👍

Storing `gl2_processing_duration_ms` as an integer is good enough and
will save some space.
@mpfz0r mpfz0r marked this pull request as ready for review February 5, 2024 11:14
@mpfz0r mpfz0r requested review from bernd and a team February 5, 2024 11:14
We don't use expected_gim_template7.json anymore.
Copy link
Contributor

@kodjo-anipah kodjo-anipah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM processing time, processing duration & receiving time are all there

@mpfz0r mpfz0r merged commit 714eda6 into master Feb 14, 2024
9 checks passed
@mpfz0r mpfz0r deleted the store-msg-receive-and-processing-times branch February 14, 2024 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Store message receive and processing times in OS / ES
3 participants