Page MenuHomePhabricator

Migrated Server-side EventLogging events recording http.client_ip as 127.0.0.1
Closed, ResolvedPublic

Description

http.client_ip was added to the Growth schemas in T287121. When verifying events flowing in for those schemas, HomepageVisit and ServerSideAccountCreation are recording http.client_ip as 127.0.0.1 for all events. Here's an example query, which returns no rows:

SELECT
    *
FROM event.serversideaccountcreation
WHERE year = 2021
AND month = 8
AND day >= 12
AND http.client_ip IS NOT NULL
AND http.client_ip != "127.0.0.1"

ServerSideAccountCreation and HomepageVisit are run server-side. The other Growth schemas are client-side and do not appear to be affected by this.

Expected behaviour: http.client_ip records the client IP address and associated geolocation information as for other schemas.

Event Timeline

nettrom_WMF renamed this task from Server-side Event Platform events recording http.client_ip as 127.0.0.1 to Migrated Server-side EventLogging events recording http.client_ip as 127.0.0.1 .Aug 13 2021, 6:38 PM
nettrom_WMF created this task.

@Tgr @Ottomata @kostajh — is there a token that can be used to join client_ip from a client-side event or does the IP need to be passed to the server-side event somehow? Since this is server to server, having http.client_ip probably doesn't make sense.

MediaWiki should have no problem adding the IP to the request. (Due to proxy mechanics, this might differ from the client-side IP in some edge cases but I doubt we care about those.) IMO that should happen on the EventLogging library level, to keep in sync with client-side logging where it also doesn't need to be manually added.

I'm adding Data Engineering and Metrics Platform to get some visibility on this, as @Tgr mentions this should happen at the library level.

Having the geolocation data available is important to answer questions in Product Dept deep dives, which happen monthly. Thus, the need for this data is rapidly increasing, we're hoping to have some insights available for the next one in mid-September. Getting this fixed before the end of the month would help facilitate that.

I believe (though I'm not 100% sure) that all WebRequests on the MW production hosts should have an x-client-ip header added by Varnish/ATS, but I don't see that being passed along anywhere in EventLogging or in EventBus (which actually performs the event submission to eventgate for server-side events). So I think the fix here would be to update EventBus::send() to get and send along the x-client-ip header. I'd appreciate a second opinion on this, though.

I believe (though I'm not 100% sure) that all WebRequests on the MW production hosts should have an x-client-ip header added by Varnish/ATS, but I don't see that being passed along anywhere in EventLogging or in EventBus (which actually performs the event submission to eventgate). So I think the fix here would be to update EventBus::send() to get and send along the x-client-ip header. I'd appreciate a second opinion on this, though.

That sounds right to me, although perhaps EventFactory::createEvent() would make sense, as that's where other metadata is added.

Thanks, @kostajh.

From earlier discussions with @Ottomata, I believe that the top-level http and meta properties are in a sense "owned" by the intake service, and the intent is for this kind of supplementation to happen there. So I think passing along X-Client-IP as an HTTP request header, to allow it to be used as http.client_ip by eventgate if needed, would more closely adhere to internal logic/assumptions than would directly supplementing the event data with it in EventFactory. We can't add http.client_ip to the event body unconditionally, or I believe events will be rejected by eventgate where http.client_ip is not present in the schema; and although eventgate-wikimedia leaves http.client_ip alone if it's present in the schema and a value is already set, I don't think the intent in general is for the metrics client to examine event schemas (as opposed to stream configs) or for producers to set it directly.

I have a patch in progress that I can push for review shortly, but it looks like we've already missed the MW branch cut this week. If it's sufficiently urgent, it can be backported.

Change 713526 had a related patch set uploaded (by Mholloway; author: Michael Holloway):

[mediawiki/extensions/EventBus@master] Conditionally send X-Client-IP header to the intake service

https://gerrit.wikimedia.org/r/713526

I believe that the top-level http and meta properties are in a sense "owned" by the intake service, and the intent is for this kind of supplementation to happen there.

Hmm, counterpoint to self: For server-side events, EventBus (via EventFactory) is already directly producing all of the meta fields. OTOH, it's safe to assume the presence of meta in EventBus, because the meta object is included in every schema, while http.client_ip is not.

IMO there is value in client-side and server-side events indicating the client IP in an identical way, because it might be used for things other than processing inside the event intake service, e.g. for network-level monitoring and anti-abuse (where it's also helpful that X-Client-IP is a commonly used header and all kinds of tools understand it).

That said, maybe worth asking someone from the Traffic team?

IMO there is value in client-side and server-side events indicating the client IP in an identical way, because it might be used for things other than processing inside the event intake service, e.g. for network-level monitoring and anti-abuse (where it's also helpful that X-Client-IP is a commonly used header and all kinds of tools understand it).

Just to be clear, you're advocating here for getting http.client_ip from X-Client-IP for events produced server-side from MediaWiki, correct? I believe that's what's happening now for client-produced events. (Actually, looking at the relevant code, eventgate looks first to X-Client-IP, then falls back to the leftmost IP in X-Forwarded-For, then finally falls back to req.socket.remoteAddress, though the function doc block only says that the field contains "[the] value of X-Client-IP request header if set."). My guess is that 127.0.0.1 is the req.socket.remoteAddress for requests coming from the MediaWiki appservers.

That said, maybe worth asking someone from the Traffic team?

Tagging Traffic and hoping that gets the right person's attention. :)

I'm just making sure I didn't miss anything: it looks to me like the instrumentation's just not sending the correct client IP. If something else is happening that needs or attention on EventGate or other parts of the pipeline, please let me know but I didn't get that from the discussion above.

In general I agree with Tgr, there's value in keeping the ip as consistent as possible between client-side and server-side.

Just to be clear, you're advocating here for getting http.client_ip from X-Client-IP for events produced server-side from MediaWiki, correct?

Yes.

odimitrijevic moved this task from Incoming to Event Platform on the Analytics board.

Just for the record, some discussion has happened in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventBus/+/713526/.
I believe in the end we're sending the IP via X-Forwarded-For header. And this should work already, because of:

... eventgate looks first to X-Client-IP, then falls back to the leftmost IP in X-Forwarded-For, then finally falls back to req.socket.remoteAddress ...

Thank you @Mholloway et. al. for taking care of this.
I think it makes sense to assign this task to you @Mholloway, please ping us if you need help from Data Engineering.

Hello!

I believe that the top-level http and meta properties are in a sense "owned" by the intake service

No fields are 'owned' by the intake service (AKA EventGate). There are some fields that are 'owned' by client producer libraries, like EventLogging / EventBus. eventgate-wikimedia will set some default values in events if they are not set, but it is easy to do this in EventGate because EventGate has the schema of the event, and can use the schema to determine if a default field should be set.

Schema fields that are not always present (like http.client_ip) cannot be automatically set by client producer libraries because they have no knowledge of the event's schema. The only place to set this now is in the instrumentation producer code, since that code is constructing an event that conforms to a specific schema.

The patch as proposed (forwarding X-Client-IP to EventGate) is certainly interesting though! It would work and I am not opposed, however we don't think that what EventGate is doing (using schemas to determine which defaults to set) is the right thing to do in the long run. https://phabricator.wikimedia.org/T273235#6879386. Instead, we should use stream config to enable/disable event hydrations, since all client producer libraries should be stream config aware.

Hi all, coming back to this as I've been OoO. As mentioned in T288853#7288436, having this data is becoming more urgent with the Product Deep Dives and the Newcomer Pilot. We've been running experiments aiming to increase account registration and activation and get questions about country-level differences that we're unable to answer (they might be possible to answer with various other proxies, but having the data available in ServerSideAccountCreation and HomepageVisit would make things a lot easier).

Is there something I can do to help move this along? @Ottomata, in your last comment you say you're not opposed, however the patch has a -1 on it from you. I get that there might be a preferred long-time solution for this that's different from what the patch proposes, and it looks like T290014 is the task for that as its description says "exploring whether we can source geolocation directly". That sounds like it could take a while, and I'd much prefer a solution that makes data start flowing in tomorrow rather than wait longer for this.

Moving this to Growth-Team's triaged column as @Mholloway is working on this; if there is something specific needed from our team beyond review on the patch, please let us know.

Ottomata, in your last comment you say you're not opposed, however the patch has a -1 on it from you

The -1 is not for the idea, but for a specific implementation concern in the patch, I think it'd just need to be resolved.

The -1 is not for the idea, but for a specific implementation concern in the patch, I think it'd just need to be resolved.

Got it, thanks for clarifying that!

Change 713526 merged by jenkins-bot:

[mediawiki/extensions/EventBus@master] Support x_client_ip_forwarding_enabled setting per event service

https://gerrit.wikimedia.org/r/713526

Looks like this got deployed last week with the train? I'm not seeing any changes in the server-side schemas, they're still recording 127.0.0.1 as the IP address. Maybe that's expected and there are additional changes needed? Let me know if something's needed on my end or if I can help out with something to get this resolved.

We need to enable it per eventgate service. Patch OTW...

Change 724143 had a related patch set uploaded (by Ottomata; author: Ottomata):

[operations/mediawiki-config@master] EventBus - Enable x_client_ip_forwarding_enabled for analytics purposes

https://gerrit.wikimedia.org/r/724143

Change 724143 merged by Ottomata:

[operations/mediawiki-config@master] EventBus - Enable x_client_ip_forwarding_enabled for analytics purposes

https://gerrit.wikimedia.org/r/724143

Mentioned in SAL (#wikimedia-operations) [2021-09-27T18:56:53Z] <otto@deploy1002> Synchronized wmf-config/CommonSettings.php: REVERT: Enable x_client_ip_forwarding_enabled for eventgate-analytics and eventgate-analytics-external - T288853 (duration: 00m 56s)

There is a bug in the code, so I had to revert my config patch. Hope to follow up this week.

There is a bug in the code, so I had to revert my config patch. Hope to follow up this week.

Thanks for following up on this, appreciate it! I'll keep an eye on this task before I attempt to QA anything.

Change 724180 had a related patch set uploaded (by Ottomata; author: Ottomata):

[mediawiki/extensions/EventBus@master] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724180

Change 724180 merged by jenkins-bot:

[mediawiki/extensions/EventBus@master] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724180

Change 724451 had a related patch set uploaded (by Ottomata; author: Ottomata):

[operations/mediawiki-config@master] CommonSettings-labs.php - test Eventbus x_client_ip_forwarding_enabled in beta

https://gerrit.wikimedia.org/r/724451

Change 724451 merged by Ottomata:

[operations/mediawiki-config@master] CommonSettings-labs.php - test Eventbus x_client_ip_forwarding_enabled in beta

https://gerrit.wikimedia.org/r/724451

Tested in beta, looks ok there.

Change 724480 had a related patch set uploaded (by Ottomata; author: Ottomata):

[mediawiki/extensions/EventBus@wmf/1.38.0-wmf.2] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724480

Change 724481 had a related patch set uploaded (by Ottomata; author: Ottomata):

[mediawiki/extensions/EventBus@wmf/1.38.0-wmf.1] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724481

Change 724380 had a related patch set uploaded (by Ottomata; author: Ottomata):

[operations/mediawiki-config@master] EventBus - Enable x_client_ip_forwarding_enabled for analytics purposes

https://gerrit.wikimedia.org/r/724380

Scheduled for a backport window tomorrow (wednesday sept 29).

Change 724480 merged by jenkins-bot:

[mediawiki/extensions/EventBus@wmf/1.38.0-wmf.2] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724480

Change 724481 merged by jenkins-bot:

[mediawiki/extensions/EventBus@wmf/1.38.0-wmf.1] Guard against undefined index notice when setting x-client-ip

https://gerrit.wikimedia.org/r/724481

Mentioned in SAL (#wikimedia-operations) [2021-09-30T19:04:00Z] <thcipriani@deploy1002> Synchronized php-1.38.0-wmf.2/extensions/EventBus/includes/EventBus.php: Backport: [[gerrit:724480|Guard against undefined index notice when setting x-client-ip (T288853)]] (duration: 01m 09s)

Mentioned in SAL (#wikimedia-operations) [2021-09-30T19:05:40Z] <thcipriani@deploy1002> Synchronized php-1.38.0-wmf.1/extensions/EventBus/includes/EventBus.php: Backport: [[gerrit:724481|Guard against undefined index notice when setting x-client-ip (T288853)]] (duration: 01m 09s)

Backport window didn't go yesterday, so I got the bugfixes out today. I'd rather wait until Monday to enable the config change, will do that then.

@Ottomata can we close this ticket out now? Or is there work left?

There is still work, I haven't deployed the config change. Sorry about that. I got caught up in the DSE hackathon this week and didn't want to have to deal with any fallout.

If you want it sooner, you could schedule the config change for a backport window deployment.

Change 724380 merged by Ottomata:

[operations/mediawiki-config@master] EventBus - Enable x_client_ip_forwarding_enabled for analytics purposes

https://gerrit.wikimedia.org/r/724380

Mentioned in SAL (#wikimedia-operations) [2021-10-12T13:13:38Z] <otto@deploy1002> Synchronized wmf-config/CommonSettings.php: Enable x_client_ip_forwarding_enabled for eventgate-analytics and eventgate-analytics-external - T288853 (duration: 00m 56s)

Okay, deployed, and I see HomepageVisit events with real client IPs.

@nettrom_WMF, f it looks okay to you, we can resolve.

I've verified that there are now events in the Data Lake with client IPs and geolocation information as expected. Thanks @Mholloway and @Ottomata for your work on getting this bug fixed!

  NODES
Idea 6
idea 6
INTERN 1
Note 7
Project 18
Verify 1