Skip to content

Update http and url ECS fields - #1813

Merged
jalvz merged 1 commit into
elastic:masterfrom
jalvz:ecs-http
Jan 24, 2019
Merged

jalvz merged 1 commit into
elastic:masterfrom
jalvz:ecs-http

Conversation

@jalvz

@jalvz jalvz commented Jan 18, 2019 •

Copy link
Copy Markdown
Contributor
  • loosen intake API for URL port to accept strings and numbers
  • add more tests and make sure to exercise all the fields

This includes all non indexed fields.

Fixes #1752

@jalvz

jalvz commented Jan 18, 2019

Copy link
Copy Markdown
Contributor Author

Missing a few unit tests, putting it up for early review

@jalvz

jalvz commented Jan 18, 2019

Copy link
Copy Markdown
Contributor Author

@elastic/apm-ui you need to be aware for this, non indexed fields root attributes are changing as per ECS:

{event}.context.request.url - > url
{event}.context.request (except url) - > http.request
{event}.context.response - > http.response

@graphaelli

Copy link
Copy Markdown
Contributor

what's the plan with url.port ? I was expecting we would switch to a long for that in 7.0.

Comment thread model/context.go Outdated
Comment thread _meta/ecs-migration.yml
Comment thread _meta/ecs-migration.yml
Comment thread _meta/ecs-migration.yml

- from: context.request.env
to: http.request.env
index: false

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

not defined in ECS

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The standard in ECS is that if the name does not end with text then it is a keyword. This is an object, so not sure how to bring this into ECS convention.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@graphaelli do you have any opinion on this?

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

The recommendation is to have all fields as keyword. If you need text datatype, you should have it as a multi-field. This is the reverse of the ES default.

Since this field is not in ECS, you're free to do what you want here.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

And about things that aren't in ECS (like http.request.env), they're not automatically a problem. If we don't add it to ECS, there will never be a conflict. And in this case, it's perfectly fine for you to define this field there.

http.request.env is the variables defined in the application's context? If that's the case, I can guarantee it'll never be in ECS (as it has nothing to do with the HTTP protocol), and would not named like this (as we try to use full words as much as possible).

So no conflict here 👍

Comment thread _meta/ecs-migration.yml
Comment thread _meta/ecs-migration.yml Outdated
index: false

- from: context.request.headers.user-agent
to: http.request.headers.user-agent

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ECS defines user_agent. While it is a root field there and not here, for the purpose of aligning I suggest to use http.request.headers.user_agent.original.

Comment thread model/context.go Outdated
Comment thread model/error/event.go
delete(e.Context, "request")
delete(e.Context, "response")

utility.Add(fields, "context", e.Context)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If I understand this PR correct, then it aims for getting rid of context. What's left here?


events = append(events, beat.Event{Fields: fields, Timestamp: e.Timestamp})

return events

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What happens with the context in span?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

#1804 open to discuss

@watson watson mentioned this pull request Jan 21, 2019
1 of 3 tasks
@jalvz
jalvz force-pushed the ecs-http branch 2 times, most recently from 53cc1fa to b3babfe Compare January 22, 2019 09:46

@simitt simitt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I suggest to also wait for @graphaelli 's opinion about those changes, but LGTM.

@simitt

simitt commented Jan 22, 2019

Copy link
Copy Markdown
Contributor

You need to (manually) update the approval files for the system-tests.

Comment thread _meta/ecs-migration.yml

# Not in ECS
- from: context.request.headers.user-agent
to: http.request.headers.user-agent.original

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actually user_agent is in ECS: https://github.com/elastic/ecs#user_agent

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

what is the reason for that? the actual header name is User-Agent

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this should stay as user-agent since it's nested under http.request.headers but I'd also be ok to switch if everyone else prefers that

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

In ECS it's at the top level, so not really a conflict with how you normalize header names as field names (if you decide to move it at the top level).

If you decide to leave it nested here because you prefer to list it as one of the header entries, then I'd opt to leave as is, to keep the consistent usage of '-' with other headers.

My actual suggestion would be to move this to ECS, however (and I thought I had seen another entry in this file to do so).

Moving this field to the ECS name will ensure the user agents recorded by APM can be found easily by any integration or person that supports the common schema, without having to create an exception for APM. That's the whole point of ECS, after all :-)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, as you noted there is another entry in this file for that. We have 2 user agents: the one in the request to the apm-server (which is moved to the ECS field at the root) and this one, which is in a request possibly captured by an APM agent.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Are these present in the same event at the same time? If not, then both should break down the user agent in the ECS field, user_agent at the top level.

If they can both be present in the same event, then that's a more complicated question :-)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, they are present at the same time.

@jalvz
jalvz force-pushed the ecs-http branch 2 times, most recently from 3ec8074 to 018b0a0 Compare January 23, 2019 14:23
Also loosen the Intake API so that url.port can be a string or a number.
It will be indexed as number
@jalvz

jalvz commented Jan 23, 2019

Copy link
Copy Markdown
Contributor Author

@sqren this updates the elasticsearch/generated files again.

request.method is also lower case now, in case is relevant

@graphaelli graphaelli left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

minor feedback but lgtm

Comment thread _meta/fields.common.yml
- name: scheme
type: keyword
description: >
The protocol of the request, e.g. "https:".

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

the example should be "https" - ecs is surprisingly specific on this - https://github.com/elastic/ecs#-url-fields.

Comment thread model/context.go
},
"port": {
"type": ["string", "null"],
"type": ["string", "integer","null"],

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

good idea

@jalvz
jalvz merged commit af76d15 into elastic:master Jan 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants