[07:47:24] PROBLEM - Difference between raw and validated EventLogging overall message rates on graphite1001 is CRITICAL: CRITICAL: 26.67% of data above the critical threshold [30.0] [07:58:03] RECOVERY - Difference between raw and validated EventLogging overall message rates on graphite1001 is OK: OK: Less than 20.00% above the threshold [20.0] [10:27:05] 2016-03-17 10:24:03,037 INFO org.apache.hadoop.ha.ZKFailoverController: Trying to make NameNode at a102.analytics.eqiad.wmflabs/10.68.17.92:8020 active... [10:27:08] 2016-03-17 10:24:30,719 INFO org.apache.hadoop.ha.ZKFailoverController: Successfully transitioned NameNode at a102.analytics.eqiad.wmflabs/10.68.17.92:8020 to active state [10:27:27] :) [10:34:19] Analytics-Cluster: Add automatic failover to the Hadoop's name node - https://phabricator.wikimedia.org/T129838#2128869 (elukey) p:Triage>Normal a:elukey [10:36:37] Analytics-Kanban: Modify oozie Webrequest-Load job not to fail in case of minor statistics error - https://phabricator.wikimedia.org/T130187#2128874 (JAllemandou) [10:43:06] Analytics-Cluster: Add automatic failover to the Hadoop's name node - https://phabricator.wikimedia.org/T129838#2128894 (elukey) Tried the change in labs disabling puppet on a101 and a102 nodes. Changes applied following the hadoop guide: Pre-step: installed the hadoop-hdfs-zkfc node (Health checks + leader... [11:11:11] all right I am running puppet again on a101/1002 to restore the previous configs, now I need to figure out what changes to add in puppet to make this work :D [11:13:19] elukey: Hi o/ [11:13:45] elukey: So taht means we'll have namenode failover soon ? [11:14:08] yessss [11:14:14] :) [11:14:40] Niiiiiiiice :D [13:09:55] joal: first draft that Andrew will probably trash :D https://gerrit.wikimedia.org/r/#/c/277984 [13:10:21] I was trying to use the puppet compiler but I think I can't with submodules [13:12:00] anyhoooow, brb lunch :) [13:12:29] Analytics, Pageviews-API, Services, RESTBase-API: Document that wikimedia pageviews API is blocked by ad blockers - https://phabricator.wikimedia.org/T126947#2129472 (mobrovac) [13:38:34] Unnhg [13:38:36] mforns: [13:38:49] this is why I thikn rsyncing with multiple sources to the same destination is bad :) [13:39:09] milimetric, mforns, do we have to put the stat1002 reportupdater stuff in the same directory? [13:39:13] as the stat1003 stuff? [13:40:16] you mean the output as it gets rsynched or the jobs themselves [13:40:22] rsynced [13:40:40] yeah, that's useful to go to the same place [13:42:34] ottomata, thx [13:43:05] mforns: running puppet, will manually run the rsync once and you can check it [13:43:25] ottomata, thanks a lot [13:43:45] ottomata: hellooooo [13:43:59] hi! [13:44:18] ottomata: whenever you have time, is it vaguely correct? https://gerrit.wikimedia.org/r/#/c/277984 [13:44:40] milimetric, hi! was thinking about the dashiki tabs layout submenu idea [13:45:53] maybe we can just add a line below the tabs (within the scrollable component) that reads: Graphs in this tab: blah(clickable) - bloh(clickable) - bluh(clickable) [13:46:17] elukey: nice! this looks great! [13:46:25] that's cool but it would take more space [13:46:31] more vertical space [13:46:34] Add some documentation about what happens if ha_enabled and zookeeper_hosts is set in cdh::hadoop [13:46:38] or in the main cdh README [13:46:50] milimetric, it would be just one line [13:46:51] did you browse the semantic ui menu and dropdowns, maybe they have something [13:47:15] we could definitely try it [13:47:44] milimetric, I thought we didn't want to have dropdowns, because people looking at the default tab, wouldn't hover on the menu [13:47:49] wait [13:47:51] i'm confused [13:47:58] mforns: [13:48:08] ottomata, aha [13:48:20] shouldn't the rsync stay the same [13:48:27] and the output on stat1002 go to output/metrics/browser? [13:48:46] ottomata, mmm I don think so [13:48:49] no? [13:48:49] so [13:48:52] on stat1003 [13:49:03] brb [13:49:03] this is the rsync [13:49:06] /usr/bin/rsync -rt /srv/reportupdater/output/* stat1001.eqiad.wmnet::www/limn-public-data/ [13:49:06] I see what you mean [13:49:09] and [13:49:17] /srv/reportupdater/output/ has a metrics folder [13:49:21] but also a bunch of other ones [13:49:38] why would we want that different on stat1002? [13:49:57] (i mean, i don't think we should be rsyncing from the same source to the same dest anyway, but the rsync from output/metrics/ on stat1002 doesn't fix that :) ) [13:50:13] (sorry, different sources to the same dest) [13:50:25] mmm [13:50:47] ottomata, elukey: eventlog1001/2001 need a reboot for a kernel upgrade, can we do that today or tomorrow? [13:50:48] say for some reason something is misconfigured to run on both stat1002 and stat1003 [13:50:51] and they both write the same filenames [13:51:12] since the rsync is automated, each one will fight the other [13:51:17] mforns: we could also put the legends in an accordion: http://semantic-ui.com/modules/accordion.html [13:51:25] and the graphs would be the items in there [13:51:35] food for thought, we should try all these things [13:52:06] anyway, mforns not going to argue about that now [13:52:08] but, ja [13:52:17] if the jobs on stat1003 output into metrics/ [13:52:22] why wouldn't they on stat1002 as well? [13:53:03] ottomata, I understand the metrics folder in stat1003 was intended to unify the new reports created for Dashiki [13:53:12] ok [13:53:15] is browser for dashiki? [13:53:20] ottomata, yes [13:53:28] then it should be in metrics on stat1002, no? [13:54:12] maybe... I think it makes sense in stat1003, because there's legacy data outside the metrics folder [13:54:22] but in 1002 there's no other legacy data [13:54:46] I don't know [13:54:55] I can change that, np [13:55:09] moritzm: definitely, but I have no idea about how to do it. I'll ask to the team and then I'll do it tomorrow EU time [13:55:34] mforns: i think consistency is more important [13:55:35] milimetric, I see [13:55:56] there could be other non dashiki / metrics created on stat1002 via reportupdater one day, no? [13:55:57] ottomata, OK will do that [13:57:59] ottomata, yes, but at the same time we're replicating a non-optimal folder structure from stat1003 no? [13:58:20] I don't see any reason to have a metrics folder except analogy with 1003 [13:58:26] which is OK [13:58:56] hmm [13:59:08] i guess, maybe milimetric has an opinion [13:59:28] hehheh, if we are going to try to make things optimmal...we should not use limn-public-data :p [13:59:39] ottomata, if you look at http://datasets.wikimedia.org/limn-public-data/ you can see what we have now under limn-public-data [13:59:43] elukey: ok (and let's also add it to the "Service restarts" page :-) [13:59:53] ottomata, hehe exactly [14:02:55] moritzm: sure! [14:03:01] does all of dashiki work from just metrics/? [14:03:07] or does it use that other stuff too? [14:05:11] man this problem of folders on 1002 / 1003 / 1001 has taken up so much of our time. You all wanna get together and figure it out in batcave / etherpad? [14:05:19] ottomata, just metrics [14:05:25] no it's not just metrics [14:05:26] ottomata: added documentation in Readme.md and hadoop.pp (https://gerrit.wikimedia.org/r/#/c/277984/3). I thought about adding auto_failover but then I saw that Yarn's autofailover is automatically added, so I thought to do the same with the namenode for consistency.. [14:05:31] it's convoluted and complicated [14:05:37] mmm [14:05:50] I mean, it's technically just metrics now, but it can access anything [14:06:16] metrics is the place it goes for convention-based metrics that have a metric / submetric / wiki.tsv structure [14:06:23] the root path for accessing report files in dashiki is /limn-public-data/metrics no? [14:06:30] I see [14:06:39] but I'd really rather either fix everything or keep everything the same, it's way too confusing to partially clean in this scenario [14:06:50] agree [14:07:25] I think we shouldn't include this fix as blocker to the browser reports [14:08:12] but that's just my thougt, maybe we can discuss it and see? [14:10:48] elukey: cool, that sounds fine then. just added some more comments [14:11:17] batcave? [14:11:22] mforns: milimetric? [14:11:30] ottomata, sure omw [14:12:44] milimetric: ? [14:12:49] sorry [14:12:50] .lol [14:33:36] ottomata: re: exec - what about adding refreshonly true AND subscribe to hadoop-hdfs-zkfc? [14:33:49] it should be fine and safer in this way [14:54:50] elukey: naw, because then whenever hadoop-hdsf-zkfc is started or restarted, it will try to run [14:55:09] also, hadoop-hdfs-zkfc will run on multiple machines, ja? [14:55:11] both namenodes? [14:55:20] so in that case it would at least run twice [15:01:57] elukey: i guess try to examine what the zookeeper format command does [15:02:03] maybe there is som elocal file it creates you can depend on? [15:08:08] ottomata: I don't think that running it each time that restart will do a lot of damage, but I can't find any good doc about what it does [15:13:12] the problem is that I don't know what znodes it creates [15:13:34] and I believe that a smart client should check if the znode is still there, and use it without re-creating it [15:17:41] $ hdfs zkfc -formatZK [15:17:42] This will create a znode in ZooKeeper inside of which the automatic failover system stores its data. [15:18:09] I guess I should try what happens when you execute the command on a live scenario [15:18:12] with failover enabled [15:28:50] elukey: check! [15:29:02] /usr/lib/zookeeper/bin/zkCli.sh [15:29:35] (sorry have been meaning to type at you, but have been talking in batcave) [15:30:26] /usr/lib/zookeeper/bin/zkCli.sh -server conf1001.eqiad.wmnet:2181 [15:30:44] run your formatZK command in labs or something [15:30:47] and look at a labs zookeeper [15:30:54] ls / around and look for the znode [15:31:59] when you knwo what the path is [15:32:00] you can do [15:32:31] madhuvishy: standduppp [15:32:41] Analytics: Clean up datasets.wikimedia.org - https://phabricator.wikimedia.org/T125854#2129918 (Milimetric) We have a plan!!! updating description [15:33:15] /usr/lib/zookeeper/bin/zkCli.sh -server conf1001.eqiad.wmnet:2181 ls /path/to/hdfs/znode | grep ... [15:33:23] or maybe get /path/to/hdfs/znode [15:33:24] instead of ls [15:36:56] Analytics: Clean up datasets.wikimedia.org - https://phabricator.wikimedia.org/T125854#2129925 (Milimetric) [15:37:30] Analytics: Clean up datasets.wikimedia.org - https://phabricator.wikimedia.org/T125854#1998898 (Milimetric) p:Low>Normal [16:09:42] buuut elukey eventlog1001 [16:09:44] ja you can reboot [16:09:48] ummm [16:10:44] yeah, i think you can just reboot it [16:16:50] ottomata: (re: /path/to/hdfs/znode) I do agree that it would be feasible to shellout a command to check zookeeper, but wouldn't it weaken the whole puppet class? It is not transparent what the hdfs zkfc -formatZK does and we should threat it as black box no? [16:21:18] ottomata: wanna go? http://kafka-summit.org/hackathon/ [16:23:37] madhuvishy: yeah!!!!! [16:23:46] we could hack on json(schema) for kafka connect [16:24:10] ottomata: sure! [16:28:45] madhuvishy: ok cool i'm rsvping [16:28:49] oh that is a bike polo night [16:28:50] oh nooo [16:28:51] oh well [16:28:52] its worth it [16:28:52] :) [16:40:03] (PS1) Nuria: Adding browser report to dashiki deploy config [analytics/dashiki] - https://gerrit.wikimedia.org/r/278025 (https://phabricator.wikimedia.org/T130069) [16:41:21] Analytics-Cluster, Analytics-Kanban, Patch-For-Review: Add automatic failover to the Hadoop's name node - https://phabricator.wikimedia.org/T129838#2130201 (elukey) [16:56:46] nuria, milimetric, madhuvishy: one of you may want to respond to this: https://lists.wikimedia.org/pipermail/wiki-research-l/2016-March/005093.html ? [16:57:28] I got it leila, thx [16:57:47] perfect. thanks milimetric. :) [17:03:06] I'm at the "Wait for analytics to deploy new versions of refinery and refinery-source to analytics cluster" step of my checklist on https://phabricator.wikimedia.org/T108618 -- how do I know when that has happened? [17:04:03] Today would be the last chance this week to test the MediaWiki->Kafaka->Oozie->Hive pipeline [17:08:36] Analytics-Kanban: browser_general table should have documenting page in wikitech - https://phabricator.wikimedia.org/T130060#2130261 (Nuria) a:mforns>None [17:29:28] bd808: we deployed just recently, I am not sure we are deploying this week again cc joal FYI that we are working in a more streamline way to handle deployments next quarter [17:29:31] Hi bd808, IIRC your oozie code has been merged and deploy, readyto be launched [17:30:08] joal, in the end I took almost all time of your chat with Dan, sorry for that [17:30:28] no worries mforns, we ended fairly quickly ;) [17:30:34] ok :] [17:30:53] nuria, joal: awesome. Can I get somebody to help with T129889 and T129886 ? [17:30:53] T129886: Create wmf_raw.ApiAction table - https://phabricator.wikimedia.org/T129886 [17:30:53] T129889: Create mediawiki_ApiAction Kafka topic - https://phabricator.wikimedia.org/T129889 [17:30:57] madhuvishy: retro? elukey ? [17:31:24] cominggg [17:31:34] nuria: joining in a minute [17:31:50] bd808: I can take care of T129889 after current meeting (in 1/2 hour° [17:31:50] T129889: Create mediawiki_ApiAction Kafka topic - https://phabricator.wikimedia.org/T129889 [17:32:11] Oops, not, I mean the other one sorry bd808, about creating the hive table [17:32:48] joal: cool deal. [17:33:20] Analytics, MediaWiki-API, Reading-Infrastructure-Team: Create wmf_raw.ApiAction table - https://phabricator.wikimedia.org/T129886#2130358 (bd808) a:JAllemandou [17:35:54] Analytics, MediaWiki-API, Reading-Infrastructure-Team, MW-1.27-release-notes, and 2 others: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618#2130359 (bd808) [17:38:41] Analytics, MediaWiki-API, Reading-Infrastructure-Team, MW-1.27-release-notes, and 2 others: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618#2130379 (bd808) [17:39:37] joal: I rechecked the check list that I'm using and the table creation may not be needed until we have data on HDFS [17:39:55] bd808: correct, but it's done:) [17:40:00] So no bother ;) [17:40:04] sweet. [17:40:36] getting the kafka partitions made is the only blocker then I guess [17:40:37] bd808: uncool thing is no data = no test :( [17:40:46] So table is here, but not tested [17:40:54] *nod* [17:40:54] bd808: --^ [17:40:58] k [17:41:00] :) [17:41:15] You can close the task about creating the table bd808 ;) [17:42:56] Analytics, MediaWiki-API, Reading-Infrastructure-Team: Create wmf_raw.ApiAction table - https://phabricator.wikimedia.org/T129886#2130400 (bd808) a:JAllemandou>None @JAllemandou made the table, but we don't have any data in HDFS yet to test it. Leaving this open until we can verify that Hive can... [17:58:34] bd808: about kafka topic creation, I think ottomata is the person to go to :) [17:59:06] joal: we have auto create topics on as far as i know [17:59:56] madhuvishy, bd808, yes, for testing purposes that is ok, but depending on volume, we might want to manually create the topic to assign the correct number of partitions [18:00:05] joal: ah yes [18:00:09] you are correct [18:00:27] this will be a very high volume channel [18:00:33] >5k/s [18:00:50] bd808: ya probably 12 partitions like our webrequest topics [18:01:08] hey guys.. quick question... are there any web based consumers of the page view API that show graphs of mobile traffic? [18:01:09] andrew needs to make them [18:01:12] yup, maybe even more if we want to spread the load [18:01:19] i want to monitor page view traffic over this month [18:01:28] specifically mobile web per project [18:01:32] bd808: just joined convo [18:01:34] whatsup? [18:01:41] jdlrobson: tools.wmflabs.org/pageviews [18:02:32] jdlrobson: this is a community member built tool improvising on the demo that mforns built [18:02:45] yay i knew there would be something! awesome! thanks madhuvishy - does it allow all pages? [18:02:48] or is it only for certain pages? [18:03:01] jdlrobson: ah yeah i don't think it's per project [18:03:03] jdlrobson: only fopr certain pages yes [18:03:07] https://vital-signs.wmflabs.org/#projects=all,eswiki,itwiki,enwiki,jawiki,dewiki,ruwiki,frwiki/metrics=Pageviews [18:03:07] doh [18:03:11] where can i fork it? [18:03:14] jdlrobson: --^ [18:03:23] awesome perfect! [18:03:24] thanks joal [18:03:33] With this one you can split bybreakdown [18:03:35] ah yes i forgot about vital-signs [18:03:39] ;) [18:03:46] ah joal madhuvishy tht's only desktop? [18:04:04] oh no it's all of them [18:04:08] i just need to work out how to filter.. [18:04:12] jdlrobson: click data breakdozn button [18:04:36] jdlrobson: shows you desktop and mobile [18:04:48] (on mobile you have web+app) [18:05:06] Analytics, Pageviews-API, Services, RESTBase-API: Document that wikimedia pageviews API is blocked by ad blockers - https://phabricator.wikimedia.org/T126947#2130511 (Milimetric) Yeah, if it's truly ad-blockers' intention to ban all analytics-related content, it won't be long before they ban any me... [18:05:06] if you need web only, I think the easiest is to fork vital code [18:05:12] jdlrobson: --^ [18:05:26] joal: I only see desktop [18:05:27] shoot i need web only :/ [18:05:43] where can i find the code? there's no fork me on github link [18:05:58] Then easiest is to fork vital sign (js only), to manually specify web only [18:06:01] I think [18:06:09] looping in milimetric ^ [18:06:26] eswiki: mobile-web: 17.29M [18:06:29] seems to be mobile web only? [18:06:40] i just can't change data breakdown to only show the mobile web [18:06:43] jdlrobson: it's a dashboard built with dashiki - https://github.com/wikimedia/analytics-dashiki [18:06:44] i cant tell what's what [18:07:08] joal: it does say mobile-web [18:07:18] even though i dont know why [18:07:25] there's no mobile-app [18:07:53] madhuvishy: Oooooohh, it might bemobile web actually ! [18:08:10] Now that we have changed the way vital-signs grabs its data ! [18:08:12] joal: ya but there's no way to just show mobile-web though [18:08:12] it's mobile-web [18:08:23] which is what jdlrobson wants i think [18:08:29] right [18:08:43] milimetric: riiight, now that we use api directly, we have correct mobile web, not web+app ! [18:08:51] jdlrobson: you want a dashboard with mobile-web with all wikis? Or just the data for some wikis is enough? [18:08:53] cool [18:09:02] it also means we can show mobile app but dont [18:09:12] true madhuvishy :) [18:09:13] right, true [18:09:17] Would be very small though [18:09:26] not so small with iOS [18:09:36] getting like 5 mil. / day or so, they broke piwik [18:09:40] milimetric: looking at this dashboard it's fine - it's just a bit noisy since it shows desktop traffic and all traffic as well (all i care about is web) [18:09:43] yup - but we should show it no - this way all-access!=mobile-web+desktop [18:09:47] right, but it's in piwik only, no? ;) [18:10:19] jdlrobson: got it, if it's not urgent file a bug and I can make the breakdown on the left into a checkbox-list and push it to the URL when you change it, so you can bookmark exactly what you need [18:10:36] it should be very easy to do and I can pair program with you if you wanna learn this codebase, it's actually really fun to work on [18:10:54] milimetric: we should have that as a task, and add mobile-app to the breakdown instead of zero [18:11:01] yep [18:11:08] milimetric: if it's fun, go for it now :) [18:11:20] nono, I have to do the very not fun thing now [18:11:24] you're trying to tempt me! [18:11:25] * joal wants more fun [18:11:38] :D [18:11:39] * madhuvishy wants more sleep [18:11:45] haha, take a nap!! [18:11:49] * joal has fun [18:11:52] analytics will be here when you wake up [18:12:12] Go to sleep madhu, no good to work without sleep :) [18:12:24] a-team, I'm done for today :) [18:12:28] :) [18:12:32] Have a good weekend ! [18:12:34] joal, good night1 [18:12:43] mforns: you should go to sleep toooo ! [18:12:58] yes I'm going too, bye a-team [18:13:09] nite [18:13:13] :] [18:13:27] milimetric: might have some bandwidth tomorrow if you are interested :) [18:13:57] jdlrobson: sure, anytime, I can drive and take a stab at it, you can review or improve [18:14:32] joal, mforns: o/ [18:30:14] Analytics-Tech-community-metrics, DevRel-March-2016: Make GrimoireLib display *one* consistent name for one user - https://phabricator.wikimedia.org/T118169#2130570 (Aklapper) Looking at http://korma.wmflabs.org/browser/top-contributors.html I see e.g. "Catrope" listed as #1. But clicking that name, I [[... [18:31:11] Analytics-Tech-community-metrics, DevRel-March-2016, Regression: top-contributors.html only displays seven entries - https://phabricator.wikimedia.org/T129837#2117561 (Aklapper) [18:31:15] Analytics-Tech-community-metrics: top-contributors should have real names for the main contributors - https://phabricator.wikimedia.org/T124346#2130584 (Aklapper) [18:33:10] Analytics: Deprecate reportcard - https://phabricator.wikimedia.org/T130117#2126320 (Elitre) Deprecate, then replace with...? [18:40:44] going offline a-team! byyyeee [18:42:23] byeye [18:47:12] Analytics-Tech-community-metrics, Developer-Relations, DevRel-March-2016: Play with Bitergia's Kabana UI (which might potential replace our current UI on korma.wmflabs.org) - https://phabricator.wikimedia.org/T127078#2130696 (Aklapper) ===:=== I'd really welcome a basic introduction (text help /... [18:50:56] Analytics-Tech-community-metrics, DevRel-April-2016: Mismatch between numbers for code merges per organization - https://phabricator.wikimedia.org/T129910#2130707 (Aklapper) [18:51:13] Analytics-Tech-community-metrics, JavaScript: Syntax error, unrecognized expression on Korma profiles - https://phabricator.wikimedia.org/T126325#2130710 (Aklapper) p:Triage>Low [18:56:10] Analytics-Kanban: Make deployment process to the cluster easier, more streamlined {hawk} - https://phabricator.wikimedia.org/T129253#2130731 (Nuria) [18:58:30] jdlrobson, madhuvishy , joal: for vital-signs and pageview metric there is a "data breakdown" button [18:58:45] to just show a split of desktop or mobile-web [19:00:36] ah, ok i see you saw that. adding app should be easy yes [19:13:24] Analytics, Analytics-Cluster, Operations, Traffic: Upgrade analytics-eqiad Kafka cluster to Kafka 0.9 - https://phabricator.wikimedia.org/T121562#1881753 (Nuria) Kafka update is needed for future uses of kafkaconnect instead of camus [19:15:47] ottomata: do we have a ticket for the upgrades to eventlogging? [19:16:37] this https://phabricator.wikimedia.org/T114199 [19:16:37] i think [19:17:06] oh, mabye this too [19:17:07] https://phabricator.wikimedia.org/T118772 [19:17:11] Analytics: Ease restarting and backfilling of jobs in cluster {hawk} - https://phabricator.wikimedia.org/T115985#2130805 (Nuria) [19:18:43] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 - https://phabricator.wikimedia.org/T130247#2130820 (Nuria) [19:19:16] Analytics-EventLogging, scap, Scap3 (Scap3-Adoption-Phase1): Move EventLogging service to scap3 - https://phabricator.wikimedia.org/T118772#2130822 (Nuria) [19:19:18] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 - https://phabricator.wikimedia.org/T130247#2130808 (Nuria) [19:19:37] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 - https://phabricator.wikimedia.org/T130247#2130824 (Nuria) [19:19:39] Analytics, Analytics-EventLogging: Upgrade eventlogging servers to Jessie - https://phabricator.wikimedia.org/T114199#2130825 (Nuria) [19:20:05] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 - https://phabricator.wikimedia.org/T130247#2130808 (Waxmigs2902) a:Waxmigs2902 [19:33:05] Analytics: Count requests for all wikis/systems - https://phabricator.wikimedia.org/T130249#2130890 (Nuria) [19:34:13] Analytics: Track pageview stats for outreach.wikimedia.org - https://phabricator.wikimedia.org/T118987#2130899 (Nuria) This work will be done as part of https://phabricator.wikimedia.org/T130249 [19:36:43] ottomata: I missed your ping earlier. My next blocker for T108618 is getting T129889 done. [19:36:44] T108618: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618 [19:36:44] T129889: Create mediawiki_ApiAction Kafka topic - https://phabricator.wikimedia.org/T129889 [19:37:04] ottomata: your name came up for doing the partition creation [19:37:16] sure! [19:37:21] ja let's just give it 12 partitons [19:38:06] cool. can I assign the task to you? [19:38:10] ja [19:38:22] Analytics, Reading-Infrastructure-Team: Create mediawiki_ApiAction Kafka topic - https://phabricator.wikimedia.org/T129889#2130918 (bd808) a:Ottomata [19:39:05] Analytics, MediaWiki-API, Reading-Infrastructure-Team, MW-1.27-release-notes, and 2 others: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618#2130921 (Ottomata) [19:39:07] Analytics, Reading-Infrastructure-Team: Create mediawiki_ApiAction Kafka topic - https://phabricator.wikimedia.org/T129889#2130919 (Ottomata) Open>Resolved ``` $ kafka topic --create --topic mediawiki_ApiAction --partitions 12 --replication-factor 3 Created topic "mediawiki_ApiAction". $ kafka top... [19:39:16] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 {oryx} - https://phabricator.wikimedia.org/T130247#2130922 (Nuria) [19:39:23] ottomata: too easy :) [19:39:40] :) [19:40:25] Analytics: Make Unique Devices Dataset Public - https://phabricator.wikimedia.org/T130252#2130926 (Nuria) [19:42:44] Analytics, Pageviews-API, Services, RESTBase-API: Document that wikimedia pageviews API is blocked by ad blockers - https://phabricator.wikimedia.org/T126947#2130953 (GWicke) The only worry I have would be that '/views/' makes it into one of those lists, but at the same time I'm optimistic that the... [19:42:46] bd808: i think we need to actually deploy the oozie jobs to get the partitions done [19:42:51] buuut, you can go ahead and merge the mw one [19:42:55] and stuff will flow kafka -> hadoop [19:43:03] Analytics: Count requests for all wikis/systems - https://phabricator.wikimedia.org/T130249#2130954 (Krenair) Okay, so everything going via varnish, not all systems. [19:43:31] Analytics: Count requests for all wikis/systems behind varnish - https://phabricator.wikimedia.org/T130249#2130955 (Krenair) [19:43:34] ottomata: cool. that matches the checklist order that ebernhardson made [19:43:43] Analytics: Make Unique Devices Dataset Public - https://phabricator.wikimedia.org/T130252#2130956 (Nuria) Closing as duplicate [19:43:45] ebernhardson: could you review https://gerrit.wikimedia.org/r/#/c/273559/2 for sanity? [19:43:53] Analytics: Make Unique Devices Dataset Public - https://phabricator.wikimedia.org/T130252#2130959 (Nuria) Open>Resolved [19:45:38] Analytics-Kanban: Write Unique devices blogpost - https://phabricator.wikimedia.org/T129498#2130964 (Nuria) [19:45:40] Analytics-Kanban, Patch-For-Review: Make last access data public {mole} - https://phabricator.wikimedia.org/T126767#2130963 (Nuria) [19:45:42] Analytics: Visualize unique devices data in dashiki - https://phabricator.wikimedia.org/T122533#2130965 (Nuria) [19:48:45] Analytics-Kanban, Patch-For-Review: Make Unique Devices dataset public {mole} - https://phabricator.wikimedia.org/T126767#2130995 (Nuria) [19:49:05] Analytics: Deprecate reportcard - https://phabricator.wikimedia.org/T130117#2130997 (Nuria) [19:49:07] Analytics-Kanban, Patch-For-Review: Make Unique Devices dataset public {mole} - https://phabricator.wikimedia.org/T126767#2022824 (Nuria) [19:59:47] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 {oryx} - https://phabricator.wikimedia.org/T130247#2131031 (Waxmigs2902) [19:59:49] Analytics-Backlog: Make eventlogging use jessie + systemd - https://phabricator.wikimedia.org/T120840#2131033 (Waxmigs2902) [20:02:22] Analytics: Deprecate reportcard - https://phabricator.wikimedia.org/T130117#2131040 (Tbayer) I was under the impression that it is still being updated by @Milimetric and @ezachte, just perhaps with a bit of delay (see also T116244). To the perspective of the general public, the report card is at the moment... [20:05:58] Analytics: Make metrics-by-project breakdown interactive and bookmarkable - https://phabricator.wikimedia.org/T130255#2131059 (Milimetric) [20:06:55] Analytics: Wikistats 2.0. Edit Reports - https://phabricator.wikimedia.org/T130256#2131074 (Nuria) [20:07:06] Analytics, Pageviews-API, Services, RESTBase-API: Document that wikimedia pageviews API is blocked by ad blockers - https://phabricator.wikimedia.org/T126947#2131087 (MusikAnimal) Reaching out to the ad block maintainers certainly wouldn't hurt, and I think they'd be inclined to believe we are in f... [20:07:40] Analytics: Wikistats 2.0. Edit Reports - https://phabricator.wikimedia.org/T130256#2131096 (Nuria) [20:07:42] Analytics-Kanban, Analytics-Wikistats, Reading-Admin: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#2131095 (Nuria) [20:08:52] Analytics: Wikistats 2.0. Edit Reports: Source Historical Edit Data into hdfs - https://phabricator.wikimedia.org/T130256#2131074 (Nuria) [20:09:05] Analytics: Wikistats 2.0. Edit Reports: Source Historical Edit Data into hdfs {lama} - https://phabricator.wikimedia.org/T130256#2131074 (Nuria) [20:13:52] Analytics: Pageview datastream on Druid - https://phabricator.wikimedia.org/T130258#2131128 (Nuria) [20:24:06] Analytics-Kanban: Add partitions to webrequest text and upload topics - https://phabricator.wikimedia.org/T127351#2040795 (Ottomata) Just did this in beta for upload and text. All looks good. varnishkafka noticed just like it was supposed to, and just kept working: ``` Mar 17 20:22:18 deployment-cache-text... [20:37:31] Analytics: Opperational improvements and maintenance in Eventlogging in Q4 {oryx} - https://phabricator.wikimedia.org/T130247#2131333 (Aklapper) duplicate>Open a:Waxmigs2902>None [21:33:08] Analytics: Make metrics-by-project breakdown interactive and bookmarkable - https://phabricator.wikimedia.org/T130255#2132188 (Nuria) Make metrics-by-project breakdown interactive and bookmarkable The breakdown is available only for pageview metric. Currently contains desktop and mobile but we could add a... [22:00:58] How do I check to see if events are getting into kafka? [22:01:16] ebernhardson, ottomata: ^ ? [22:01:22] hmmm [22:01:38] I'm running kafkacat -b kafka1012 -t mediawiki_ApiAction -c 1 > api.avro but it just sits there [22:01:53] yeah, doesn't look like anyting is coming [22:01:54] in [22:01:56] based on info at https://wikitech.wikimedia.org/wiki/Analytics/Cluster/MediaWiki_Avro_Logging [22:02:00] hmm [22:02:16] oh. sampled 1/5k [22:02:26] bd808: that should be a 1/s sampling though, right? [22:02:27] some my 3 hits to testwiki ... not enough [22:02:30] oh lol [22:03:22] ok. I'll just sync it live and watch logs [22:25:50] Analytics-Kanban, Research-and-Data-Backlog, Patch-For-Review: Remove Client IP from Eventlogging capsule {mole} - https://phabricator.wikimedia.org/T128407#2132612 (ggellerman) [22:25:54] Analytics, Research-and-Data-Backlog: Percentage of users with DNT on - https://phabricator.wikimedia.org/T127571#2132613 (ggellerman) [22:26:04] Analytics, Analytics-Cluster, Improving-access, Research-and-Data-Backlog: Hashed IP addresses in refined webrequest logs - https://phabricator.wikimedia.org/T118595#2132619 (ggellerman) [22:28:11] argh! I just realized that I called the new logging "ApiRequest" for half the changes and "ApiAction" for the other half [22:28:26] which is not going to work for obvious reasons [22:28:45] I can merge a follow-up [22:29:04] I guess I need to figure out which half is easier to change [22:29:24] I think it's making it all ApiAction that will be easier [22:30:14] But I'm going to have to look at all 7 places to make sure [22:30:25] Analytics, Research-and-Data-Backlog, Research-management: Draft announcement for wikistats transition plan - https://phabricator.wikimedia.org/T128870#2132665 (ggellerman) [22:30:25] * bd808 finishes what he's doing first [22:35:57] Analytics, MediaWiki-API, Reading-Infrastructure-Team, MW-1.27-release-notes, and 2 others: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618#2132719 (bd808) So I messed up and named the logging channel "ApiRequest" in some places (MediaWiki, even... [22:53:58] oh ffs. I called in "ActionApi" rather than "ApiAction" in another place [22:54:24] It's almost like I did this work in dribs and drabs over 5 months :/ [23:00:08] (PS1) BryanDavis: Fix ApiAction record name [analytics/refinery] - https://gerrit.wikimedia.org/r/278193 (https://phabricator.wikimedia.org/T108618) [23:07:03] Analytics, MediaWiki-API, Reading-Infrastructure-Team, MW-1.27-release-notes, and 2 others: Publish detailed Action API request information to Hadoop - https://phabricator.wikimedia.org/T108618#2132875 (bd808) New checklist: [] [[https://gerrit.wikimedia.org/r/#/c/278187/|Rename ApiRequest to ApiAc... [23:08:06] ori: ^ there a whole pile of busted. :/ We'll get it straightened out next week. [23:48:33] (CR) EBernhardson: [C: 2] Drop support for message without rev id in avro decoders and make latestRev mandatory [analytics/refinery/source] - https://gerrit.wikimedia.org/r/255105 (owner: DCausse) [23:48:52] (CR) EBernhardson: [C: 1] Drop support for message without rev id in avro decoders and make latestRev mandatory [analytics/refinery/source] - https://gerrit.wikimedia.org/r/255105 (owner: DCausse) [23:49:17] was only trying to +1 :) i didn't realize i even had +2 there... [23:56:46] Analytics-EventLogging, Patch-For-Review: Provide a robust way of logging events without blocking until network request completes; use sendBeacon - https://phabricator.wikimedia.org/T44815#2132993 (ori)