-
Notifications
You must be signed in to change notification settings - Fork 392
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
[Ceph] Add Integration Package with OSD Pool Stats data stream #5128
[Ceph] Add Integration Package with OSD Pool Stats data stream #5128
Conversation
/test |
🌐 Coverage report
|
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.
LGTM!
fields: | ||
- name: bytes | ||
type: long | ||
description: Number of client I/O rates write bytes per second. |
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.
Please change it to write rates
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.
Just to clarify, Do we need to update description as Number of client I/O rates write bytes per second.
-> Number of client I/O write rates bytes per second.
?
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.
Number of client I/O write rates in bytes per second
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.
Got it. Will update wherever applicable. Thanks!
description: Number of client I/O rates write bytes per second. | ||
metric_type: gauge | ||
unit: byte | ||
- name: operation.count |
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.
Suggest to use operation_count as there exist no more than 1 fields under operation group
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 are following Elastic best practice while doing field mappings. Hence we have added count suffix wherever it's applicable. Final json structure would be like ceph.osd_pool_stats.client_io_rate.write.operation.count
. Let me know if it looks good to you!
- name: id | ||
type: long | ||
description: Pool ID. | ||
- name: name |
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.
suggest to rename as pool_name
and pool_id
- name: read | ||
type: group | ||
fields: | ||
- name: 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.
It may be best to change to write.byte to write.rate_per_sec , read.byte to read.rate_per_sec. This is following the convetion in oracle.sysmetric fields mapping
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.
Based on your suggestions, final output will be ceph.osd_pool_stats.client_io_rate.write.rate_per_sec
that is making rate
redundant. I guess currently it is the best structure that provides the IO rates and in group only. So readability also increase as per the current json event structure. I see in oracle.sysmetric no json structure is form eventhough we can. According to me, The current best json structure for the user is ceph.osd_pool_stats.client_io_rate.write.bytes
and same is applicable for the field read.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.
You may consider changing from ceph.osd_pool_stats.client_io_rate -> ceph.osd_pool_stats.client_io, if there are no constraints
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.
Instead of updating ceph.osd_pool_stats.client_io_rate -> ceph.osd_pool_stats.client_io, We can update ceph.osd_pool_stats.client_io_rate
-> ceph.osd_pool_stats.client_io_rate_per_sec
, Because all the client_io_rate are descripted as per_sec
. So the updating field mapping will be like ceph.osd_pool_stats.client_io_rate_per_sec.read.bytes
. WDYT?
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.
Go with removing operation.
from everywhere. This would solve all the problems.
Every IO is an operation. So, no need to use it anywhere
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.
Keep rest as it is.
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.
Are you sure we should not keep the operation.
in field mapping? I guess it is not creating any problems based on current structure. I/O can be operation, device, program anything. According to me its seems fine to callout operation
separately.
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, please go ahead removing 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.
LGTM
Package ceph - 0.3.0 containing this change is available at https://epr.elastic.co/search?package=ceph |
What does this PR do?
Checklist
How to test this PR locally
elastic-package test
Related issues