[01:20:48] (PS9) Mforns: [WIP] [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/192319 (https://phabricator.wikimedia.org/T89251) [01:20:54] (CR) jenkins-bot: [V: -1] [WIP] [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/192319 (https://phabricator.wikimedia.org/T89251) (owner: Mforns) [01:23:14] (PS10) Mforns: [WIP] [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/192319 (https://phabricator.wikimedia.org/T89251) [01:23:21] (CR) jenkins-bot: [V: -1] [WIP] [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/192319 (https://phabricator.wikimedia.org/T89251) (owner: Mforns) [03:10:13] (PS6) Fhocutt: Add user names to json report, corresponding tests [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/181770 (https://phabricator.wikimedia.org/T74747) [07:59:38] Analytics-Tech-community-metrics, Wikimedia-Git-or-Gerrit, ECT-February-2015, ECT-March-2015: Active Gerrit users on a monthly basis - https://phabricator.wikimedia.org/T86152#1077254 (Qgil) [08:00:17] Analytics-Tech-community-metrics, Wikimedia-Git-or-Gerrit, ECT-February-2015, ECT-March-2015: Basic metrics about contributors exercising +2/-2 permissions in Gerrit - https://phabricator.wikimedia.org/T59038#1077255 (Qgil) [08:05:49] Analytics-Tech-community-metrics, JavaScript: No graphs are displayed on code review queue due to JS error - https://phabricator.wikimedia.org/T88322#1077263 (Qgil) Open>Resolved a:Qgil I have been able to load the page every time I have visited, even if it does take a while. I will close this ta... [08:11:58] Analytics-Tech-community-metrics: Graphs for median/average should report absolute numbers - https://phabricator.wikimedia.org/T68266#1077280 (Qgil) Open>Resolved a:Qgil I have checked several graphs in Korma, and this task seems to be resolved. [08:15:43] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015, Epic: Allow contributors to update their own details in tech metrics directly - https://phabricator.wikimedia.org/T60585#1077289 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:43] Analytics-Tech-community-metrics, ECT-March-2015: Instructions to update user data in korma - https://phabricator.wikimedia.org/T88277#1077291 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:46] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015: Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T89135#1077295 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:47] Analytics-Tech-community-metrics, ECT-March-2015: KPI pages in korma need horizontal margins - https://phabricator.wikimedia.org/T88670#1077297 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:48] Analytics-Tech-community-metrics, ECT-March-2015, Patch-For-Review: "Age of unreviewed changesets by affiliation" shows negative number of changesets - https://phabricator.wikimedia.org/T72600#1077303 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:49] Analytics-Tech-community-metrics, ECT-March-2015: Tech metrics should talk about "Affiliation" instead of organizations or companies - https://phabricator.wikimedia.org/T62091#1077299 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:15:50] Analytics-Tech-community-metrics, ECT-March-2015, Patch-For-Review: "Volume of open changesets" graph should show reviews pending every month - https://phabricator.wikimedia.org/T72278#1077301 (Qgil) Proposing this task for the #ECT-March-2015 sprint [08:28:15] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015: Support for vizGrimoireJS-lib widgets - https://phabricator.wikimedia.org/T89132#1077328 (Qgil) p:Low>Normal GSoC / Outreach are around the corner, and we need to decide whether this possible tech projects is in or out. [08:41:00] Analytics-EventLogging, MediaWiki-extensions-Sentry, Multimedia, Multimedia-Sprint-2015-02-25, Patch-For-Review: Log EventLogging schema validation errors in Sentry - https://phabricator.wikimedia.org/T90083#1077369 (Gilles) Open>Resolved Seen working on beta [09:53:13] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015, Epic: Allow contributors to update their own details in tech metrics directly - https://phabricator.wikimedia.org/T60585#1077525 (Qgil) p:Low>Normal [09:58:06] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015: Support for vizGrimoireJS-lib widgets - https://phabricator.wikimedia.org/T89132#1077539 (Qgil) Open>declined a:Qgil Actually, we think that this might not be the best idea for a Possible Tech Project right now. [09:59:19] Analytics-Tech-community-metrics, Possible-Tech-Projects: Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T89135#1077542 (Qgil) p:Normal>Lowest [09:59:26] Analytics-Tech-community-metrics, Possible-Tech-Projects: Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T89135#1027974 (Qgil) Not for this round. [10:05:15] Analytics-Tech-community-metrics, ECT-March-2015, Patch-For-Review: "Volume of open changesets" graph should show reviews pending every month - https://phabricator.wikimedia.org/T72278#1077548 (Qgil) a:Qgil [10:05:41] Analytics-Tech-community-metrics, ECT-March-2015, Patch-For-Review: "Age of unreviewed changesets by affiliation" shows negative number of changesets - https://phabricator.wikimedia.org/T72600#1077549 (Qgil) a:Qgil [10:06:55] Analytics-Tech-community-metrics, ECT-March-2015: Tech metrics should talk about "Affiliation" instead of organizations or companies - https://phabricator.wikimedia.org/T62091#1077553 (Qgil) a:Dicortazar [12:16:28] Analytics-Tech-community-metrics, ECT-March-2015: KPI pages in korma need horizontal margins - https://phabricator.wikimedia.org/T88670#1077777 (Dicortazar) a:Dicortazar [12:17:14] Analytics-Tech-community-metrics, ECT-March-2015: Instructions to update user data in korma - https://phabricator.wikimedia.org/T88277#1077778 (Dicortazar) a:Dicortazar [12:21:36] Analytics-Tech-community-metrics, Wikimedia-Git-or-Gerrit, ECT-February-2015, ECT-March-2015: Basic metrics about contributors exercising +2/-2 permissions in Gerrit - https://phabricator.wikimedia.org/T59038#1077781 (Dicortazar) As the following step, the defined chart and table will be part of th... [12:23:27] Analytics-Tech-community-metrics, Wikimedia-Git-or-Gerrit, ECT-February-2015, ECT-March-2015: Active Gerrit users on a monthly basis - https://phabricator.wikimedia.org/T86152#962385 (Dicortazar) As similarly done in {T59038}, the following step consists of adding the proposed chart (nicer and with... [12:26:09] Analytics-Tech-community-metrics, ECT-March-2015: Instructions to update user data in korma - https://phabricator.wikimedia.org/T88277#1077790 (Dicortazar) An initial configuration file will be provided with information about unique identities, affiliations and countries. Initially, this will be private... [13:31:21] halfak: morning [13:31:32] so your flight's coming in today at 12:55 or tomorrow (Tuesday)? [13:37:13] Hiya [13:47:28] Analytics-Tech-community-metrics, Possible-Tech-Projects, ECT-March-2015, Epic: Allow contributors to update their own details in tech metrics directly - https://phabricator.wikimedia.org/T60585#1077886 (Dicortazar) [14:55:10] (CR) Mforns: [C: 1] "LGTM" (1 comment) [analytics/limn-edit-data] - https://gerrit.wikimedia.org/r/192944 (https://phabricator.wikimedia.org/T89729) (owner: Milimetric) [15:08:33] Analytics-Cluster, Analytics-Kanban: Make gecoded data and chosen client_ip available as fields in refined webrequest data - https://phabricator.wikimedia.org/T89401#1078152 (ggellerman) Open>Resolved [15:12:06] Analytics-Cluster, Analytics-Kanban: Add jar versions as parameters in oozie jobs - https://phabricator.wikimedia.org/T90736#1078156 (JAllemandou) Open>Resolved [15:18:27] mforns: this is the graph for valid/overall: https://graphite.wikimedia.org/render/?width=588&height=311&_salt=1425309464.624&target=eventlogging.client_side_events.valid.rate&target=eventlogging.overall.valid.rate&from=00%3A00_20150215&until=23%3A59_20150302 [15:19:32] nuria, ok [15:20:00] mforns: There is probably one new event that is not validating (or did not validate) during the timepreriod. Logs should be on vanadium/stat1002 looking at the logs of consumers for that timeperiod (/var/log/upstatrt) you should be able to see what event was causing issues and we can notify team [15:20:25] right [15:21:13] the behavior of the chart lines this weekend is similar to two weeks ago [15:21:37] nuria, did we have a similar problem back then? [15:22:31] mforns: I think so, i think the popup schema was the issue then [15:22:40] ok, thanks! [15:22:47] having a look [15:35:06] mforns: ok, let me know [15:48:50] nuria, now I have access to vanadium, and it seems I can use sudo command, but I don't know what password I have, did you specify it at any point when requesting access? [15:49:11] mforns: i use my same pw for stat1002 [15:49:35] aha [15:51:17] my usual password does not work in stat1002 neither [15:51:25] :[ [15:58:23] mforns: what password do you use to ssh to 1001 /1003/1002 ...it should be that one [16:06:33] nuria, talking to paravoid, he says I'm still not a sudoer in vanadium [16:06:56] mforns: then i would re-open the tickets [16:07:38] nuria, sure [16:08:16] (CR) Nuria: "Thanks much for doing these changes." (2 comments) [analytics/wikimetrics] - https://gerrit.wikimedia.org/r/181770 (https://phabricator.wikimedia.org/T74747) (owner: Fhocutt) [16:09:45] mforns: and do you have permits in 1002/1003? [16:09:54] no [16:14:14] mforns: that is something to fix too [16:14:29] mforns: the 1002/1003 andrew can do for you [16:14:36] ok, are there other machines I need access too? [16:14:51] ok, for 1002/1003 I'll ask andrew [16:15:25] mforns: the ones listed here: http://www.mediawiki.org/wiki/Analytics/Onboarding#Accessing_production_infrastructure [16:15:49] thanks [16:15:50] getting access to 1001/1002 includes access to bastion as ssh is proxied that way [16:29:37] mforns: I have added hafnium that is not on the list [16:29:45] ok [16:30:18] I suppose hafnium is the same process as vanadium (not through andrew, but ops ticket) right? [16:34:41] and nuria, do I need root permits for hafnium also, or just normal access? [16:35:33] mforns: you need root [16:38:41] milimetric: can you check that you do have sudo on vanadium? (whenever, does not have to be now) [16:39:18] nuria: I do have it, yes [16:39:28] do you need anything from there? [16:39:40] milimetric: so you can ssh and tail logs, right? [16:39:49] milimetric: no, mforns just did not have it [16:40:03] yes, I can ssh and tail yes, it's great [16:40:14] i meant to mention it in standup last week, apologies if i forgot [16:40:58] milimetric, np. It's just that my task in phab got resolved but I still do not have root in vanadium [16:44:23] Analytics-Cluster, Analytics-Kanban, Epic: {epic} WMF has UC report per project per month & day {bear} - https://phabricator.wikimedia.org/T88647#1078479 (Nuria) [16:44:24] Analytics-Cluster, Analytics-Kanban: WMF has technical documentation on UC by last visited date [5 pts] {bear} - https://phabricator.wikimedia.org/T88812#1078478 (Nuria) Open>Resolved [17:02:44] mforns: let us know once that is resolved [17:03:01] nuria, sure, I already reopened the task [17:03:39] mforns: you could search for who is in RT duty in ops today and let them know [17:03:52] ok [17:09:40] (CR) Ottomata: [C: 2 V: 2] Adjust legacy_tsv description in status dump script [analytics/refinery] - https://gerrit.wikimedia.org/r/193410 (owner: QChris) [17:09:58] (CR) Ottomata: [C: 2 V: 2] Add mediacounts to status dump script [analytics/refinery] - https://gerrit.wikimedia.org/r/193411 (owner: QChris) [17:10:23] (CR) Ottomata: [C: 2 V: 2] Collapse caption lines in table of dump script, if they agree [analytics/refinery] - https://gerrit.wikimedia.org/r/193412 (owner: QChris) [17:10:33] Thanks :-) [17:11:39] nuria, Coren is helping me with that right now [17:11:45] mforns: k [17:18:56] Analytics-Cluster, Analytics-Kanban, Epic: {epic} WMF has UC report per project per month & day {bear} - https://phabricator.wikimedia.org/T88647#1078596 (Nuria) Not that we are just going to try to implement "monthly" cookies on 1st phase, not daily. [17:28:44] nuria, I'm in :] [17:29:10] mforns: ok, i am looking at the problem but you can look too [17:29:17] ok [17:53:34] nuria: do you need any support with ops for the VCL CR for last-visited-time? [17:54:50] nuria, do the logs that fail validation end up in vanadium? or in stat1002? or both? [17:55:32] mforns: only in vanadium, you have to look at the processor logs [17:56:18] oh, I thought you said the consumer logs [17:56:34] ok, looking [17:57:55] Analytics-EventLogging: Large number of popup events not validating - https://phabricator.wikimedia.org/T91272#1078744 (Nuria) NEW a:Prtksxna [18:15:24] nuria, I did a small analysis with: vanadium:/var/log/upstart$ sudo zgrep '2015-03-01 11:4' eventlogging_processor-client-side-events.log.1.gz | egrep -o 'schema%22%3A%22[^%]+%' | less | cut -f4 -d'%' | cut -f3 -d'2' | less | sort | uniq -c | sort -nr [18:16:18] and the output is: http://pastebin.com/tzhRg8Pu [18:18:39] I've seen you already sent an email for Popups schema [18:19:06] Are MultimediaViewerNetworkPerformance and MobileWikiAppSavedPages also known issues? [18:34:50] mforns: wait, why 11:4? [18:35:18] oh sorry, it was 10:4 utc [18:37:16] mforns: alarms are on Sun Mar 1 22:38:30 UTC 2015, right? [18:37:39] oh, it's pm? sigh.. [18:37:41] sorry [18:37:50] mforns: no worries [18:47:13] nuria, during the alert time, there are 135 MobileWikiAppSavedPages events without the required field appInstallID [18:47:58] mforns: is that significantly higher than any other hour? [18:48:54] mforns: regardless that event also deserves a ticket, you can create one in phab and cc deskana and mobile team and send FYI to analytics list [18:49:14] ok [18:52:07] mforns: but i do not see a clear culprit for the event, do you? [18:52:17] no [18:52:54] the same time range in the previous days gives: 27th->104 occurences, 26th->79, 25th->117 [18:53:15] let me look at the other errors [18:53:20] just a sec [18:59:15] (CR) Ottomata: "Ellery, this code is mostly done, it just needs a babysitter to get it through code review. Oliver is dropping it, do you want to pick it" [analytics/refinery/source] - https://gerrit.wikimedia.org/r/188588 (owner: OliverKeyes) [19:00:30] nuria, well popup seems to have an increase, from 59 in the 26th to 35, 59 and finally 83 in 1st of Mar [19:01:13] but it seems too small to have created the alert by itself [19:03:21] mforns: right, we have gotten this alert before when people deploy a new schema and most events do not validate, i do not think this is the case here [19:04:17] mforns: but regardless the failures on the mobile schemas should have tickets [19:04:35] sure, I'll file them [19:06:57] Huh. [19:07:03] We've not pushed out a new release or anything. [19:07:06] So that's troubling. [19:11:50] (CR) Nuria: "Can we also add a test to the contrary, that is www.wikipedia.org/foobarbaz is NOT counted as a pageview?" [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193513 (owner: OliverKeyes) [19:12:19] Deskana: I think those failures have been there for a while [19:12:46] Deskana: we are trying to cleanup house a bit on our end. [19:14:51] nuria: I'm checking with Adam to see what might be causing that issue now. [19:15:34] Deskana: Thank you, could be that that event is sent regardless of whether the user has opted out and thus appinstalid is not there ? [19:18:32] nuria: No. The opt out completely stops events from being sent, it doesn't affect install ID transmission (for anything except reading) [19:18:50] Deskana: great, one less thing to worry about [19:19:23] nuria: Could you send me one or two of the events that failed validation so I can check the UA to see what app version? [19:19:55] mforns: Did you open the ticket? we can paste all this info there, plus I think there are couple events not one with teh same issue [19:20:09] I'm writing it [19:20:17] Deskana: getting you uas now [19:20:22] trying to do some commands to get more info [19:21:23] https://www.irccloud.com/pastebin/3VquPqmI [19:22:12] Deskana: 2015-03-01 06:41:48,433 (MainThread) Unable to decode: ?%7B%22schema%22%3A%22MobileWikiAppSavedPages%22%2C%22revision%22%3A10375480%2C%22event%22%3A%7B%22action%22%3A%22savenew%22%7D%2C%22wiki%22%3A%22ruwiki%22%7D; cp3019.esams.wikimedia.org 72227515 2015-03-01T06:41:48 91.198.174.89 WikipediaApp/4.0.6 (iPhone OS 7.1.2; Phone) [19:23:38] Deskana: The majority of issues seem to come from IOS App [19:24:49] Deskana: no, sorry, both android & ios have issues [19:25:21] Deskana: but since we have many more users on android seems like error is more prevalent on iOS [19:27:44] nuria: Okay, we think we broke something in our test builds and those events are all from us testing things. [19:28:11] Deskana: do you know you can test in beta labs? [19:28:22] Deskana: no need to test EL in prod, works just the same [19:28:37] nuria: How do we test the app in beta labs? [19:29:01] nuria: You mean point our beta builds at a different EL server? [19:29:10] Deskana: you point it to log against beta labs varnish: https://wikitech.wikimedia.org/wiki/EventLogging/Testing/BetaLabs [19:29:30] nuria: Okay, I'll make a note of that and we can investigate. For now, let's fix this specific issue. [19:30:00] Analytics-EventLogging: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079148 (mforns) NEW [19:34:12] Deskana: sounds good, specific info on how can you test: https://wikitech.wikimedia.org/wiki/EventLogging/Testing/BetaLabs#How_to_log_an_event_to_beta_labs_directly [19:34:39] nuria: Yep, we somehow broke our implementation of that schema in master. dr0ptp4kt is fixing it now. [19:35:00] Deskana: thanks for the very fast response [19:35:11] nuria: AFAIK this has not made its way into a production release.. [19:35:23] nuria: We should have a fix by the end of the day. [19:35:49] Deskana, I filed a task in phab: https://phabricator.wikimedia.org/T91290#1079148 [19:36:11] Analytics-EventLogging, Mobile App Sprint 52 - iOS: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079164 (Deskana) p:Triage>High [19:36:17] Analytics-EventLogging: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079167 (Nuria) p:High>Triage [19:36:35] mforns: i have added adam and dan to that task so they can see it [19:36:45] ok [19:36:57] Analytics-EventLogging: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079177 (Deskana) a:dr0ptp4kt [19:37:15] Analytics-EventLogging: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079148 (Deskana) p:Triage>High [19:37:33] Analytics-EventLogging: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079148 (Deskana) We somehow broke our implementation of this schema on iOS. There's no preprocessData method implemented for that schema, which causes the install ID to not be rou... [19:37:51] Analytics-EventLogging, Wikipedia-App-iOS-App, Mobile App Sprint 52 - iOS: Some events not validating for MobileWikiAppSavedPages schema - https://phabricator.wikimedia.org/T91290#1079182 (Deskana) [19:48:56] ottomata: when you have a minute in your hackathon... can we fix the issues with permits and wikimetrics? [19:54:46] Analytics, Wikimedia-Fundraising: Provide performant query access to banner show/hide numbers - https://phabricator.wikimedia.org/T90649#1079306 (atgo) [19:55:46] joal: this was the problem: https://gerrit.wikimedia.org/r/#/c/193882/1/manifests/hadoop/defaults.pp [19:55:54] i set vcores to 0 on those nodes [20:02:17] NIIIICE one ;) [20:02:25] Had not seen that ! [20:02:29] Thx mate [20:02:37] I'll double check later [20:03:09] nuria, do the events for eventlogging have a size limit in bytes/chars? [20:03:40] because I think the issues with MultimediaViewerNetworkPerformance schema come from the length of some of its events... [20:04:11] I think they get cropped at some point and then they fail to be parsed [20:05:15] although that's just an hypothesis, I wondered if you knew about a limit? [20:10:49] mforns: for URL? [20:11:01] may be [20:11:24] I don't know, at any point in the EL pipeline [20:11:28] the url makes sense [20:11:46] mforns: no, there is no limit, urls might come in cropped if they are real large, like for example, I rememeber akamai cut them at 4000 chars [20:11:50] mforns: at a guess https://twitter.com/nikmd23/status/524306035784167426 ? [20:12:29] oh! interesting [20:12:52] also http://support.microsoft.com/kb/208427 [20:12:54] tgr: mmmm...limits how [20:13:33] tgr: That limit does not apply to all browsers everywhere but now, if your urls are that huge something is up, [20:13:34] is it possible to correlate the errors with the UA signature? [20:14:05] tgr, mforns : we had huge urls before at my prior job when js modules where too small and you needed to name a ton to load all the ones to compose the page [20:14:14] 2KB is not huge for an EL URL [20:14:20] nuria, aha [20:14:55] although I wouldn't expect MultimediaViewerNetworkPerformance to be huge [20:15:05] tgr: the limit you send does not apply beyong ie7 i do not think [20:16:03] tgr: Sorry, ie8 is there too. Note that EL is not supported for it's 1k [20:16:38] but, the thing is, all events that fail are printed cropped at 1k [20:16:46] we completely disable JS for IE<8 AFAIK [20:16:52] and all the validating events are less than that (smaller) [20:16:54] tgr: right [20:16:58] but IE8 could run into the length limit [20:17:15] tgr: For resourcetiming? [20:17:26] tgr: it doesn't have that api, right? lemme check [20:17:52] tgr: it does not [20:18:29] tgr: http://caniuse.com/#search=Resource [20:18:32] MultimediaViewerNetworkPerformance has short fields - two domain names and a bunch of numbers [20:19:03] I don't think it can grow large unless some field is filled with wrong data [20:19:21] mforns: do you have some examples of invalid requests? [20:19:28] sure [20:19:30] %7B%22event%22%3A%7B%22type%22%3A%22image%22%2C%22contentHost%22%3A%22ja.wikipedia.org%22%2C%22isHttps%22%3Afalse%2C%22total%22%3A2084%2C%22urlHost%22%3A%22upload.wikimedia.org%22%2C%22status%22%3A200%2C%22XCache%22%3A%22cp1050%20miss%20(0)%2C%20cp4006%20miss%20(0)%2C%20cp4014%20frontend%20miss%20(0)%22%2C%22varnish1%22%3A%22cp1050%22%2C%22varnish1hits%22%3A0%2C%22varnish2%22%3A%22cp4006%22%2C%22varnish2hits%22%3A0%2C% [20:19:31] 22varnish3%22%3A%22cp4014%22%2C%22varnish3hits%22%3A0%2C%22XVarnish%22%3A%22645968118%2C%20731321378%2C%201599345166%22%2C%22contentLength%22%3A328437%2C%22age%22%3A1%2C%22timestamp%22%3A1425249599%2C%22lastModified%22%3A1394877408%2C%22redirect%22%3A0%2C%22dns%22%3A0%2C%22tcp%22%3A108%2C%22request%22%3A1208%2C%22response%22%3A767%2C%22cache%22%3A1%2C%22uploadTimestamp%22%3A%2220120930000000%22%2C%22imageWidth%22%3A128 [20:19:31] 0%2C%22country%22%3A%22JP%22%7D%2C%22revision%22%3A11030254%2C%22schema%22%3A%22MultimediaViewerNetworkPerformance%22%2C%22webHost%22%3A%22ja.wikipedia.org%22%2C%22wiki [20:19:43] wait [20:20:29] is that all? [20:20:33] is this pastable in pastebin? or has it private issues? [20:20:34] that's around 600 bytes [20:20:46] that is exactly 1k [20:21:02] nothing beyond standard EL stuff like user agent [20:21:19] and the curious thing is that all events that do not validate are cropped at that size [20:21:25] that is only part of the event [20:21:32] you can create a private paste in phabricator if you really want to play it safe :) [20:21:33] the rest got lost I think [20:21:47] this, or the logging module is cropping it to 1k [20:21:48] mforns: well, it could be that the log is printing teh event cropped [20:21:59] mforns: it doesn't mean the event itself is cropped [20:22:14] sure [20:22:14] mforns: ah sorry, we are saying the same thing [20:22:16] are there valid events which are cropped? [20:22:25] should be easy to tell via the closing } [20:22:31] what I am saying is that all events that fail are cropped, and all that pass are smaller [20:22:40] not cropped (at least the ones that I've seen) [20:22:57] tgr: that is the error log so only events that do not validate are posted there. [20:23:07] tgr: so you know this can be easily tested on beta labs [20:23:32] tgr: events are processed in the varnish enepoint teh same way they rae in prod [20:23:34] *are [20:24:24] anyway, the even mforns posted is not huge, the full payload is inside the 1K part apart from some of the generic EL fields [20:24:39] you're right [20:25:08] nuria: I'm a bit wary of using beta to understand how exactly things work in production [20:25:14] had bad experiences with that :) [20:25:22] tgr: there is no difference when it comes to EL [20:25:35] tgr: it allows to catch errors earlier [20:25:49] tgr: cannot speak for mediawiki though [20:26:33] anyway if this really is a size-related problem, the only anomaly I can think of is an extremely large user agent string [20:26:43] but that should be very rare [20:27:25] http://stackoverflow.com/a/6595973/323407 [20:28:27] ok joal, your cluster should be better now, sorry bout that! [20:29:15] np,thx man [20:31:28] tgr, what about the XCache and XVarnish fields? [20:32:25] tgr: ya, i doubt is size related [20:32:52] mforns: they are the relevant HTTP headers [20:32:58] a few dozen bytes [20:33:05] aha [20:53:04] Analytics-Engineering, Analytics-Kanban: Backfilling EL events from 20150206 to 20150210 - https://phabricator.wikimedia.org/T89269#1079620 (Nuria) [21:29:01] (PS3) OliverKeyes: Avoid excluding Wikidata pageviews [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193513 [21:29:17] (CR) OliverKeyes: "Great idea, Nuria! Done :D" [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193513 (owner: OliverKeyes) [21:44:01] nuria, milimetric: hey [21:44:09] why do we look at diffs in horrible ways, we should do something like this: http://jsfiddle.net/milimetric/sv9b4ggm/1/ [21:44:13] hi Krenair, what's up [21:44:23] I need to make progress on https://phabricator.wikimedia.org/T88027 [21:44:46] * milimetric reads [21:45:12] Krenair: ok, so looks like all your patches are merged for that? [21:45:20] the core dependencies, yes [21:45:27] I still need saveFailure.type fixed [21:45:36] ok, and what's the blocker there? [21:45:41] and some sort of sense made of abort.type [21:45:50] still need to decide what to include / exclude? [21:46:09] (sorry, not been following your patches) [21:46:16] Ideally it'd accept an integer for an EditPage constant [21:46:41] or something that can be mapped from one [21:47:00] EditPage constant? Oh like failure would just record the integer value from wikitext you're saying [21:47:10] that way you don't have to change the schema when those constants change [21:47:11] hm... [21:47:34] because right now it can only handle EditPage::AS_CONFLICT_DETECTED and EditPage::AS_ARTICLE_WAS_DELETED [21:48:04] right, but it's important that those are the same as the current "conflict" and "pageDeleted" values [21:48:16] what? [21:48:21] hold on [21:49:08] sorry, it was "editConflict" and "editPageDeleted" [21:49:38] right now I assume those are the same as the editpage constants [21:49:39] I'm trying to say, what you emit from wikitext should match what ve emits [21:49:50] so you can use the integer constants, I can translate them on the analysis side [21:50:00] the rest does not map and I have to leave responseUnknown [21:50:05] and as long as you add proper comments and explanation in the schema, that's totally fine with me [21:50:15] but then you should change the VE instrumentation to use the constants as well [21:50:23] I'm not touching the Schema myself. I have no idea what I might break by touching that. [21:50:46] oh, fear not, you can totally touch the schema, I can explain that quickly [21:50:59] the current code, in VE javascript just refers to a specific revision id of the schema [21:51:19] so no matter what you do, unless you delete the current revision (don't do that) you won't break the current instrumentation [21:51:50] and if you make a new revision, you can use that from wikitext and migrate VE to it later. In the meantime, you leave me a headache of joining text with integers but I'll be fine [21:52:06] make sense? [21:52:53] If you decide what you want to do, I can change the schema for you, if you're still not comfortable [21:53:01] okay... [21:56:17] sorry, I'm not sure what that means :) [22:11:31] milimetric, this might make it difficult for visualeditor to fill in the schema [22:12:12] it probably doesn't get this information [22:16:49] Krenair: yeah, so you'd either have to register a JS variable with those codes, hard code them, or log human-readable names from wikitext [22:17:52] I *guess* you could make that failure.type field take "1" as "pageDeleted" and "pageDeleted" as "pageDeleted" as well, and I'll merge them in the analysis [22:17:59] but that makes for nasty data [22:30:08] Analytics: Upgrade daily/monthly aggregations of pageview dumps to new data files - https://phabricator.wikimedia.org/T90203#1080139 (ezachte) It should be easy to migrate aggregation scripts to pagecounts-all-sites (at least in theory), because the new files are on purpose very much downward compatible, al... [22:44:03] milimetric, that's not really the issue [22:46:56] we'd need both editors to be able to properly record the errors they see [22:52:04] (CR) Ottomata: [C: 2 V: 2] Avoid excluding Wikidata pageviews [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193513 (owner: OliverKeyes) [23:02:26] (PS1) OliverKeyes: Include mediawiki.org pageviews [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193982 [23:04:42] (PS2) OliverKeyes: Include mediawiki.org pageviews [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193982 [23:05:35] (CR) Ottomata: [C: 2 V: 2] Include mediawiki.org pageviews [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193982 (owner: OliverKeyes) [23:13:02] Analytics: Los Alamos collaboration - https://phabricator.wikimedia.org/T91331#1080335 (ggellerman) NEW a:DarTar [23:13:28] Analytics: Los Alamos collaboration - https://phabricator.wikimedia.org/T91331#1080343 (ggellerman) [23:13:35] milimetric? [23:13:51] Analytics: Los Alamos collaboration - https://phabricator.wikimedia.org/T91331#1080335 (ggellerman) @kevinator using Phab to capture work related to the implementation of Reid’s proposal [23:14:50] Analytics: Los Alamos collaboration - https://phabricator.wikimedia.org/T91331#1080364 (ggellerman) [23:14:51] Analytics-Cluster, Analytics-Kanban: Geo-coding UDF - https://phabricator.wikimedia.org/T77683#1080365 (ggellerman) [23:14:59] Krenair: so I thought the problem is that EditPage and the VE javascript don't share "constants" [23:15:05] in this case, integer codes for errors [23:15:25] right? [23:16:33] It doesn't even particularly need to be EditPage's exact values [23:16:45] We just need some way for both of the editors to log their failure types [23:16:59] (PS1) OliverKeyes: Include search consistently [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193985 [23:17:00] In the same format, consistently. WikiEditor on the server, VE on the client [23:17:33] No work has been done on the code for a week because there is no clear way forward here [23:17:54] (btw, a book on Hadoop is the O'Reilly deal of the day today) [23:19:14] Krenair: there's no magic I can think of. It's either: hardcode the value in one place or another, or hoist the values from EditPage into JS variables so VE can read them [23:19:21] that's what I was trying to say above [23:19:26] i'll brb 10 min. [23:19:33] (PS2) OliverKeyes: Include search consistently [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193985 [23:26:16] Analytics-Cluster, Analytics-Kanban: Geo-coding UDF - https://phabricator.wikimedia.org/T77683#1080402 (Ottomata) Oh forgot I said we would do that. Hm. CCing Joseph. [23:29:39] Analytics: Publish aggregate geodumps of article pageviews - https://phabricator.wikimedia.org/T91331#1080423 (DarTar) [23:30:17] joal https://gerrit.wikimedia.org/r/#/c/171056/ [23:30:41] xmldump avro schema there ^ [23:30:45] just want you to have a reference to it [23:32:26] k [23:35:39] Krenair: I'm back. So, do you see what I mean, or am I misunderstanding? [23:36:16] Neither of those are okay solutions [23:40:09] (CR) Nuria: [C: 1] "This follows suite so +1." [analytics/refinery/source] - https://gerrit.wikimedia.org/r/193985 (owner: OliverKeyes) [23:43:48] Krenair, milimetric : do you want to do a small hangout on the issue of errors of both editors? [23:44:02] nuria: sure, in the batcave [23:44:07] https://plus.google.com/hangouts/_/wikimedia.org/a-batcave [23:44:07] I think I need to speak to Roan about it [23:44:19] It's not a good time for me to do a hangout [23:44:33] Krenair: sounds good. [23:44:51] nuria: you wanna talk about it? I'm in the cave [23:44:55] Krenair: just let us know. [23:45:38] Krenair: errors on server and client are just not going to match (different platforms, different editors) we just have to find a common lingo to intercompare them somewhat. [23:45:50] milimetric: sure, coming [23:46:04] I was wondering if we can find some way to achieve it actually [23:46:26] Krenair: of course we can, talk to roan get his input and we can work with that. [23:47:07] Krenair: I do not think the task needs to be blocked, both editors are already working and reporting errors, it's just a matter of capturing them. [23:47:40] Do we need saveFailure.type and abort.type for this to be useful? [23:48:59] Krenair: yes, saveFailure.type is used in this kind of analysis: https://edit-analysis.wmflabs.org/adhoc.html#ve-failures.tsv [23:49:22] abort.type is not being used yet, but there are lots of questions being asked about it, so we'll need that too [23:49:51] Krenair, milimetric that being said teh answer could be "well we cannot get that piece of data in the server quite yet" [23:50:57] milimetric, could you +2 https://gerrit.wikimedia.org/r/#/c/193990/ [23:51:08] Krenair: I'd say this: at this point, if client and server values for those fields don't match exactly, that's ok to start [23:51:14] we need data more than we need perfect data [23:52:23] is the server-side logging only two ('editConflict', 'editPageDeleted' - otherwise, 'responseUnknown') types usefully OK? [23:52:25] if the best we can do right now is log conflict and page deleted, then that's ok, we can work with that to start and add more later [23:52:27] If not, we need to rethink this [23:52:40] Krenair: yeah, that's useful, and we can iterate later