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:
source.port 55,134
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 9200, not 9,200 if your thousand separator locale is ,.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
