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

Httpmetricbeat #4092

Closed

Conversation

christiangalsterer
Copy link
Contributor

Hi @ruflin,

here a very first commit.
There are no tests yet and I haven't run manual tests.

Actually I get a strange error when trying to run metricbeat and also in some tests, that the process are immediately killed, e.g. with "Killed: 9".

I'm running on Mac with golang 1.7.4 and my other beats are running fine. Are there any special settings needed for metricbeat on a mac?

Shall I open an issue for tracking/reference for the new metricbeat?

@elasticmachine
Copy link
Collaborator

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run.

1 similar comment
@elasticmachine
Copy link
Collaborator

Jenkins standing by to test this. If you aren't a maintainer, you can ignore this comment. Someone with commit access, please review this and clear it for Jenkins to run.

@christiangalsterer
Copy link
Contributor Author

Forget about my comment on build issues. It is solved by updating to gaoling 1.8.1 (should have checked beforehand).

@ruflin
Copy link
Member

ruflin commented Apr 23, 2017

I had a similar issue with 1.8 which is a golang/ os x issue. 1.8.1 should solve it.

http := helper.NewHTTP(base)
http.SetMethod(config.Method)
http.SetBody([]byte(config.Body))
for key, value := range config.Headers {
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, saw that as well, but then forgot to change before committing.

Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the contribution. I'm really looking forward to have the http module as part of metricbeat.

I left a few comments below. Could you also add an entry in the CHANGELOG.asciidoc?


event := common.MapStr{}

event["request"] = common.MapStr{
Copy link
Member

Choose a reason for hiding this comment

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

As these are based on the configs set, not sure if we should really add the request to each document. What would be the use case here?

// Part of new is also setting up the configuration by processing additional
// configuration entries if needed.
func New(base mb.BaseMetricSet) (mb.MetricSet, error) {

Copy link
Member

Choose a reason for hiding this comment

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

Could you add here a log message like logp.Beta("The http json metricset is in beta.").

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes will do.

type MetricSet struct {
mb.BaseMetricSet
http *helper.HTTP
headers map[string]string
Copy link
Member

Choose a reason for hiding this comment

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

In case we do not add these fields (see comment below) to the event, they are probably not needed in the object.

"body": responseBody,
}

return event, nil
Copy link
Member

Choose a reason for hiding this comment

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

The json metricset is a dynamic metricset. That means it can be used multiple times with different fields as output. To make sure these fields to not conflict, we need a namespace which can be configure. As an example see here the jmx metricset: https://github.com/elastic/beats/blob/master/metricbeat/module/jolokia/jmx/jmx.go#L93 So event are put into http.namespace.*.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True, thanks for the hint. Is namespace here the correct concept, or is it to use different document_types?

Copy link
Member

Choose a reason for hiding this comment

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

Namespace is the one to use here. We don't use document type, especially as it will be removed in 6.0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, will make the changes accordingly.

event["response"] = common.MapStr{
"status_code": response.StatusCode,
"headers": m.getHeaders(response.Header),
"body": responseBody,
Copy link
Member

Choose a reason for hiding this comment

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

As this is JSON, don't we need to decode it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes definitely.

Copy link
Member

Choose a reason for hiding this comment

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

One more note on the body: I would probably put the decode json directly on the top level and not into a body namespace.


event["response"] = common.MapStr{
"status_code": response.StatusCode,
"headers": m.getHeaders(response.Header),
Copy link
Member

Choose a reason for hiding this comment

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

As status_code and response header will be the same for all http metricsets, I was thinking to add these on the module lever for example under a response namespace. How to do that for example see docker: https://github.com/elastic/beats/blob/master/metricbeat/module/docker/cpu/data.go#L18

That would mean these are always under http.response.*.

I'm not sure if we should enable the headers by default because in the case of json I assume in most use cases people are not too interested in the headers (happy to be convinced otherwise). So I would make it configurable with a config option. As we already have headers in the config file, we could make it response.headers.enabled.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is definitely room for improvement to move some of the information to the module layer. Idea was to get something working and getting familiar with Metricbeat implementation.
W.r.t if we should add the header I don't see an issue here to always add them

Copy link
Member

Choose a reason for hiding this comment

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

Happy to merge the PR rater soonish and do improvements on top of it.

For the headers, I probably miss the use case.

@ruflin ruflin added in progress Pull request is currently in progress. Metricbeat Metricbeat module review labels Apr 24, 2017
ruflin and others added 13 commits April 24, 2017 09:54
Update of the Contributing guide was missed in elastic#4033.
This allows if a second request is needed with a different path in a metricset to reuse the http helper and hostparser and only overwrite the path temporarly.
In some cases, a metricset does not return an event but also not an error. This can be the case if a metricset for a distributed system should only send events for the master. All metricbeat instances are running on all nodes, but only one node should send the events and the other skip the event. This changes makes this behaviour possible.
Fix race in go-metrics adapter, if registry is updated concurrently from
multiple go routines.
…issue#199

Warn Beats users not to do multiline handling in Logstash
* Rename package name, packages in add_could_metadata and add_locale
should follow the name of their current folder
Add perfmon raw counter values calculations

This PR adds functions to calculate performance counters from raw values. These functions should serve more as internal apis.
* Remove kibana from the short config and comment it out by default
* Move kubernetes processor to root processors folder
 * Restart watch call on error
 * Flag kubernetes proccesor as beta
 * Fix config validation for `in_cluster` cases
 * Add kubernetes metadata fields
 * Put kubernetes processor fields under a common namespace
…elastic#4102)

* Adding query APIs for metricsets and modules from metricbeat registry
* Added locking to make `mb.Register` thread-safe.
Expand double wildcards into standard glob patterns, up to a maximum
depth of 8 levels after the wildcard.

Resolves elastic#2084
athom and others added 14 commits April 27, 2017 09:27
…stic#4111)

* Support Alibaba Cloud provider for add_cloud_metadata processor
* Add note for Alibaba Cloud provider in add_cloud_metadata processor documentation.
See PR elastic#4091 for detailed list of event format changes and sample events.

- export transport.DialWith
- update heartbeat look:
  - add look.Status
  - add some missing godoc
- rewrite heartbeat dialchain package
  - simplify package
  - have connection layers add standardized connection data to the final event
  - add some more helpers
  - add some godocs
- update event format. See PR elastic#4091
- add more detailed duration measure to HTTP module
- update job settings
  - introduce explicit structs for job settings
  - job settings can contain static monitor fields to be added to every event
  - helpers can add more static monitor fields to settings
- update fields.yml structure
- update kibana dashboard
Add community beats topic to devguide
Added first request/event
Added first request/event
added first config for testing
Moved fields to modules
Update (some) documentation

Open:
- complete documentation
# Conflicts:
#	metricbeat/docs/modules/http.asciidoc
#	metricbeat/module/http/_meta/config.yml
#	metricbeat/module/http/_meta/fields.yml
#	metricbeat/module/http/json/_meta/fields.yml
#	metricbeat/module/http/json/json.go
@christiangalsterer
Copy link
Contributor Author

'make collect' doesn't seem to update the generated doc files (anymore). I did already a fresh clone, but no luck. This is why the "make check" currently fails ans the docs don't match anymore.

@christiangalsterer
Copy link
Contributor Author

intellij had some refresh issues causing some bad merges/rebases. I will fix that later today, sorry for any inconveniences caused by this.

@ruflin
Copy link
Member

ruflin commented Apr 30, 2017

use make update instead of make collect

@christiangalsterer
Copy link
Contributor Author

Thanks for the quick reply. If you want to to create a new PR as the current is cluttered with merge commits I'm happy to do so.

I will add more documentation later today. In any case thanks for any review comments in advance.

@ruflin
Copy link
Member

ruflin commented Apr 30, 2017

will probably not be able to review it today. you could also squash the commits and the force push to the sam branch.

@christiangalsterer
Copy link
Contributor Author

sure no problem, enjoy the long weekend. Will also squash the changes into a single commit

@christiangalsterer
Copy link
Contributor Author

I added PR #4155 for the confusion on make collect vs make update.

@ruflin
Copy link
Member

ruflin commented May 1, 2017

@christiangalsterer Any chance to push the squashed changes? Right now it is kind of tricky to review as the diff is huge because of all the merges. Probably you also have to rebase on master. As you merged previously I worry that you will have quite a few conflicts :-( In general I recommend to always rebase on master and not merge master.

@christiangalsterer
Copy link
Contributor Author

@ruflin: Sure thing. Will squash the changes and I always use rebase normally, but somehow IntelliJ played some bad tricks ;-)

@christiangalsterer
Copy link
Contributor Author

Actually maybe I close this PR and create a new one, to have a cleaner state, would you be ok with this?

@ruflin
Copy link
Member

ruflin commented May 1, 2017

sure, feel free to open a new one.

@christiangalsterer
Copy link
Contributor Author

Replaced by #4156.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in progress Pull request is currently in progress. Metricbeat Metricbeat module review
Projects
None yet
Development

Successfully merging this pull request may close these issues.