Adds network.protocol.name and network.protocol.id #79
Conversation
With most logs coming in, the protocol names are not resolved to their respective full name and instead rely on the IDs from [IANA](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) This adds names and ids. The regular `network.protocol` would use name, but if you're not planning to use resolution, `network.protocol.id` would be available.
| @@ -9,7 +9,17 @@ | |||
| type: keyword | |||
| description: > | |||
| Network protocol name. | |||
| example: http | |||
| example: tcp | |||
| - name: protocol.name | |||
There was a problem hiding this comment.
It is not possible to have protocol and protocol.name as otherwise ingestion in ES will not work (object vs keyword type). I assume we could remove protocol?
There was a problem hiding this comment.
@ruflin ah that makes sense. I guess we can just stay with network.protocol if we plan to add network.application.protocol. That means we should be able to keep network.protocol.id.
There was a problem hiding this comment.
network.protocol and network.protocol.id can also not coexist.
There was a problem hiding this comment.
Yeah I think the confusion comes from ElasticSearch' multi-fields. So it's possible to have foo and foo.bar because it's actually one field (one value) indexed in different ways. By default/convention, the top level is analyzed for full text search, whereas the nested field is indexed another way, in this case keyword indexing, for aggregations and exact match searches. You could even have more than one nested field, but the common thread is that it's always exactly the same value being indexed in different ways.
On the other hand, you cannot have foo and foo.bar be two different values, because as @ruflin said, the top level needs to be of type object, to be able to nest arbitrary stuff under it.
There was a problem hiding this comment.
Well actually, looking again at the actual file, it seems like protocol is just a dupe of protocol.name.
So the following should do it (we don't need to explicitly define the top level object):
fields:
- name: protocol.name
type: keyword
description: >
Network protocol name.
example: TCP
- name: protocol.id
type: keyword
description: >
Network protocol id https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
example: 6
|
Closing this issue, as #81 fixes this use case, and more. |
With most logs coming in, the protocol names are not resolved to their respective full name and instead rely on the IDs from IANA. This adds names and ids. The regular
network.protocolwould use name, but if you're not planning to use resolution,network.protocol.idwould be available.