Normalize AWS RDS CPU Utilization values before metadata API call

[gpop63]

Overview

We should normalize CPU Utilization values before making the metadata API call. Normalizing these metric values before, ensures that they are correctly scaled regardless of the API call outcome.

Bug noticed by @agithomas

When the API call fails the CPU Utilization value is left untransformed and metadata (db_instance.*) is missing as expected.

Normalization successful

"rds": {
        "write": {
          "iops": 32.992212962548756
        },
        "database_connections": 202.5,
        "disk_queue_depth": 3.8251273585859344,
        "latency": {
          "read": 0.000597923599665421,
          "write": 0.001494035012286908
        },
        "freeable_memory": {
          "bytes": 24291670016
        },
        "free_storage": {
          "bytes": 1936544964608
        },
        "read": {
          "iops": 6147.187137265246
        },
        "throughput": {
          "network_receive": 382272.82916163537,
          "network_transmit": 12146763.734239174,
          "read": 211789547.4894744,
          "write": 276755.216951128
        },
        "swap_usage": {
          "bytes": 4340457472
        },
        "db_instance": {
          "class": "db.r5.4xlarge",
          "engine_name": "oracle-ee",
          "arn": "arn:aws:rds:eu-west-1:x:db:prod-zonda-mea-master",
          "status": "available",
          "identifier": "prod-zonda-mea-master"
        },
        "cpu": {
          "total": {
            "pct": 0.141125
          }
        }
      },

Normalization failed

      "rds": {
        "latency": {
          "write": 0.00373913188801891,
          "read": 0.0033277979724311226
        },
        "swap_usage": {
          "bytes": 4340457472
        },
        "disk_queue_depth": 29.583544356294787,
        "freeable_memory": {
          "bytes": 24227618816
        },
        "database_connections": 205,
        "free_storage": {
          "bytes": 1936431253504
        },
        "read": {
          "iops": 8572.673917114498
        },
        "throughput": {
          "read": 407276872.41836303,
          "write": 2831619.3420464424,
          "network_receive": 422334.8679408032,
          "network_transmit": 29206122.435347874
        },
        "write": {
          "iops": 153.26444758516493
        },
        "cpu": {
          "total": {
            "pct": 15.412756538452992
          }
        }
      }

Checklist

• 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.

Disruptive User Impact

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @gpop63? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[agithomas]

LGTM!

[agithomas]

@elastic/obs-ds-hosted-services can you please look into the PR when you get some time?

[zmoog]

Good catch @agithomas! LGTM.