What type is the "port" field in Heartbeat output?

Elastic Stack Beats
1

I think what I'm seeing is that

(1) for a type HTTP monitor with the port specified in the "urls" the "port" field in the Elasticsearch document is a string

(2) for a type TCP monitor with the port specified in the "ports" the "port" field in the Elasticsearch document is numeric

Am i imagining this?

2

... or did I get those the wrong way round? ... seriously confused here ...

3

http.url is a text field, tcp.port is an integer. Is that what you are referring to? The url contains more then just the port. Perhaps you can share some more background on the issue you are having?

1 Like
4

With this configuration (boring bits snipped):

    - type:     http
      urls:     ['http://www.example.com:1234']

    - type:     tcp
      hosts:    ["appserver.example.com"]
      ports:    [1410]

then in Elasticseach, according to the Kibana "Discover" screen, I get, respectively

    "port": 1234,
    "port": "1410",

which confused my code somewhat until I spotted it. (Leaving aside further confusion as to how the same field can sometimes be numeric and sometimes a string in Elasticsearch anyway, surely the mapping must be one or the other?)

5

Re the mapping point, I have now discovered Strings in integer fields?

6

Which heartbeat version are you using? This is a bug. Ports should always be numeric values.

7

5.5.1

8

In 6.0 we redid the event format for heartbeat. https://github.com/elastic/beats/pull/4091

I just noticed it's using string for all port types. But the Elasticsearch template mapping configures the port number to be an integer. :scream:

9

New github issue: https://github.com/elastic/beats/issues/5696

10

What a pain. I'd written some generic code to handle boolean (true/false) statuses so I'll have to write some new code to handle "up"/"down". (I suppose an alternative would be to run it through Logstash and change it back to the old format ...)

11

@TimWard Thanks for bringing this up.

If the template on the elasticsearch side states int, ES should either reject it or store is a integer I think. So even if I agree that this is a bug, it should end up in the right format in Elasticsearch (assuming the template was applied before sending data)?

12

@TimWard Just tried to reproduce this with master / 6.x It seems we have fixed it there more by accident probably. Could you try out 6.0 and check if you still have the issue?

13

Thanks for the investigations and comments. I'm sure I will try it with 6.0 one day, but installing and configuring a 6.0 set-up is unlikely to reach the top of my priority list in the immediate future.

1 Like
14

Thanks Tim for the answer. Appreciate your effort you put into this and I'm glad you found a temporary solution.

15

This topic was automatically closed after 21 days. New replies are no longer allowed.