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
[AWS][RDS] Add metric type to fields #6094
Conversation
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
🌐 Coverage report
|
@@ -25,321 +25,422 @@ | |||
- name: rds | |||
type: group | |||
fields: | |||
- name: cpu.total.pct |
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.
this format is not working? any specific reason to change 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.
The format work, but the file has many fields and it was easier to group them and made changes this way @tetianakravchenko
type: group | ||
fields: | ||
- name: replicated_write_io.bytes | ||
metric_type: counter |
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.
so this value is not an aggregated value during some period of time, similar to other metrics? I thought cloudwatch always provides aggregated values
the same question regarding the data_transfer.bytes
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 problem with these metrics is that are only considered for a specific time window, like 15 minutes. So if we receive 2 documents, there is no guarantee that the most recent document will have a higher value for that field than the other. @tetianakravchenko
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.
And since we only receive a document after that time window (I think), there is no point in using counter since we never have values that relate to each other @tetianakravchenko
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.
shouldn't it then be a gauge
? instead of counter
? 🤔
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, I was making a case for gauge, I thought I had set it as such. But now I am confused on why I set this metric as a counter in the first place 😕
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 fixed it @tetianakravchenko to be a gauge
description: | | ||
The amount of network throughput both received from and transmitted to clients by each instance in the Aurora MySQL DB cluster, in bytes per second. | ||
- name: network_receive | ||
metric_type: gauge |
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.
if it is not an aggregated data, should it be counter then?
then same regarding network_transmit
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.
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
type: long | ||
format: bytes | ||
description: | | ||
The amount of available storage space. | ||
- name: maximum_used_transaction_ids | ||
metric_type: counter |
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.
could you please double-check if this should be a counter? sounds reasonable, based on the description, but just in case
type: long | ||
description: | | ||
The percentage of requests that are served by the Resultset cache. | ||
- name: engine_uptime.sec | ||
metric_type: counter |
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 same here: could you please double-check if this should be a counter? sounds reasonable, but just in case
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, I checked yesterday and I believe both are counter. @tetianakravchenko
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.
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.
hmm, strange to see this spike between 13:30 and 14:30, if this metric is suppose to monotonically increase, no? and why later value is not increasing?
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.
They are increasing @tetianakravchenko The difference between the previous value and the current value is always >0. I expressed myself wrongly, sorry for that. We see a huge spike because we received no values for some time (see the same visualization, this time including the empty rows):
So when we received the value at 14:xxh, the last one we had was the one from 13:xx, so there was a bigger difference.
Package aws - 1.38.1 containing this change is available at https://epr.elastic.co/search?package=aws |
* Add metric type. Signed-off-by: constanca-m <constanca.manteigas@elastic.co>
What does this PR do?
Add metric type to fields of RDS data stream, necessary to support TSDB in the future.
Details
Gauge and counter fields were defined based on:
Checklist
changelog.yml
file.How to test this PR locally
Refer to #6078
Related issues