[01:09:26] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, iOS-5-app-production: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1756072 (RobH) Would there be any drawback to running this inside a ganeti virtual machine, rather t... [01:29:59] Analytics, Deployment-Systems, Services, operations, Scap3: Use Scap3 for deploying AQS - https://phabricator.wikimedia.org/T114999#1756099 (Dzahn) [05:38:14] Analytics-EventLogging, Wikimedia-Logstash: Validation error for invalid value type should include property name - https://phabricator.wikimedia.org/T116719#1756304 (Krinkle) NEW [07:05:30] Analytics, MediaWiki-extensions-Gadgets: Gadget usage statistics - https://phabricator.wikimedia.org/T21288#1756380 (NiharikaKohli) [08:02:07] Analytics-Backlog, Datasets-General-or-Unknown, operations: Requests to dumps.wikimedia.org should end up in hadoop wmf.webrequest via kafka! - https://phabricator.wikimedia.org/T116430#1756432 (Addshore) duplicate>Open Re opened per https://phabricator.wikimedia.org/T116429#1754706 [08:47:57] Analytics-Backlog, Discovery: Display automata and humans separately on zero results rate graph - https://phabricator.wikimedia.org/T112846#1756481 (Deskana) [08:48:05] Analytics-Kanban, Discovery, Discovery-Cirrus-Sprint, Patch-For-Review, WorkType-NewFunctionality: Update CirrusSearchRequestSet schema to have a timestamp field - https://phabricator.wikimedia.org/T115715#1756482 (Deskana) Open>Resolved [10:06:19] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756627 (Anmolkalia) NEW [10:08:25] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756641 (Anmolkalia) [10:11:55] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756655 (Anmolkalia) [10:15:50] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756669 (Anmolkalia) a:Anmolkalia [10:19:45] Analytics-Tech-community-metrics, Possible-Tech-Projects, Outreachy-Round-11: Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T89135#1756676 (Anmolkalia) [10:21:02] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756680 (Anmolkalia) [10:25:36] Analytics, MediaWiki-extensions-Gadgets: Gadget usage statistics - https://phabricator.wikimedia.org/T21288#1756720 (Bawolff) [10:29:47] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756734 (Anmolkalia) [10:30:52] Analytics-Tech-community-metrics, Outreachy-Round-11: Outreachy Proposal for Improving MediaWikiAnalysis - https://phabricator.wikimedia.org/T116733#1756627 (Anmolkalia) @jgbarah, @dicortazar, please suggest improvements in the proposal. Thank you. [10:34:51] !log manual aggregator launch after small bug correction [10:34:54] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [10:36:04] (PS1) Joal: Correct bug in parameter definition [analytics/aggregator] - https://gerrit.wikimedia.org/r/249088 [10:37:01] (CR) Joal: [C: 2 V: 2] "Self merging critical bug." [analytics/aggregator] - https://gerrit.wikimedia.org/r/249088 (owner: Joal) [10:40:47] (PS2) Joal: Update bin/camus to include CamusPartitionChecker [analytics/refinery] - https://gerrit.wikimedia.org/r/248048 (https://phabricator.wikimedia.org/T113252) [11:21:55] (PS3) Joal: Update bin/camus to include CamusPartitionChecker [analytics/refinery] - https://gerrit.wikimedia.org/r/248048 (https://phabricator.wikimedia.org/T113252) [11:37:41] Analytics-Engineering, Wikimedia-Mailing-lists: home page for the analytics mailing list should link to gmane - https://phabricator.wikimedia.org/T116740#1756860 (hashar) NEW [12:01:45] * joal will be back in a few hours [12:58:11] Analytics, Continuous-Integration-Config, WMDE-Analytics-Engineering, Wikidata: Add basic jenkins linting to analytics-limn-wikidata-data - https://phabricator.wikimedia.org/T116007#1757055 (hashar) Don't we want jobs for all the limn data repositories? Currently we have the following Gerrit proj... [13:35:52] (CR) Ottomata: [C: 2 V: 2] Update bin/camus to include CamusPartitionChecker [analytics/refinery] - https://gerrit.wikimedia.org/r/248048 (https://phabricator.wikimedia.org/T113252) (owner: Joal) [13:40:24] Analytics, Discovery, EventBus, MediaWiki-General-or-Unknown, and 6 others: Define edit related events for change propagation - https://phabricator.wikimedia.org/T116247#1757151 (Ottomata) Ok, cool, I'm cool with that, so: `request_id` - UUID1 from Varnish, not necessarily unique for an individua... [13:48:32] Analytics, Discovery, EventBus, MediaWiki-General-or-Unknown, and 6 others: Define edit related events for change propagation - https://phabricator.wikimedia.org/T116247#1757179 (mobrovac) >>! In T116247#1754709, @Ottomata wrote: > What do y'all think about keeping these 'framing' fields in a nest... [14:02:34] hm, a-team, anyone around for me to practice my talk in a few mins? [14:25:44] ottomata: I guess I'm too late ? [14:27:32] nope! [14:27:40] am on phone, few mins [14:29:46] ok joal ja?! [14:30:34] yup [14:30:36] cave ? [14:30:38] ja [14:30:48] git pull [14:30:52] oops :) [14:51:35] Analytics, Discovery, EventBus, MediaWiki-General-or-Unknown, and 6 others: Define edit related events for change propagation - https://phabricator.wikimedia.org/T116247#1757410 (GWicke) > I've been thinking about it too. Ideally, we could leave these fields out of schema defs, simply reference th... [15:05:55] holaaaa [15:06:56] hey nuria [15:07:33] Analytics-Backlog, Analytics-EventLogging, Database: Eventlogging tables not replicating from master to slave - https://phabricator.wikimedia.org/T116599#1753433 (jcrespo) Waiting for confirmation that everithing is ok on your side to close this ticket. [15:10:16] Analytics-Backlog, Analytics-Kanban: Test Elastic search pageview data loading/retrieval on labs - https://phabricator.wikimedia.org/T116763#1757512 (Nuria) NEW [15:11:06] Analytics-Backlog, Analytics-Kanban: Testing druid data loading/retrieval on labs {slug} - https://phabricator.wikimedia.org/T116764#1757527 (Nuria) NEW a:Milimetric [15:11:24] Analytics-Backlog, Analytics-Kanban: Test Elastic search pageview data loading/retrieval on labs {slug} - https://phabricator.wikimedia.org/T116763#1757537 (Nuria) [15:14:05] (PS1) Joal: Update changelog.md preparing for release 0.0.21 [analytics/refinery/source] - https://gerrit.wikimedia.org/r/249140 [15:22:02] Analytics-Backlog, Analytics-EventLogging, Database: Eventlogging tables not replicating from master to slave - https://phabricator.wikimedia.org/T116599#1757586 (Ironholds) mysql:research@analytics-store.eqiad.wmnet [log]> SELECT LEFT(timestamp,8), COUNT(*) FROM MobileWikiAppSearch_10641988 WHERE time... [15:23:48] Analytics-Backlog, Analytics-EventLogging, Database: Eventlogging tables not replicating from master to slave - https://phabricator.wikimedia.org/T116599#1757591 (jcrespo) Open>Resolved [15:25:18] Analytics-Backlog, Database: Set up bucketization of editCount fields {tick} - https://phabricator.wikimedia.org/T108856#1757592 (mforns) Thanks @jcrespo! [15:26:06] Analytics-Kanban, Database: Delete obsolete schemas {tick} [5 pts] - https://phabricator.wikimedia.org/T108857#1757596 (mforns) Thanks again, @jcrespo [15:28:53] Analytics-Kanban: Backfill mobile and upload for oct 20th [3 pts] {hawk} - https://phabricator.wikimedia.org/T116283#1757606 (kevinator) Open>Resolved [15:29:18] Analytics-Backlog: Improve loading Analytics Query Service with data {slug} [subtasked] - https://phabricator.wikimedia.org/T115351#1757610 (kevinator) [15:29:19] Analytics-Kanban: improve timeuuid writing {slug} [5 pts] - https://phabricator.wikimedia.org/T115353#1757608 (kevinator) Open>Resolved [15:29:32] Analytics-Backlog, Analytics-Kanban, Developer-Relations, MediaWiki-API, Research-and-Data: Add Application errors for Mediawiki API to x-analytics - https://phabricator.wikimedia.org/T116658#1757612 (Anomie) > Now, this doesn't include errors like 404s or 503 so only part of the errors from the... [15:29:57] Analytics-Kanban: special character stripping on cassandra loading (tabs) {slug} [5 pts] - https://phabricator.wikimedia.org/T115356#1757613 (kevinator) Open>Resolved [15:29:58] Analytics-Backlog: Improve loading Analytics Query Service with data {slug} [subtasked] - https://phabricator.wikimedia.org/T115351#1722097 (kevinator) [15:30:00] Analytics-Kanban: Document Cassandra SLAS and storage requirements for daily and hourly data {slug} - https://phabricator.wikimedia.org/T116407#1757616 (Milimetric) [15:30:52] Analytics-Backlog: Improve loading Analytics Query Service with data {slug} [subtasked] - https://phabricator.wikimedia.org/T115351#1722097 (kevinator) [15:33:43] OMG I was wondering why no one was at standup.... It's not for another 30 minutes! [15:33:49] Analytics-Backlog, Wikipedia-iOS-App-Product-Backlog, hardware-requests, operations, iOS-5-app-production: Request one server to suport piwik analytics - https://phabricator.wikimedia.org/T116312#1757636 (Milimetric) To add a little bit to the description, the data collected here is sensitive fr... [15:36:03] Analytics: AQS cluster Grafana dashboards - https://phabricator.wikimedia.org/T116590#1757644 (Milimetric) woah :) thx all [15:43:43] Analytics-Kanban: Update oozie diagram [3 pts] {hawk} - https://phabricator.wikimedia.org/T115993#1757664 (kevinator) Open>Resolved [15:45:10] nuria, hi! [15:45:42] mforns: hello, been loading some data into elastic search [15:45:54] mforns: was trying to figure out now how to agreggate [15:45:56] ottomata: forgot to ask you: can you merge milimetric's change on aggregator (--output-projectviews) [15:46:48] Analytics-Backlog, Analytics-Kanban: Testing druid data loading/retrieval on labs {slug} - https://phabricator.wikimedia.org/T116764#1757678 (Nuria) Open>declined [15:46:48] ottomata: https://gerrit.wikimedia.org/r/#/c/247458/ [15:47:18] mforns: i can explain what i have done thus far, checkout README on /home/mforns [15:47:18] nuria: you declined that druid task? ^ [15:47:26] milimetric: it was a duplicate [15:47:29] oh [15:47:35] milimetric: should i close it instead? [15:47:36] you can just merge duplicates in [15:47:43] which is the one you're keeping? [15:47:57] milimetric: https://phabricator.wikimedia.org/T116409 [15:48:21] click the "Merge Duplicates In" and search for T116764 [15:48:28] i just did ... [15:48:31] Analytics-EventLogging, Editing-Department, Improving access, QuickSurveys, and 3 others: Schema changes - https://phabricator.wikimedia.org/T114164#1757708 (leila) @csteipp, correct, we don't need widget impression data so we should register data only if the user responds to the survey. Re when... [15:48:58] weird, not showing up, must be cache [15:48:59] milimetric: no wait [15:49:14] Analytics-Backlog, Analytics-Kanban: Testing druid data loading/retrieval on labs {slug} - https://phabricator.wikimedia.org/T116764#1757712 (Nuria) [15:49:18] Analytics-Backlog, Analytics-Kanban: Druid testing on labs to asses whether is a suitable Cassandra replacement. {slug} - https://phabricator.wikimedia.org/T116409#1757713 (Nuria) [15:49:21] milimetric: ahem, now, i did it right [15:49:24] also - we shouldn't be tagging things with both Backlog and Kanban [15:49:24] milimetric: sorry [15:49:31] they're either in progress or incoming, not both :) [15:49:51] morning a-team :) [15:49:53] milimetric: ahhhh, ok, i thought i'd do that for the ones that were not pointed [15:49:58] milimetric: but ok, note taken [15:50:09] nuria, I've seen the README you left, thanks! [15:50:16] nuria: oh, that makes sense, no, but we can point them in kanban if they're not pointed, we can do that at tasking [15:50:27] mforns: i am trying to figure out how to define agreggations we can work on that today [15:50:35] but it's better they're not in backlog 'cause it'll let us see the new things that we haven't already prioritized [15:50:37] nuria, joal says we don't need to aggregate beforehand, EL has aggregation capabilities [15:50:49] ES? [15:50:50] nuria, yes, let's do that today [15:50:52] mforns: right, but you need to define the schema of agreggations [15:51:04] mforns: let's work on that after standup [15:51:11] mforns: https://www.elastic.co/guide/en/elasticsearch/guide/master/_aggregation_test_drive.html [15:51:23] nuria, I also did some reading and videos, and there's a python client to make bulk insertion easy [15:51:29] mforns: i loaded 10.000 records which should be enough [15:51:33] nuria, mforns depending on deploys I could help if you want :) [15:51:37] nuria, cool [15:53:35] Analytics, Analytics-Cluster, Fundraising Tech Backlog, Fundraising-Backlog, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1757745 (Jgreen) > @Jgreen, most of that looks right. I didn't know about the landingpages.tsv.log bit--is that... [15:53:45] joal: ok, let's talk after you do the deploys [15:54:34] madhuvishy: hola, yt? [15:54:39] nuria: yeah [15:54:49] in zombie jetlagged mode though [15:55:11] ok, we will only ask you basic aritmetic kind of questions ... [15:55:14] Analytics-Kanban: Move camus files from refinery to puppet [3] {hawk} - https://phabricator.wikimedia.org/T113990#1757759 (JAllemandou) a:Ottomata [15:55:14] :) [15:59:31] Analytics, Analytics-Cluster, Fundraising Tech Backlog, Fundraising-Backlog, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1757785 (Jgreen) We need to get this cut over ASAP, as it is blocking Tech Ops in several important ways. [16:00:09] (PS20) Joal: Add cassandra load job for pageview API [analytics/refinery] - https://gerrit.wikimedia.org/r/236224 [16:00:28] Analytics-Backlog, Analytics-Kanban, Patch-For-Review: Remove loading of hourly data from Cassandra loading scripts and hql [5 pts] {slug} - https://phabricator.wikimedia.org/T116408#1757789 (JAllemandou) [16:04:39] Analytics-Kanban: Move camus files from refinery to puppet [3 pts] {hawk} - https://phabricator.wikimedia.org/T113990#1757808 (JAllemandou) [16:08:38] Analytics-Cluster, Analytics-Kanban: Research whether no cookie header numbers improve Last access uniques {bear} [13 pts] - https://phabricator.wikimedia.org/T115350#1757822 (madhuvishy) a:madhuvishy [16:14:54] Analytics: View counts in squid logs, webstatscollector 2.0 and hive are very dissimilar for several projects. - https://phabricator.wikimedia.org/T116609#1757862 (ezachte) [16:15:48] Analytics-Engineering, Wikimedia-Mailing-lists: home page for the analytics mailing list should link to gmane - https://phabricator.wikimedia.org/T116740#1757872 (JohnLewis) p:Triage>Low [16:19:03] milimetric: read the patch about aggregator cron: there is an issue :) [16:19:12] Let's correct that before asking ottomata to merge it [16:32:28] (CR) Ottomata: [C: 2 V: 2] Update changelog.md preparing for release 0.0.21 [analytics/refinery/source] - https://gerrit.wikimedia.org/r/249140 (owner: Joal) [16:34:17] Analytics-Tech-community-metrics, DevRel-October-2015: Correct affiliation for code review contributors of the past 30 days - https://phabricator.wikimedia.org/T112527#1757945 (Luiscanasdiaz) @Aklapper, I've been reviewing the data with my colleague Santiago Dueñas and we discovered that the name we are s... [16:46:16] !log Releasing refinery-source v0.0.21 [16:46:18] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [16:53:55] Analytics-EventLogging, Editing-Department, Improving access, QuickSurveys, and 3 others: Schema changes - https://phabricator.wikimedia.org/T114164#1758014 (csteipp) @leila, all. With the rest of the data that we're now saving in Eventlogging like Schema:Edit and AccountCreation, that would give... [17:14:45] Analytics-EventLogging, Editing-Department, Improving access, QuickSurveys, and 3 others: Schema changes - https://phabricator.wikimedia.org/T114164#1758214 (leila) @csteipp I understand your point. Thanks for providing more context (I did not have a big picture of all the other schema and what th... [17:20:46] milimetric: sorry i didnt follow up with you yesterday [17:20:51] sok [17:20:57] so with https://www.irccloud.com/pastebin/ewbn3cSN/ i get Illegal mix of collations for operation 'UNION' [17:21:24] hm, jdlrobson I ran that query on stat1003, how are you running it? [17:23:43] jdlrobson: yeah, that query works ok, how are you testing? [17:24:37] milimetric: running on s1-analytics-slave [17:25:12] hm... collation might be different on those tables, lemme check [17:26:44] (PS2) Jdlrobson: Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) [17:26:56] milimetric: ^ so in theory that should work minus the collation issue [17:27:03] jdlrobson: yeah, i get that error there too, but we don't use that server [17:27:08] I don't even know what that is... [17:27:18] just merge it, it runs on analytics-store so it'll be fine [17:27:46] for future reference, s1-analytics-slave is some weird old thing, analytics-store has been the place these queries ran since the beginning [17:30:41] jdlrobson: I double checked the collation on s1-analytics-slave and it's the exact same. This would be a ticket to file with the DBAs, I've no idea what's going on. Anyway, it's a moot point, death to whatever s1-analytics-slave is [17:39:59] (PS3) Milimetric: Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:40:37] (CR) Milimetric: ""table" is a reserved word in sql :)" [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:40:48] (CR) Milimetric: [C: 2 V: 2] ""table" is a reserved word in sql :)" [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:41:07] (PS1) Joal: Upgrade refinery-camus and refinery-job to 0.0.21 [analytics/refinery] - https://gerrit.wikimedia.org/r/249180 [17:41:19] (PS4) Jdlrobson: Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) [17:42:49] (CR) Milimetric: [C: -2] "you can't remove columns, the report will break. If you'd like to remove, coordinate with us and we can remove the column from the existi" [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/247045 (https://phabricator.wikimedia.org/T98701) (owner: Florianschmidtwelzow) [17:43:28] (CR) Milimetric: [C: 2 V: 2] Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:43:44] ok jdlrobson that looks fine, but the change it depends on will break the page-ui-daily report if submitted [17:43:53] it will? [17:44:00] you can't remove columns or else the report won't know how to merge the new changes with the old TSV [17:44:01] it depends on a change? whoops [17:44:03] doesn't need one [17:44:10] yeah, shouldn't depend I think [17:44:21] just a bad gerrit link - but feel free to self-merge when you untangle [17:44:45] (PS5) Jdlrobson: Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) [17:44:54] and for the other one - either don't remove the column (re-ordering is fine) or let us know if you need to remove it. We can do it, we've just been hesitant because remove + reorder is hard to handle automatically [17:44:54] (CR) Jdlrobson: [C: 2] Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:45:04] (CR) Jdlrobson: [V: 2] Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:45:12] yeh that was accidental :) [17:45:16] thanks milimetric ! [17:45:19] np [17:46:46] (Merged) jenkins-bot: Bump MobileOptions revision [analytics/limn-mobile-data] - https://gerrit.wikimedia.org/r/248990 (https://phabricator.wikimedia.org/T115129) (owner: Jdlrobson) [17:50:15] milimetric: can you remind me how i deploy? [17:56:03] nuria: do you know if there is anything specific to do while deploying a new avro schema in refinery ? [17:57:02] joal: update the version of the jar we are using in puppet, [17:57:12] jdlrobson: oh, sorry, no, this is deployed automatically, puppet just updates the sql and it gets picked up on the next run. It takes a while for everything to show up on the dashboard because cron / rsync [17:57:23] joal: let me see the camus cmd in puppet, give me a sec [17:57:31] sure nuria [17:58:14] nuria: I expect your command in puppet to use artifact/refinery-camus.jar (symlink with last version) [17:58:42] joal: likely, let's just verufy [17:58:45] *verify [18:02:12] joal: yes, the last jar is used, see: [18:02:15] https://www.irccloud.com/pastebin/kdqmGLem/ [18:02:42] refinery-camus.jar [18:02:45] ok nuria, so it should autmatuically pick up the last one [18:02:56] Is it ok for me to deploy that ? [18:03:02] joal: yes, cause refinery-camus is where the avro schema would be [18:03:22] joal: yes, i do not think we have incoming events quite yet [18:03:31] yes nuria, I just don't know how to double ckeck if the deployment has worked or not for instance [18:03:32] joal: even if we did it will be ok [18:03:39] Ok great :) [18:03:59] I let you CR https://gerrit.wikimedia.org/r/#/c/249180/, and deploy :) [18:06:10] ottomata: could you please deploy AQS as well? [18:06:11] https://wikitech.wikimedia.org/wiki/Analytics/Cluster/AQS#Deploying [18:06:33] milimetric: ottomata is currently lightning talking :) [18:06:37] oh shit [18:06:39] i missed that [18:06:41] huhuhu [18:07:00] sorry!!!! [18:07:09] I'm such an *** [18:19:15] (CR) Ottomata: [C: 2 V: 2] Upgrade refinery-camus and refinery-job to 0.0.21 [analytics/refinery] - https://gerrit.wikimedia.org/r/249180 (owner: Joal) [18:19:37] Analytics-EventLogging, Editing-Department, Improving access, QuickSurveys, and 3 others: Schema changes - https://phabricator.wikimedia.org/T114164#1758656 (csteipp) If we're logging the "username" (which is the IP address for logged-out users currently), then I'm fine with that! Then if there's... [18:21:57] (CR) Joal: [C: 2 V: 2] Add oozie job to compute browser usage reports [analytics/refinery] - https://gerrit.wikimedia.org/r/246851 (https://phabricator.wikimedia.org/T88504) (owner: Mforns) [18:24:37] !log deploying refinery [18:24:39] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [18:24:58] Analytics, Discovery, EventBus, MediaWiki-General-or-Unknown, and 6 others: Define edit related events for change propagation - https://phabricator.wikimedia.org/T116247#1758730 (mobrovac) [18:25:03] Analytics, Discovery, EventBus, MediaWiki-General-or-Unknown, and 7 others: EventBus MVP - https://phabricator.wikimedia.org/T114443#1758728 (mobrovac) [18:26:17] milimetric: can deploy. [18:26:34] sorry for pinging you during your talk, I enjoyed the end of it :) [18:26:36] np [18:26:38] :) [18:29:43] ottomata: refinery deployed, can you merge the puppet patch for camus not to fail ? [18:30:45] argh, totally missed the talk! [18:31:40] mforns: job started ! [18:31:47] joal, woohoo! [18:31:50] mforns: on sunday 25th :) [18:32:10] ok [18:32:30] ottomata: thanks for the lightning talk, very helpful for understanding the background of this better. can the slides be uploaded to commons? [18:33:00] sure! [18:33:40] HaeB: is it best to export PDF and upload? [18:33:49] yes [18:33:57] Analytics, Analytics-Cluster, Fundraising Tech Backlog, Fundraising-Backlog, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1758782 (awight) We do want landingpages.tsv.log, it's processed and statistics about the landing page impressi... [18:34:21] ottomata: cf. https://www.mediawiki.org/wiki/File:Pageview_@_Wikimedia_(WMF_Analytics_lightning_talk,_June_2015).pdf [18:34:53] tears come to my eyes thinking of that browser report ... let me know when is all good to check it out joal [18:36:00] HaeB: https://commons.wikimedia.org/wiki/File:EventLogging_on_Kafka_-_Lightning_Talk.pdf [18:36:04] OH [18:36:10] oh ok [18:36:11] yeah [18:36:24] Analytics, Analytics-Cluster, Fundraising-Backlog, Unplanned-Sprint-Work, Fundraising Sprint Vengaboys: Landing page impression log parser should get sample rate from filenames - https://phabricator.wikimedia.org/T116800#1758791 (awight) NEW a:awight [18:36:38] cool [18:36:42] great! [18:37:19] nuria: it needs a week of data to compute, so for now it's not doint anything ... [18:37:38] Shall I go and restart it at the beginning of octboer (or even before) ? [18:38:20] nuria: --^ [18:38:22] FYI, a-team, I updated some eventlogging docs with the examples from my talk [18:38:23] https://wikitech.wikimedia.org/wiki/Analytics/EventLogging#Accessing_Data [18:38:34] Analytics, Analytics-Cluster, Fundraising-Backlog, Unplanned-Sprint-Work, Fundraising Sprint Vengaboys: Impression log parsers should get sample rate from filenames - https://phabricator.wikimedia.org/T116800#1758813 (awight) [18:38:57] ottomata: we should use your schema in the header of that page as well ! [18:39:03] joal: that would be awesome [18:39:14] nuria: I'll do that :) [18:39:17] mforns: --^ [18:39:17] header? [18:39:19] joal: like beginning of october will give us couple weeks [18:39:31] I'll do beginning of september :) [18:39:34] Just for fun ;-P [18:39:53] ottomata: on the side of the ToC [18:40:05] schema? [18:40:07] joal: sounds good, will reports be retrievable with hue? [18:40:29] example ottomata: https://wikitech.wikimedia.org/wiki/Analytics/Cluster/Hive [18:40:39] joal, cool thanks! [18:40:43] oh you mean the graphic? [18:40:56] hmmmm, files should be visible I think, but not in table the way it's currently done [18:41:03] ottomata: yessir ! [18:41:14] they are here [18:41:14] https://wikitech.wikimedia.org/wiki/Analytics/EventLogging/Architecture [18:41:14] The one with kafka ottomata (obviously) [18:41:19] well, that one [18:41:26] :) [18:42:04] but hm, ja one like yours would be cool on the front page, hmMm [18:42:04] cool [18:42:13] anyway, hm. been thikning...WHERE AM I GOING TO RUN BURROW?! [18:42:22] not many Jessie machines at my disposal [18:42:28] HMMmm [18:43:43] ottomata: managed to do it if you want [18:44:23] eh? [18:44:30] ottomata: pushing the change, please revert if not ok :) [18:44:37] joal: i only 80% know what you are talking about, but ok! :) [18:44:51] do it! [18:45:06] huhuhu --> https://wikitech.wikimedia.org/wiki/Analytics/EventLogging [18:45:10] ottomata: --^ [18:46:16] cool ok! [18:46:24] nice [18:46:38] ottomata: merged the puppet change for camus ? [18:46:49] oh, hey a-team, this looks out of date, ja? [18:46:50] https://wikitech.wikimedia.org/wiki/Analytics/EventLogging#Size_limitation [18:46:50] if not, python script will not do anything ... [18:46:52] mforns: ? [18:46:56] aye, ok joal, you deployed? [18:47:03] deployed ottomata ! [18:47:08] ottomata, looking [18:47:16] cool, and you tested running camus with --dry-run and check stuff? [18:47:44] yup, did that [18:48:11] either --dry-run for a python dry-run, or --check-dry-run for check dry-run :) [18:48:18] ottomata: --^ [18:48:28] ottomata, yes outdated [18:50:03] cool [18:52:29] yup ottomata: last camus run at 18:20 UTC :) [18:53:14] ottomata: currently monitoring for the next run [18:53:28] k cool [18:56:37] mforns: BUG ! [18:56:49] joal, arff [18:56:52] or really ? [18:56:56] hm, need to re-read :) [18:57:00] what happened [18:57:13] I wonder if you override data in that job [18:57:41] or if you create new each time [18:58:55] mforns: --^ [18:59:16] joal, it overrides the one that has the same name [18:59:31] ok, but every new report is a new folder [18:59:35] yes [18:59:38] ahh, feeling better :) [18:59:59] I don't know why, I for once thought that maybe you were using the same file and append at the end [19:00:20] ottomata: camus job started :) [19:00:34] ottomata: waiting 10 more minutes :) [19:03:26] :) [19:05:19] ottomata: did that deploy go ok? [19:06:05] oh, ah, you have to remidn me! i just did the check [19:06:12] check looks good. doing for real [19:06:32] !log deploying aqs [19:06:34] Logged the message at https://www.mediawiki.org/wiki/Analytics/Server_Admin_Log, Master [19:06:42] working better this time milimetric [19:08:04] nice ottomata: https://wikimedia.org/api/rest_v1/metrics/pageviews/per-article/en.wikipedia/all-access/all-agents/Godzilla/daily/2015101400/2015101400 [19:08:12] milimetric: all is well. [19:08:33] milimetric: You rock dude :) [19:08:35] thx much, so that's one problem solved [19:09:28] ottomata: now I added you to https://gerrit.wikimedia.org/r/#/c/249207/ [19:09:46] if that looks good merge it and we'll have dumps/pageviews [19:09:58] then we can send Erik an email and that's another problem solved [19:10:11] Analytics-Backlog, Analytics-Kanban, MediaWiki-API, Research-and-Data: Add Application errors for Mediawiki API to x-analytics - https://phabricator.wikimedia.org/T116658#1758900 (Qgil) [19:10:22] It's problem-solving day for milimetric :) [19:10:32] now I'm going to eat some cake and relax, so my brain can stop hurting [19:10:35] :) [19:11:17] milimetric: looks good, i will merge [19:11:42] uhhh, why no can merge? [19:11:42] hm [19:11:48] oh i'm not logged in, weird [19:12:10] gerrit keeps you in for like 90 days or something [19:12:18] a lot better than ALL WIKIS! :) [19:13:04] joal, :] sorry for the lag (in the batcave looking at ES) [19:13:15] np mforns :) no bug in fact ! [19:13:23] mforns: ES works ? [19:13:23] joal, woohoo! :] [19:13:47] joal, what we tested, works, now we're trying to do time ranges [19:14:21] ok mforns [19:14:29] mforns: performance wise, seems correct ? [19:15:07] Analytics-Kanban, Analytics-Wikistats, Patch-For-Review: Feed Wikistats traffic reports with aggregated hive data {lama} [8 pts] - https://phabricator.wikimedia.org/T114379#1758960 (Milimetric) @ezachte, this has been done. The new dataset will be available at dumps.wikimedia.org/other/pageviews/ once... [19:15:42] Analytics-Backlog, Analytics-Kanban: Druid testing on labs to asses whether is a suitable Cassandra replacement. {slug} - https://phabricator.wikimedia.org/T116409#1758969 (Milimetric) p:Triage>High a:Milimetric [19:15:44] ottomata: hdfs dfs -ls /wmf/data/raw/webrequest/webrequest_mobile/hourly/2015/10/27/19 [19:15:47] :D [19:16:15] ottomata: one issue though: logging doesn't make it to the log file :( [19:16:27] oh [19:16:30] but except from that, works ! [19:16:39] looking [19:16:46] ottomata: I have the starting log, but not the core log [19:16:52] but awesooome! [19:16:53] hm [19:17:02] joal: it is different than before? [19:17:21] When running it by hand, I had the console log fine [19:17:34] I guess I'll add a logfile parameter? [19:17:47] hm ... maybe not actually [19:18:09] hm, no, the cron shoudl be redirect the stuff to the file [19:18:13] redirecting* [19:18:19] >> ${log_file} 2>&1 [19:18:31] Also, since the checker fails correctly (return value != 0), cron should send you an email if there is any issue [19:18:47] yeah ottomata, it's weird :( [19:19:21] But at least we have the IMPORTEd flag :) [19:19:26] yeah! [19:19:26] * joal is happy ! [19:19:54] I'll add the code for load job to launch correctly based on that tomorrow [19:20:14] if you have any idea on that logging stuff ottomata, I'm eager to know :) [19:21:28] ottomata: I use that to configure log4j in console mode: org.apache.log4j.BasicConfigurator.configure [19:22:09] joal, looking in 2 mins [19:22:20] ottomata: no rush :) [19:22:31] I'll be gone in minutes, so we'll talk about that tomorrow [19:22:58] milimetric: between restbase and pageviews in dumps, that makes a good achievement today, congrats :) [19:23:39] Ohhh ! [19:23:56] ottomata: f*cking dumb BUG in camus checker [19:24:03] I'll correct that tomorrow [19:24:28] madhuvishy: :) http://apt.wikimedia.org/wikimedia/pool/main/b/burrow/ [19:24:41] ok you see it joal? [19:24:46] the problem? [19:24:50] i don't have to look :D ? [19:24:53] ottomata: currently, the tool is flagging the currently importing partition (not current -1) [19:25:02] ahhhh OO [19:25:03] k [19:25:07] but that is not about output? [19:25:21] I'll correct that tomorrow morning, then redeploy (how bad) [19:25:33] nope ottomata [19:25:36] k [19:25:40] i'm going to do a manual run and see [19:25:55] more important than output actually ;) [19:27:20] mforns, nuria: hdfs dfs -text /wmf/data/archive/browser/general/desktop_and_mobile_web-2015-9-27/* [19:28:21] mforns, nuria : How sad, no linux above .5% :) [19:28:23] Analytics, Analytics-Cluster, Fundraising-Backlog, Unplanned-Sprint-Work, and 2 others: Impression log parsers should get sample rate from filenames - https://phabricator.wikimedia.org/T116800#1759039 (awight) Open>Resolved [19:28:24] Analytics, Analytics-Cluster, Fundraising Tech Backlog, Fundraising-Backlog, operations: Verify kafkatee use for fundraising logs on erbium - https://phabricator.wikimedia.org/T97676#1759040 (awight) [19:28:58] ok a-team, I'm off for tonight [19:29:07] nite jo [19:29:18] Thanks milimetric :) [19:29:25] See you all tomorrow ! [19:31:58] joal: i'm not sure what is missing from the camus logs, looks ok to me... [19:32:01] just from a glance [19:32:08] i gotta run too, eye exam time! laters! [19:38:30] bye joal [19:38:34] :] [19:49:42] Krinkle: yt? [19:49:52] o/ [19:50:08] not to throw you in an emotional rollercoaster but ... [19:50:20] Krinkle: we did the browser reports v 0.1 [19:50:32] Krinkle: available here: hdfs dfs -text /wmf/data/archive/browser/general/desktop_and_mobile_web-2015-9-27/ [19:50:34] nuria: Oh nice. I was just about to do a query actually. I need one today. [19:51:39] Krinkle: there are some things that need fixing, like dates are not padded, also percentages are ported with too high precision but it should be VERY useful [19:54:00] nuria: stat1002? [19:54:07] Krinkle: yes [19:54:16] I've never used hdfs before [19:54:31] Krinkle: let me send you a wikitech link [19:54:40] [error] text: Path is a directory [19:56:57] Krinkle: https://wikitech.wikimedia.org/wiki/Analytics/Cluster/FAQ [19:57:24] Krinkle: sorry, it has a '*' at teh end [19:57:26] *the [19:58:14] nuria: OK [19:58:25] nuria: What do the dashes mean? [19:58:27] Windows 7 - Chrome 45 10.882796197757541 [19:58:27] iOS 9 Mobile Safari 9 6.822354159334845 [20:04:30] nuria: So where would this data go from here? Things I'd like to know is browser usage (e.g. total % of Chrome, and version breakdown. os breakdown is not needed. Though a separate breakdown of just OS (without browser) could be interesting as well. [20:04:46] Is there a visualisation platform this could go into? [20:10:13] Krinkle: Ya, we need a better display of the info, but now we have the info, that is something. want to file a task for that? [20:10:32] Krinkle: for display that is [20:10:52] This is for 1 day, last month, unsampled, trimmed to some cut off? [20:11:27] And runs periodically? [20:11:32] Is the query saved somewhere? [20:11:56] Krinkle: ( i will document this) but no, it is a weekly report [20:13:32] In Grafana one can step over properties with wildcards and sum() them, so it'd be easy to e.g. browser.os=*.browser_family.version=*.count and it shows all counts by browser name. And trivially browser.os.*.* would show counts for OS etc. [20:14:12] What I'd like for my monthly report (weekly starting next week, performance team) is breakdown of browser names % and with versions. So we can spot trends over time. [20:15:12] Right now we have https://stats.wikimedia.org/SquidReportClients.htm which has this breakdown, but is bad for many other reasons (including the outdated ua parser) [20:16:06] Monthly would be enough, but weekly is even more awesome. It'd be nice to have it run over the full 7 days though to avoid bias towards a specific day. [20:17:11] There are existing reports for analytics, is the process for those automated to some extend? Or are they imported into the visualisation statically from time to time? [20:17:18] e.g. the visualeditor report card and such. [20:20:49] Krinkle: automated [20:21:13] we wrote a report runner that updates the static files and we rsync them to datasets.wikimedia.org [20:21:25] dashboards just read the static files from there [20:21:52] the report runner is clever, and documented here: https://wikitech.wikimedia.org/wiki/Analytics/Reportupdater [20:22:02] Just found https://phabricator.wikimedia.org/T88504 as well. Cool. [20:22:21] The dashes are os_version, but for Windows it's part of OS name or something. Hmm. O [20:22:22] K [20:22:29] That's ua-parser quirk [20:23:30] milimetric: Cool, they fetch cross-domain? [20:23:46] yep, CORS is configured on datasets. [20:24:21] What kind of dashboards do we have set up in that way. Limn? [20:24:35] limn and dashiki both [20:25:36] Limn seems limited in regard to aggregating (e.g. grouping by browser family), or does it have that feature? Looking into Dashiki now [20:25:48] Though we could do that ahead of time [20:26:36] Krinkle: yes, dashiki has specific layouts, so you're trying to find something for the browser breakdown? [20:26:38] limn is at reportcard.wmflabs and Dashiki vital-signs and edit-analysis.wmflabs? [20:26:44] Krinkle: yes [20:27:03] and in theory dashiki makes it super easy to just drop any visualization of any timeseries into a layout [20:27:08] Yeah, I'd like to be able to view browser usage and quickly see % breakdown by browser name (no os or version), and then jump into os usage, and breakdown into versions when needed. [20:27:19] so 1. come up with layout 2. use dashiki modules to build it 3. deploy (very easy) [20:27:46] So we have separate dashiki instances per layout, but they all have access to the same data? [20:27:47] Krinkle: if you find a good visualization using *literally* any viz tool, I can implement you a graph for that in dashiki [20:28:07] separate dashiki instances per layout / per config, so language and vital signs use dashiki in different ways, like this: [20:28:16] https://language-reportcard.wmflabs.org/ [20:28:31] and yea, the datasets.wikimedia data is accessible by all [20:28:38] Hm.. what consistutes a dashiki layout. [20:28:39] and the reportupdater can access anything stats1003 can [20:28:43] Is it arbitrary js/html? [20:28:49] I thought it was more abstract [20:29:16] yeah, more abstract, a layout has style but also a solution to an information architecture problem [20:29:33] for example, vital signs lets you look at any of the 850 projects without some horrible infinite scrolling [20:29:54] and edit-analysis lets you see compare two different data sources [20:30:25] so if you're (at a high level) comparing two different things, you can configure that same layout that edit-analysis uses to compare your things [20:30:32] Hm.. so I need only something basic (I'm sure everybody said that). Looking at the existing language and and vital signs layouts, I imagine it would have on the left the different metric names with the option to merge/unmerge breakdown for browser, browser-version, OS. So it either shows OS, or browser, or browser+browser-version [20:30:34] something like taht [20:30:45] if you've got something that you wanna see broken down by our projects, then vital-signs, but this sounds like something new [20:31:04] Krinkle: why don't you work with a designer to get mocks [20:31:15] Krinkle: of what you would like to see and we implement that [20:31:28] Krinkle: talking about visual stuff in irc is very hard [20:31:48] Krinkle: doesn't have to be very spec-ed out [20:31:48] It feelswrong/overengineered to design a new tool for it. I create like 10 new dashboards every day in grafana. [20:32:22] well, dashiki's optimized to do just this. it usually takes just a couple days to get a new layout [20:32:34] as long as we have some idea of what it looks like and what the breakdowns are [20:32:49] Krinkle: either way, the browser data is good for graphana [20:32:56] Krinkle: cause we care about counts [20:32:56] grafana's that fast because it uses a specific layout too - so you have to bend your data into it [20:33:11] Krinkle: so in that way it is a good fit [20:33:14] if you don't want to bend data, you have to do a little work [20:33:29] Krinkle: other types of data (comparations/cross-references) are not [20:34:01] Yeah, but in this case it's not time series (except for switching between weeks or months, the main charts I expect would be bar charts or pie charts) [20:34:02] Krinkle: do you care about this data over time? [20:34:16] :) [20:34:18] ok, so monthly [20:34:18] Krinkle: it is also time, i gurantee [20:34:38] Krinkle: in mobile you are going to want to look at adoption/death of browsers over time [20:34:59] Sure, but I don't need a line graph over time. It's nice to have, but no where near the first 90% of priorities. [20:35:09] Krinkle: so it is a timeseries for some kinds of information but not for all [20:35:19] I can easily compare two pie charts with different month' input [20:35:24] Krinkle: how about a tree map: http://bl.ocks.org/mbostock/4063582 [20:36:05] so you select the month and breakdown you wanna see, and it gives you a map like that [20:36:20] Krinkle: on my opinion http://gs.statcounter.com/ does good with a basic timeline [20:36:20] you can hover to get exact numbers and look at the whole viz to get an idea of proportion [20:36:22] That's essentially a bar chart, right? [20:36:30] milimetric: ^ [20:36:37] but with rectangles [20:36:40] yeah, in my opinion better because you get context [20:36:52] Does it have axis? [20:36:54] and i think a treemap is great for mobile [20:36:56] and better than a pie chart because the context surrounds [20:37:12] I don't see a context after staring at it [20:37:26] Anyway, I'm a bit frustrated I guess. [20:37:34] I'll think about it. [20:37:40] by context I mean, next to each box you see about 3 or 4 other boxes to understand what its size means in a physical intuitive way [20:37:52] How is that different from a pie chart [20:38:02] I'm sorry :( didn't mean to frustrate you [20:38:13] in a pie chart each slice only has 2 others next to it [20:38:16] I feel like what I need here is very mundane. [20:38:19] Krinkle: let us understand what is frustrating [20:38:29] Krinkle: you want to visualize the data, right? [20:38:38] it is mundane, and we can make a one-time TreeMap in about 5 minutes [20:38:46] and one that updates with new data in probably 10 [20:39:01] but we'd rather build infrastructure so other people can do breakdowns like this [20:39:09] and that'll take 2-3 hours instead of 10 minutes [20:39:12] which is worth it to us [20:39:17] Yes, I agree. [20:39:20] and a little planning and all that [20:39:20] Which is why I love grafana. [20:39:43] right, sorry to bother you with the infrasctructure considerations [20:39:51] if you prefer a pie graph though, that's 100% up to you [20:40:28] if you don't want to work with a designer, just let us know bar/pie/treemap/whatever and we'll build it so that it can be re-used [20:40:34] I don't have much cycles for this, and I'm sure there are other people who need the data as well that should have input. But it's not difficult or controversial. [20:41:56] Basically I'd like to be able to see a percentage breakdown for a given month of browser usage. Optionally fragmented by browser version. So e.g. it shows 10 bars or slices with like Chrome: 30% or 30 slices like Chrome 45: 12%. [20:41:56] Krinkle: right, agreed. So what would be most useful as next step? [20:42:02] fair enough, ok, so TreeMap, ability to select a few different breakdowns, and specify which week / month you want to look at [20:42:27] And for PMs I imagine they'll want to feed inputs for mobile and overall separately, but you already have that :) [20:42:41] I'm thinking pie chart or bar chart. [20:42:43] nuria: no worries, I'll do this in some volunteer time tonight, I'll have fun for once instead of all this data loading :) [20:42:54] I find TreeMap highly confusing, but maybe the demo is not a good example? [20:43:33] Krinkle: everyone serves a different purpose, for desktop there is not a huge number of browsers [20:43:39] maybe :) I'll play with it and see if it can be made more clear. If not, I'll use a pie or bar [20:44:01] I'm happy with anything, but for inspiration I imagine it has a selector to select mobile/overall and select month. And then it draws the charts with options to select os, browser, or browser+version [20:44:06] OK. Let's give it try :) [20:44:51] k [20:45:10] Krinkle: and report is run weekly OVER a week of data, of course, [20:45:19] Krinkle: not just 1 day of the week [20:45:42] Krinkle: we will wait a bit to announce reports on engineering once we know they are working well. [20:46:01] nuria: just to be sure, these results can be made public, right? [20:47:54] milimetric: yes, there is no longtail cc Krinkle [20:48:00] When I last worked on this Oliver recommended to exclude any browser/os/version values with < 10K hits in a month, but otherwise OK to publish. [20:48:13] Consolidated into "Other" [20:52:35] Krinkle: want to file a ticket for the next deliverable of teh report? [20:53:00] Krinkle: we focused on getting data and our second pass will be about a way to better consume it [20:53:15] milimetric: any idea why there are big gaps in http://mobile-reportcard.wmflabs.org/ 22-25th for main-menu-daily? [20:53:25] did we have an outage? [20:53:30] jdlrobson: yes, EL was not replicating [20:53:44] the data's there now, I think it'll catch up tonight [20:53:56] sweet! okay i'll check back later. Thanks for the super quick answer :) [20:54:10] if it's still there tomorrow, jdlrobson, let me know and I'll fix the file so it regenerates tomorrow [20:55:03] will do! thanks! [21:01:36] nuria: Should I add it to https://phabricator.wikimedia.org/T88504 ? [21:05:38] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1759407 (Krinkle) >>! @Milimetric wrote: > Aggregate User Agent information (@Krinkle). Very useful for making engineering decisions on features and performance work. Adding T88504 as blocker for this. [21:05:43] Analytics-Cluster, Analytics-Kanban, Easy, Patch-For-Review: PM sees reports on browsers (Weekly or Daily) [8 pts] - https://phabricator.wikimedia.org/T88504#1013502 (Krinkle) [21:05:44] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1759409 (Krinkle) [21:19:38] Krinkle: let's make another task, that one was about the data and we would prefer to have another about visualization [21:19:51] Krinkle: as data source will not change [21:19:56] OK [21:20:48] Krinkle: thank you. [22:11:42] just randomly curious, i see you are using jmxtrans in the kafka and cdh repositories. what do you think of it? is it useful, might we want to consider using this for the java services discovery runs (elasticsearch, blazegraph)? [22:14:43] Analytics-Cluster, Analytics-Kanban, Easy, Patch-For-Review: PM sees reports on browsers (Weekly or Daily) [8 pts] - https://phabricator.wikimedia.org/T88504#1759835 (Nuria) [22:14:44] Analytics-Kanban, Analytics-Wikistats: {lama} Wikistats 2.0 - https://phabricator.wikimedia.org/T107175#1759834 (Nuria) [22:31:57] 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] [22:33:17] RECOVERY - Difference between raw and validated EventLogging overall message rates on graphite1001 is OK: OK: Less than 25.00% above the threshold [20.0] [22:47:53] i saw in icinga one of the analytics servers was down, analytics1039 [22:48:06] i had to powercycle it. this was the output i saw on mgmt console https://phabricator.wikimedia.org/P2248 [22:48:12] after powercycling it's back as normal [22:48:38] just fyi, it looks ok again in monitoring [23:06:27] Analytics, MediaWiki-Authentication-and-authorization, Reading-Infrastructure-Team, MW-1.26-release, Patch-For-Review: Create dashboard to track key authentication metrics before, during and after AuthManager rollout - https://phabricator.wikimedia.org/T91701#1760120 (Legoktm) Is there anything... [23:49:48] Analytics, MediaWiki-Authentication-and-authorization, Reading-Infrastructure-Team, MW-1.26-release, Patch-For-Review: Create dashboard to track key authentication metrics before, during and after AuthManager rollout - https://phabricator.wikimedia.org/T91701#1760233 (Tgr) Open>Resolved