[Oracle Module] New sysmetric metricset

[yug-rajani]

• Enhancement

What does this PR do?

Create a new sysmetric metricset to complement the current performance one.

Why is it important?

What Oracle DBAs usually do is actually pull the pre-calculated metrics from the V$SYSMETRIC table (called System View). DBAs usually need around 10 out of these 200+ metrics and Oracle will keep adding more metrics to this table in the future, so, there has to be a way to dynamically filter in or query only those that are suggested by the user with the help of a keyword or Regex.

Checklist

• My code follows the style guidelines of this projects
• 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 [Oracle Module] New sysmetric metricset #30946

Screenshot

[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

• Start Time: 2022-06-14T04:26:10.826+0000

• Duration: 74 min 58 sec

Test stats 🧪

Test	Results
Failed	0
Passed	3865
Skipped	993
Total	4858

💚 Flaky test report

Tests succeeded.

🤖 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!)

[cmacknz]

You'll need to add a CHANGELOG entry for this.

I'm not very familiar with this code. The commit history (https://github.com/elastic/beats/commits/main/x-pack/metricbeat/module/oracle) suggests @sayden would be a good reviewer here.

[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 oracle_sysmetric_metricset upstream/oracle_sysmetric_metricset
git merge upstream/main
git push upstream oracle_sysmetric_metricset

[kush-elastic]

There are few nits from my side and there are few methods that can be explained a bit using comments. So others can easily understood the workflow.
Else LGTM!

[agithomas]

Second part of the requirement is as below.

Another problem with the queries used by the metricbeat module is that they don’t account for the rack installations. If there is a rack-installation, metricbeat is not going to provide correct results, because nobody knows whether the data reported is from the current node that you connected to or is an average across all nodes in the rack.

How this requirement is met?

[yug-rajani]

Second part of the requirement is as below.

Another problem with the queries used by the metricbeat module is that they don’t account for the rack installations. If there is a rack-installation, metricbeat is not going to provide correct results, because nobody knows whether the data reported is from the current node that you connected to or is an average across all nodes in the rack.

How this requirement is met?

We have covered all the points mentioned as a part of solution in the PRD.

If we refer to the V$SYSMETRIC table documentation here, there is no field which can help us in identifying the node from which the data is reported. We also verified the metrics and units from the output of sysmetric table, but could not find an identifier. So, it does not seem to be possible to cover that as a part of sysmetric metricset.

Do you have any ideas over it?

[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 oracle_sysmetric_metricset upstream/oracle_sysmetric_metricset
git merge upstream/main
git push upstream oracle_sysmetric_metricset

[agithomas]

Second part of the requirement is as below.
Another problem with the queries used by the metricbeat module is that they don’t account for the rack installations. If there is a rack-installation, metricbeat is not going to provide correct results, because nobody knows whether the data reported is from the current node that you connected to or is an average across all nodes in the rack.
How this requirement is met?

We have covered all the points mentioned as a part of solution in the PRD.

If we refer to the V$SYSMETRIC table documentation here, there is no field which can help us in identifying the node from which the data is reported. We also verified the metrics and units from the output of sysmetric table, but could not find an identifier. So, it does not seem to be possible to cover that as a part of sysmetric metricset.

Do you have any ideas over it?

You may check V$INSTANCE database view

[yug-rajani]

Hey @agithomas, we have made all the changes as per your suggestions and discussion over the sync. We are looking into the parameter CON_ID by doing some hands-on with the Oracle Database. We will get back to you with our analysis over the same soon and we can agree upon something after discussing with the team.

Please feel free to review the rest of the PR and let us know if you have any other suggestions/feedback.

Update (06/08/2022):
Discussed to go with the existing implementation and not collect the CON_ID field as it does not seem to suffice our requirement of knowing from where the data is being reported.
CC: @akshay-saraswat

@agithomas, this PR is ready for review. All the existing review comments have been addressed. Please take a second round of review for the PR at your convenience.

[agithomas]

LGTM

Blocked because of the requested change. This however is addressed : Explnataion : As a part of this enhancement, we had to map the fields dynamically as mentioned in the PRD. Your point makes sense, we can add a function to transform the field names dynamically to snake case to follow the Elastic naming conventions. But because of the dynamic mapping, it does not seem feasible to group the fields.