Can someone please explain to me why port number ECS fields like source.port, destination.port, etc. are defined as numerical type long? When would port numbers from logs ever need to be used in any kind of mathematical calculation?
Here's why I ask. In Kibana, with numerical data types the value for the port number is rendered in a document as for example:
Obviously no one puts a comma in a port number. Could we just change the format of the number to remove the comma under advanced settings...yes...but then it removes all commas for all other numbers everywhere.
What would be the impact of defining the ECS port number fields as keyword string type in an index template to override the default long type? Would that cause problems anywhere like in Endpoint Security?
Port numbers are mapped as a numeric type because Elasticsearch optimizes those types for range queries, and making a range query on a port is a pretty common use case.
Some real use cases would be search all ports between a specific range, or search all events where the destination port is higher than some specific number.
You can change the way kibana shows numeric values by editing the format of the specific field in your index pattern, this will affect only the specific field, not other numeric fields.
To remove the thousand separator from the fields with port numbers, you just need to format the field as a number and use a
0 in the number format pattern, like the example in the following image.
This way, any port higher than
1000 will appear without the thousand separator, for example,
9200 will show as
9,200 if your thousand separator locale is
Ah, ok. Thank you. I was only thinking about it from a metrics perspective.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.