User_ipaddress unknown

For engineers Enrichment
1

I noticed that my ip_lookup (geo only) enrichment wasn’t adding any geo values. After investigating I found that all events have ‘unknown’ in the user_ipaddress field. I’m unsure about why that would be.

We’re running on scala stream collector and stream enrich on aws.

Any ideas?

2

Are you self hosting the maxmind database? Snowplow no longer hosts this for you. You’ll need to download the db from maxmind and host it yourself.

See notice:

3

I’m self hosting on s3. However, I think the enrichment will probably work fine if I could fix the ‘unknown’ ip values in the user_ipaddress field - that’s step one. Afterall, if there’s no IP there’s nothing to lookup.

for what it’s worth this is my ip_lookup json:

{
“schema”: “iglu:com.snowplowanalytics.snowplow/ip_lookups/jsonschema/2-0-0”,
“data”: {
“name”: “ip_lookups”,
“vendor”: “com.snowplowanalytics.snowplow”,
“enabled”: true,
“parameters”: {
“geo”: {
“database”: “GeoLite2-City.mmdb”,
“uri”: “s3://snowplow-enrichments/third-party/maxmind”
}
}
}
}

4

Hi @JBATX
Are you setting the ip in the payload in any of your tracking to be ‘unknown’? Or are you using the setUserIpAddress() that are available in some of the trackers?

5

@PaulBoocock good idea. I just confirmed that we are not doing either. We are using the off the shelf minified js tracker and hosting it on cloudfront. No setUserIpAddress available.

For context, we are using the tracker from the background in our browser extension. Perhaps this matters though I don’t know why it would. We’re sending get requests to the collector and the entire pipeline is functioning.

6

The collector will generate an ‘unknown’ IP if it is unable to parse it:

We utilise the extractClientIP function of akka to get the IP from one of the following headers:
X-Forwarded-For , Remote-Address , or X-Real-IP.
One (or more) of these headers should be set by the server or load balancer you are running the collector on (nginx, etc.).

1 Like
7

Just to chime in here - it might help narrow things down to open a page which sends the events in your own browser and find the request in the network tab.

The IP address should be set in the headers of the request - so you’ll hopefully be able to identify if the problem is at the tracker level or downstream.

8

@PaulBoocock that’s what I needed. thanks!
@Colm , good idea. I was actually already doing that from the extension’s background.html.

None of the headers are getting set in the request. This may be a quirk of chrome extensions - I’m researching that. Is there a way to set one of those headers using the tracker? As I understand it now, setting the IP is not supported in the JS tracker. Is that actually the case?

…alternatively, can the scala collector identify the IP based on the network collection and set the header before it’s parsed in the code you pasted above?

9

update: problem solved by setting X-Real-IP in the extension prior to sending events with sp(). I’m getting geo data in atomic.events now!

10

You can do this through the setIpAddress method but I’m not sure if you’ll have access to this if you are running with a Chrome extension.

1 Like