[09:15:54] Do we have any metric that gives insights on search update lag? I was about to roll out the wikidata bypass and was wondering, how I would be able to monitor success. [09:18:51] I should be able to run a kafka subscriber on the update topic that compares kafka-record timestamps with the meta.dt of the payload, but if we have any monitoring in place already, I’d use that. [09:27:08] pfischer: I don't think we have that and my understanding is that T328330 is supposed to address this [09:27:09] T328330: Create SLI / SLO on Search update lag - https://phabricator.wikimedia.org/T328330 [09:27:52] Erik wrote a tool IIRC that scans RecentChange and perform requests to elastic to compare [09:29:46] not sure where it is, perhaps check_rc.py in CirrusSearch/scripts? [09:31:48] But perhaps just checking few examples from https://www.wikidata.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&limit=50&days=7&urlversion=2 and opening ?action=cirrusDump to check the version might be sufficient? [09:33:07] currently it's still lagged but the change might not yet be live [09:34:22] Thank you, I’ll check the dump for now. [09:37:15] The script from Erik seems to here: https://phabricator.wikimedia.org/P17040 [09:37:24] *be [09:50:00] lunch [10:19:13] dcausse: The script helped a lot (thanks ebernhardson!), there was a significant reduction of lag from ~380s to 10-40s. So apparently that worked. [11:46:33] pfischer: awesome! [12:52:37] Weekly status update: https://wikitech.wikimedia.org/wiki/Search_Platform/Weekly_Updates/2024-07-19 [12:55:08] o/ [13:40:34] \o [13:49:01] o/ [14:38:09] sigh... writing some doc about federation but finding examples that are not too depressing is a bit hard... it's all about diseases, cancer or other quite scaring subjects... [14:38:17] :( [15:52:54] heading out, have a nice week-end [15:55:02] workout, back in ~40 [18:14:06] sorry...been back, but now leaving to watch my son's recitcal. Back in ~2h [20:35:16] back