-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Metricbeat][Kubernetes] Add metricset for state_namespace #36406
[Metricbeat][Kubernetes] Add metricset for state_namespace #36406
Conversation
@@ -238,7 +241,7 @@ func NewResourceMetadataEnricher( | |||
case *kubernetes.StatefulSet: | |||
m[id] = metaGen.Generate(StatefulSetResource, r) | |||
case *kubernetes.Namespace: | |||
m[id] = metaGen.Generate("namespace", r) | |||
m[id] = metaGen.Generate(NamespaceResource, r) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only concern is if we break sth here that we dont see.
My local tests are successful though and for eg. a pod has the namespace in it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it will break anything. We were following the same logic for all the case
and we haven't had a problem (at least yet).
But I notice that adding add_metadata
makes us loose the UUID. I checked for 2 metricsets: state_deployment
and this new one.
We get an object for every metricset that is like this:
"kubernetes":{
"deployment":{
"name":"same-name",
"uid":"9db79c06-db65-4081-923f-b78deb19eda7"
},
And then we overwrite the object again kubernetes.deployment
and we loose this data. I am using here state_deployment
as reference since that one is released, unlike state_namespace
.
)), | ||
}, | ||
|
||
Labels: map[string]p.LabelMap{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only label that I see in my tests:
kubernetes.labels.kubernetes_io/metadata_name : kube-node-lease
So not sure if this line works here or needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to get the name of the namespace, that is why I added the line. But I did notice that adding the add_metadata
leads to loss of data (the UUID). I will write about it on your the comment above.
@constanca-m some tests also failing. Please fix those. Apart from that the basic metrics are there:
|
I noticed, but running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice addition!
I have left some comments regarding some implementation details.
"created": { | ||
"sec": 1691566337 | ||
}, | ||
"name": "kube-node-lease", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think reporting the name here would be redundant since it will be added anyways by the metadata Enricher. However maybe you can added under kubernetes.namespace
directly and this would either be replaced by the Enricher or just remain there if the Enricher is disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, this is not true, because the kubernetes.namespace.name
gets overwritten. I explain why in this comment: #36406 (comment)
With the approach you suggested below, it works. I merged the change.
@@ -0,0 +1,23 @@ | |||
- name: state_namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer a name like namespace_state
which reflects that this section gives information related to the namespace's state. state_*
is quite an internal/elastic terminology and might not be so accurate/specific.
Note that I'm only referring to the fields' prefix and not the name of the metricset. The name of the metricset is just fine as is. But maybe we can improve the field's naming with what I mention.
@mlunadia do you have any preference here? state_namespace.*
VS namespace_state.*
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gizas since you were the one suggesting this name, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am also +1 for using namespace_state
as the object field name.
@constanca-m this looks good to me. The only change that would be nice is to use a more meaningful field name, which will not be confused with the data stream name. |
CHANGELOG-developer.next.asciidoc
Outdated
@@ -88,6 +88,7 @@ The list below covers the major changes between 7.0.0-rc2 and main only. | |||
|
|||
==== Added | |||
|
|||
- Add new metricset in Kubernetes module, `namespace_state`. {pull}36406[36406] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this comment #36406 (comment) was related only to the field name, where metrics are store kubernetes.state_namespace.*
- > kubernetes.namespace_state.*
, not to the name of the metricset itself.
I think that the state_*
in the metricset name is a reference to the metrics source - that they are scraped from the kube_state_metrics
, if it is correct module name should be state_namespace
for consistency. @MichaelKatsoulis @ChrsMark is my assumption regarding naming correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tetianakravchenko, you are right, I misunderstood. So now the document looks like this:
{
"@timestamp": "2019-03-01T08:05:34.853Z",
"event": {
"dataset": "kubernetes.namespace_state",
...
},
"kubernetes": {
"namespace": "kube-node-lease",
"namespace_state": {
...
}
},
"metricset": {
"name": "state_namespace",
...
},
...
}
I could not change the event.dataset
, I am not sure what this field means and elastic docs are not very clear either. I am guessing it is the "family" of fields that caused the metrics on the document.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think event.dataset
should be kubernetes.namespace
. I explain this at #36406 (comment). I'm not sure if that line there also has impact in other places but event.namespace
should be kubernetes.namespace
if we want to be more accurate.
- state_persistentvolume | ||
- state_persistentvolumeclaim | ||
- state_storageclass | ||
- state_namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems you pushed local changes for this file, could you please revert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Is it ok now with just state_namespace
added?
if resourceName != util.NamespaceResource { | ||
resourceName = strings.ReplaceAll(resourceName, prefix, "") | ||
} else { | ||
resourceName = "namespace_state" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the resource name should be namespace
so as to be used in event.dataset
properly. Potentially we could extend the metricset to also add other fields like namespace_foo
so just using namespace_state
for the dataset I think is not so correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am afraid that will break again because kubernetes.state
already exists 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that the value of event.dataset
should be set to namespace
. I think this would work since it's the value that we set so I don't see how it would be in conflict with anything else, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would create a conflict, because that field is setting the object kubernetes.namespace_state
. And if we change it to kubernetes.namespace
, this is the document that is generated (I just ran this):
{
"event": {
"dataset": "kubernetes.namespace",
"duration": 115000,
"module": "kubernetes"
},
"kubernetes": {
"namespace": {
"created": {
"sec": 1691566342
},
"status": {
"active": true,
"terminating": false
}
}
},
"metricset": {
"name": "state_namespace",
"period": 10000
},
"service": {
"address": "127.0.0.1:55555",
"type": "kubernetes"
}
},
Which will cause the conflict with the string field kubernetes.namespace
@ChrsMark
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to change the kubernetes.namespace_state
part. This can be as is.
I only suggest to change the value of event.dataset
. I guess it's doable to just set this specifically within the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could try that, but how do I set that field? I had a look at the code and:
e, err := util.CreateEvent(event, "kubernetes."+resourceName)
if err != nil {
m.Logger().Error(err)
}
between these lines, there is still not event.dataset
field.
The event
is {"_module":{"namespace":"kube-node-lease"},"created":{"sec":1693554126},"status":{"active":true,"terminating":false}}
(example) and e
is {{} {"namespace":"kube-node-lease"} {"created":{"sec":1693554126},"status":{"active":true,"terminating":false}} kubernetes.namespace_state 0001-01-01 00:00:00 +0000 UTC <nil> 0s 0s false}
(example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that we have change our minds here so many times, just changing event.dataset = kubernetes.namespace_state, breaks also the user experience that metrics that come from kube state metrics have the pattern:kubernetes.state_*
Just retested those and wanted to bring this to discussion once more. @elastic/obs-cloudnative-monitoring team any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey everyone, I don't want to block this PR but want to raise the concern of being blocked from using the I think that sooner or later we will hit this as part of the ECS-Otel merger as well -> https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/k8s/#namespace here it is an obejct already. So I wonder what is the long term plan with this and how we should approach this. @mlunadia @tommyers-elastic @gizas what do you think? What are our chances of introducing this breaking change and when it would be the right time to do it? |
@ChrsMark the tranformation of So for now I would say to merge this PR and to open the new story for changing the namespace to object for all kubernetes datasets. This will need documentation updates for our users. Also to add the note that when this new story will start, try to also align this new kubernetes.state_namespace and the work done here. So the new story to have a reference for this pr here @tommyers-elastic what do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully agree with adding sth that is not 100% future proof and just planning to revisit this in the future. If we add this now but we know it will change we will have users to deal with breaking changes even for this newly added metricset. I would see more value in dealing directly with the breaking changes now rather than adding just a metricset.
However approving since it's decided to proceed with the current naming formats.
Please file an issue about revisiting those and make sure to prioritize this.
Thanks @ChrsMark . Byt this,
Do you mean we should know take care of freeing |
I mean that with the current implementation of this metricset we will face an extra breaking change if we decide to change the fields' schema. So the |
* Add metricset. --------- Co-authored-by: Chris Mark <[email protected]> (cherry picked from commit 165d970)
The issue to change |
…6406) * Add metricset. --------- Co-authored-by: Chris Mark <[email protected]>
What does this PR do?
Add a new metricset,
state_namespace
, to the Kubernetes metricbeat module.You can all find the metrics available for it in here. We only fetch
kube_namespace_created
andkube_namespace_status_phase
in our metricset (both are stable metrics).Considerations
Unlike the other state metricsets, this one needs to have the
state_
prefix in the resource object. Example:kubernetes.state_deployment
adds akubernetes.deployment
object to the document;kubernetes.state_namespace
adds akubernetes.state_namespace
object. We do this becausekubernetes.namespace
already exists as a field. This way we cannot add a new object to the document with an already registered field of a different type. Otherwise, we will keep running into this error:Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
You can follow the instructions in this file.
Related issues
Relates to elastic/elastic-agent#3100.
Results
The source will be in ES as:
In Discover: