Skip to content
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

[Kibana Module] Add additional metric fields #6746

Merged
merged 1 commit into from
May 25, 2018

Conversation

tsullivan
Copy link
Member

@tsullivan tsullivan commented Apr 3, 2018

Adds a new Kibana module for stats. This is based on the existing status module, which will be deprecated in Kibana once stats becomes established.

Depends on elastic/kibana#17773

@tsullivan tsullivan requested a review from ruflin April 3, 2018 17:49
@tsullivan
Copy link
Member Author

This is a work-in-progress change as it'll need some extra work after this first commit to implement the schema I'm going for:

  • avg_in_millis is sometimes an integer, and sometimes a null value. If there were no requests in the measurement window, then the value is null
  • requests.status_codes is a dictionary with keys for the status code. Only the status codes that have been measured in the window are present as keys.
    • Example:
      "requests": {
         "total": 3,
         "disconnects": 0,
         "status_codes": {
            "200": 3
         }
      }
      

These need to be handled in the schema to avoid error log messages. Advice is welcome! :)

@ruflin
Copy link
Member

ruflin commented Apr 3, 2018

To make certain fields optional, you can pass an optional flag. See here for an example: https://github.com/elastic/beats/blob/master/metricbeat/module/apache/status/data.go#L22

Also metricbeat tests will required you to document the new fields here (https://github.com/elastic/beats/blob/master/metricbeat/module/kibana/status/_meta/fields.yml) and then run make update.

@ruflin ruflin added in progress Pull request is currently in progress. module Metricbeat Metricbeat labels Apr 3, 2018
}
)

type OverallMetrics struct {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exported type OverallMetrics should have comment or be unexported

@tsullivan
Copy link
Member Author

To make certain fields optional, you can pass an optional flag

I'm going to ensure that all the fields are predictable by the API, so I won't really need to do this.

Also metricbeat tests will required you to document the new fields here

Thanks for the tip. I made some changes and ran make update

},
"kibana": {
"stats": {
"cluster_uuid": "G279hqGeSDqjj_OgBq6wUw",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is the elasticsearch cluster uuid, we should put it under elasticsearch.cluster.id as we do in other events. This makes it possible to correlate all events from one cluster. I can take care of that in a follow up PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would affect the Kibana PR as well as this one, so wouldn't it make sense to do this before merging, to reduce the follow-up needed?

The Kibana PR still depends on another one that no one has had time to review yet, so we still have some time to adjust the data structure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if I'm wrong about this affecting the Kibana PR. Maybe as an alternative the solution is to map incoming cluster_uuid value to elasticsearch.cluster.id in metricbeat/module/kibana/stats/data.go? If yes, then I'd agree to taking care of it in a followup PR.


// New create a new instance of the MetricSet
func New(base mb.BaseMetricSet) (mb.MetricSet, error) {
cfgwarn.Beta("The kibana metricset is beta")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have an interesting case here we haven't had in Beats so far, that we release a metricset for an endpoint which is not available yet.

Is the stats endpoint going into 6.4?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's planned for 6.4: elastic/kibana#17773

"state": c.Str("state"),
}),
}),
"uptime_in_millis": c.Int("uptime_in_millis"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should follow our metricbeat conventions here for the units: https://www.elastic.co/guide/en/beats/devguide/current/event-conventions.html

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my clarity, you're suggesting that the change would just be a naming switch in this file, correct?

"uptime_in_millis": c.Int("uptime_ms"),

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a65066bb2

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this idea wouldn't work:

2018-04-23T17:44:15.601-0700    ERROR   schema/schema.go:41     Error on field 'uptime_in_millis': Missing field: uptime_in_millis, Error: Key uptime_ms not found
2018-04-23T17:44:15.601-0700    ERROR   schema/schema.go:41     Error on field 'avg_in_millis': Missing field: avg_in_millis, Error: key avg_ms not found
2018-04-23T17:44:15.601-0700    ERROR   schema/schema.go:41     Error on field 'max_in_millis': Missing field: max_in_millis, Error: Key max_ms not found

@ruflin is there a way we can pivot on the naming within the beat module? It would help us avoid some messy work in Kibana around not introducing breaking API changes.

fields:
- name: free_in_bytes
type: long
description: >
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the bytes you can add format: bytes so the Kibana index pattern will automatically contain the unit.

@ruflin
Copy link
Member

ruflin commented Apr 23, 2018

@tsullivan There seems to be a panic in the tests at the moment, probably because metrics or something that you access doesn't exist in the event.

I suggest we get this PR in as soon as the stats endpoint is merged in Kibana and then can do follow up PR's to clean up the naming and add integration tests with the actual endpoints.

@tsullivan
Copy link
Member Author

then can do follow up PR's to clean up the naming and add integration tests with the actual endpoints.

Sounds good to me. I will remove the added integration tests for now.

The feedback around naming looks like things I should work on in elastic/kibana#17773 and then update here to reflect the change before anything gets merged. What do you think?

@ruflin
Copy link
Member

ruflin commented Apr 24, 2018

@tsullivan For the naming: We could follow the same approach here as we do with the ES endpoints to have an XPack version and a MB version data structure for the next 6.x release. Like this the naming in Kibana is consistent and we can still follow the MB naming scheme to be in line with all other endpoints.

I'm also ok to get it in with the Kibana naming so I can add it as being X-Pack in a follow up PR and add the MB naming part.

@tsullivan
Copy link
Member Author

elastic/kibana#17773 is merged, making this PR testable against the master branch of Kibana!

@ruflin
Copy link
Member

ruflin commented May 2, 2018

@tsullivan That is great. We need to modify the testing somehow as so far all metricbeat modules are tested against stable releases. But @jsoriano introduced for other modules to test it against multiple versions which we can also do for Kibana. Main difference is that we will have to build our own image here (or reuse the one from testing/environments). CI will probably not very happy as Kibana takes forever to start and 2 instances makes it worse, but it should work. @tsullivan Let me see how we can make that happen in the repo and then rebase this PR on top of it.

@tsullivan
Copy link
Member Author

@tsullivan Let me see how we can make that happen in the repo and then rebase this PR on top of it.

Sounds like a plan. Let me know when this branch should be rebased.

}
)

type OverallMetrics struct {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exported type OverallMetrics should have comment or be unexported

@@ -0,0 +1,220 @@
package node_stats

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't use an underscore in package name

@@ -0,0 +1,12 @@
package add_host_metadata

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't use an underscore in package name

@ruflin
Copy link
Member

ruflin commented May 23, 2018

Ready for a first round of reviews. Tests are currently only run against a file as 6.4 is not out yet. It would be possible to add an additional Kibana version to our test env but already 1 instance of KB puts enough load on our test environment and it would also require an additional version of ES for compatibility.

@ruflin ruflin requested a review from jsoriano May 23, 2018 12:40
@@ -0,0 +1,32 @@
package kibana
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move common testing code to kibana/mtest as discussed in #7106 (comment)?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

return map[string]interface{}{
"module": "kibana",
"metricsets": []string{metricset},
"hosts": []string{GetEnvHost() + ":" + GetEnvPort()},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

net.JoinHostPort() :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed. We have this all over the place. Probably time to extract this method more generic.

This is based on the existing `status` module, which will be deprecated in Kibana once `stats` becomes established. The stats endpoint will be available in Kibana 6.4 and newer.
@jsoriano jsoriano merged commit 8fa913c into elastic:master May 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants