Consider doing async reverse dns lookups in probe, breaking out the internet node into something more interesting.

[tomwilkie]

Esp when running apps in the cloud, would be nice to show which components are calling out to which services (s3, ses, etc)

[peterbourgon]

Ooh, I like it: we could just tag remote nodes with a variety of whois-y lookup data...

"123.45.6.78;80": {
    "country": "UK",
    "city":    "Birmingham",
    "owner":   "HP Foods LLC"
}

[awh]

Other metadata types that could be interesting - geoIP, autonomous system

[tomwilkie]

Design considerations:

• we don't want to hammer any backend (dns) service, so we'll want some caching
• we don't want the lookups in dns to block the probes main thread

[peterbourgon]

For geolocation stuff, it may be better to ship a GeoIP database with every Scope release, rather than pinging some remote service.

[inercia]

@peterbourgon there are some GeoIP databases publicly available (with some Golang libs). Maybe Scope could download it on the first run and keep it until a new version is available...

[peterbourgon]

The probes would need to download it, and you may have lots of probes in your infrastructure. If I were an ops guy, I would be very unhappy with a monitoring agent reaching out to the internet and downloading some megabytes from a server when it first boots. I would be very unhappy with it reaching out to the internet at all, actually, unless I explicitly turned some feature on, and understood the implications of doing so.

[inercia]

@peterbourgon you are right: we should include the GeoIP database in the Scope image. Maybe we could add an option for overriding the embeded database in the future...

[inercia]

And what about adding this kind of information not in the probe but in the server? The result of geolocating an IP would be the same, and it would be easier to keep an up-to-date database in the server...

[tomwilkie]

The app server might not be running in the same context as the probes, and might not have access to the same dns (for instance).

Lets worry less about geoip for now, and more about reverse dns lookups.

[awh]

Lets worry less about geoip for now, and more about reverse dns lookups.

Yes sorry about that - I didn't mean to pollute this PR, just capture the conversation we had around it the other day...

[inercia]

Some implementation questions:

• Where should we add this reverse resolution metadata? In the Address/EdgeMetadatas ? In Address/NodeMetadatas?
• For avoiding contention, maybe the first time we see an IP we could trigger a async, reverse resolution and then add the metadata the next time we generate a report... could this be feasible?

[tomwilkie]

1. Address/Endpoint NodeMetadatas is the obvious choice, but these don't exist for remote ends of connections. We'll need to have the probes generate the pseudo nodes, which is part of Consider gently converging NodeMetadata struct and RenderableNode #357
2. Yes that sounds like a good idea. Don't block the probe goroutine, have it pick it up next time.

[inercia]

Ok, then I'll start by adding new nodes in Address/NodeMetadatas for remote ends of connections iff we have a cached reverse DNS resolution, with the reverse resolution in the "addr" (I'll add these in Addresses as I've seen in the comments in the code that Endpoints need pids, but correct me if I'm wrong)

[peterbourgon]

Done