-
Notifications
You must be signed in to change notification settings - Fork 529
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
Add system network fields #5436
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
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.
Fields and processor/otel changes LGTM, but I don't think we need the modeldecoder, processor/stream, or testdata changes.
model/modeldecoder/v2/decoder.go
Outdated
@@ -526,6 +526,21 @@ func mapToMetadataModel(from *metadata, out *model.Metadata) { | |||
if from.System.Platform.IsSet() { | |||
out.System.Platform = from.System.Platform.Val | |||
} | |||
if from.System.Network.Carrier.Name.IsSet() { |
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 new fields are only for the iOS agent, which uses OTLP. Let's leave modeldecoder out of it please.
Co-authored-by: Andrew Wilkins <axwalk@gmail.com>
Co-authored-by: Andrew Wilkins <axwalk@gmail.com>
- name: network.connection_type | ||
type: keyword | ||
description: | | ||
Cellular network technology, eg. 4G |
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 am not certain about the naming. ECS has a definition for network
and one for host
with some host.network
fields. None of them contain what we need. This PR introduces network.carrier.*
fields, that are not (yet) in ECS, but also not aligned with the otel proposal net.host.carrier.*
.
@jalvz did you have a conversation with the ECS folks where they would see these fields fit in? I am a bit worried to just remove the host
part, that is in the otel proposal.
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 have already a top level host
field, I didn't think it would make much sense to duplicate the field inside network
to refer to the same host?
network
is already defined as top level field in ECS (https://www.elastic.co/guide/en/ecs/current/ecs-network.html),
I sort of followed #491, btw.
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.
ECS says (about the network fieldset):
The network is defined as the communication path over which a host or network event happens.
The network.* fields should be populated with details about the network activity associated with an event.
Seems to me it makes sense to go under network
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 let me ask:
host
andnetwork.host
would refer to the same host, or different ones?- If different: which is what? If same: why duplicate a field we already have?
- What exactly says in the ECS
network
definition that dictates there should be ahost
field insidenetwork
? (sorry I can't see that in the quote) - If we go with
network.host
, why don't we apply the same reasoning elsewhere? Eg., aprocess
normally runs on ahost
, yet there is noprocess.host
; rather 2 top fields (conceptually related). - If we go with
network.host
, how do you justify that in the context of other fields? We could have eg.network.host.connection_type="wifi"
andnetwork.name="Guest wifi"
- whyconnection_type
andname
would not be at the same level? - What does it mean, conceptually,
network.host.carrier
?: ahost
has acarrier
? acarrier
runs on ahost
?...
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.
After some offline discussion, network.carrier.*
is where the new fields fit best related to ECS, and net.host.carrier.*
was the prefered nesting in the open-telemetry proposal; so 👍 on the changes.
This pull request is now in conflicts. Could you fix it @jalvz? 🙏
|
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, but please wait until we have consensus on #5436 (review)
(cherry picked from commit 01a12f2) # Conflicts: # changelogs/head.asciidoc # include/fields.go
Added |
Bumped to 7.15 in #5719 |
Motivation/summary
See motivation on the linked ticket bellow.
Some notes:
network
instead ofnet
because ECS prefers it.host
subkey, like in the OTel spec proposal because ECS already has a top levelhost
key. We could nestnetwork
insidehost
but I don't see any value in doing that.Checklist
How to test these changes
Related issues
Closes #5203