[metricbeat] Add creation timestamp to state_persistentvolumeclaim metricset

[barkbay]

This PR is an attempt to include the creation timestamp for PersistentVolumeClaim resources, as introduced in kubernetes/kube-state-metrics#1741:

# HELP kube_persistentvolumeclaim_status_condition Information about status of different conditions of persistent volume claim.
# TYPE kube_persistentvolumeclaim_status_condition gauge
# HELP kube_persistentvolumeclaim_created Unix creation timestamp
# TYPE kube_persistentvolumeclaim_created gauge
kube_persistentvolumeclaim_created{namespace="project-a683325324224314ad460a8768a1c481",persistentvolumeclaim="es-es-search-88f7d645f-2m8fb-elasticsearch-data"} 1.699866923e+09

This is my very first PR to add a field in Metricbeat, so please be indulgent 😄

Proposed commit message

[metricbeat] Add creation timestamp to state_persistentvolumeclaim metricset

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.

Author's Checklist

• I still have to test it on my dev cluster.

How to test this PR locally

Related issues

n/a

Use cases

We need the creation timestamp in order to trigger alerts for Pending volumes bases on their creation timestamps.

[botelastic]

This pull request doesn't have a Team:<team> label.

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @barkbay? 🙏.
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

[MichaelKatsoulis]

Isn't this file created automatically ? I wonder why indentation is wrong.

[barkbay]

Isn't this file created automatically ? I wonder why indentation is wrong.

Sorry, It is very likely that I did something wrong during my tests, I'm still trying to familiarize myself with the unit tests in this package. Could you explain me what command is supposed to generate this file? 🙇

[constanca-m]

You can go to the metricbeat/module/kubernetes/state_persistentvolumeclaim directory and just run on the terminal:

go test -data

That should generate all the expected files.

[barkbay]

Thanks a lot @constanca-m , last commit includes the files generated by go test -data

[MichaelKatsoulis]

We collect the creation time in other metricsets of kubernetes module as well. See state_service, state_job and state_storageclass. In all those cases we use

"kube_service_created":                      p.Metric("created", p.OpUnixTimestampValue()),

which transforms the seconds in a unix timestamp and declare the field as date. See

beats/metricbeat/module/kubernetes/state_service/_meta/fields.yml

Line 31 in 9f93f93

- name: created

I would suggest to do the same here and name the new filed created instead of created.sec

[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: 2023-11-13T14:01:36.999+0000

• Duration: 48 min 22 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4473
Skipped	902
Total	5375

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the 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!)

[barkbay]

I haven't looked at how to test it yet. I'm using Agent, not sure about the simplest way to do that 😕

• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Let me know which one should be updated.

[constanca-m]

I haven't looked at how to test it yet. I'm using Agent, not sure about the simplest way to do that

We have a README file on how to test this @barkbay

[MichaelKatsoulis]

Thanks @barkbay for adding this. We should add the new field in the integration data stream as well. But it should happen after the FF of beats.