METRON-680: GeoLiteDatabase incorrectly using country geoname_id instead of city

[justinleet]

Swaps out country's geoname_id for city's geoname_id. Both ids are the same in format (they're the ids for the geonames.org dataset).

The only direct effect I know of from this is the Kibana dashboard uses this field for unique locations (so changing what feeds this changes the dashboard output). The main wrinkle is that city can be unpopulated, even though a country exists (e.g. if an IP is just assigned to the U.S., it may not have a city). This isn't always true that (at least one IP range for Japan appears to fill in Japan as the city's geoname id).

I'm opening the PR with just the direct change, but it's definitely open to discussion if we want to adjust.

[cestella]

Can you reopen with the right JIRA prefix: METRON-680 ?
EDIT: Nevermind, evidently the ASF bot is smart enough to link the two with this name. Sorry! Retracted.

[justinleet]

@cestella My mistake, fixed.

[cestella]

I don't mind this change, but could we add another field for "countryLocId" so that, if so desired, people could reconfigure that instead?

[justinleet]

@cestella We definitely could. METRON-679 has the details about all the other fields we could be passing, including the current country geoname id being passed. If we want to start passing additional fields, I'd rather just do it one as part of that ticket.

For this, we could also just change the box to do a unique count of one of the other existing fields, and just ignore locId entirely. To the best of my knowledge it only gets used in that one Kibana visualization. Depending on how granular we want the box to be (at least by default), we could always make it a unique count on city or a unique count on location_point (or whatever the actual field for lat,long) is.

[cestella]

Ok, sounds good to me. +1 by inspection