[Metricbeat] Fix fields not being parsed correctly in postgresql/database

[sayden]

What does this PR do?

Fix postgresql.database.blocks.time.read.ms and postgresql.database.blocks.time.write.ms being captured and reported as a long instead of double thus not being reported at all.

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

• Closes [Metricbeat] [PostgreSQL] module [database] metricset - wrong mapping for blk_read_time and blk_write_time #25301

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Duration: 87 min 57 sec

❕ Flaky test report

No test was executed to be analysed.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[jsoriano]

Please, double check if this change is problematic in a deployment with both versions of Metricbeat, we had recently some bad experiences with type changes that looked safe.

The kind of test you could do is:

• Install Metricbeat 7.15 and create a visualization using this field (even if it is zero).
• Double-check that you have a metricbeat-* index pattern where this field appears.
• In the same deployment, update to Metricbeat with this fix, and check if there is any problem with the visualization or with the index pattern.

[jsoriano]

cc @kaiyan-sheng

[kaiyan-sheng]

Yeah please double check here 😂 Not sure if it's the same case but I accidentally made a breaking change for changing field type from scaled float to long.

[ruflin]

Should this also be backported to 7.16?

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b bugfix/postgresql/fix-bulk_read_write-values upstream/bugfix/postgresql/fix-bulk_read_write-values
git merge upstream/master
git push upstream bugfix/postgresql/fix-bulk_read_write-values

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b bugfix/postgresql/fix-bulk_read_write-values upstream/bugfix/postgresql/fix-bulk_read_write-values
git merge upstream/master
git push upstream bugfix/postgresql/fix-bulk_read_write-values

[jlind23]

@sayden what should we do with this PR?

[mergify]

This pull request does not have a backport label. Could you fix it @sayden? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[ruflin]

I removed the backport labels on this PR to make sure it doesn't get backported to any old branches by accident. We can add backport labels when this gets merged.

[ruflin]

For the PR itself, lets get this over the line as it is valuable fix.

[ishleenk17]

@kaiyan-sheng @jsoriano :
This issue was brought up recenlty by a support engineer.
Any reason why this was not merged, if you might remember the history here ?
Looks like a customer is facing an issue due to this.

[jsoriano]

@ishleenk17 looking to the comment history only some testing and the decision to backport was pending, change looks good and valuable for the rest. Not sure why this was closed. Feel free to take it over and complete it.

[PBoff]

@jsoriano and @ishleenk17 - Do we have any timelines for this?.

[PBoff]

@jsoriano and @ishleenk17 - Do we have any timelines for this?.

[ishleenk17]

@kush-elastic : Could you please share the latest on this ?

[kush-elastic]

I have started working on this. I will post the results of my findings soon.
There are some scenarios I need to verify for post change as discussed with @ishleenk17.
Thanks

[kush-elastic]

@PBoff and @ishleenk17,
I have raised PR with changes and verified the scenarios presented before. Let's wait for the PR to be reviewed and merged.
Here's PR Link.