[15:14:35] herron: o/ [15:14:53] elukey: hey I was just looking at your patches [15:14:59] I have a generic question about the slo_definitions file, feel free to answer anytime [15:15:06] ah no no I didn't mean to push you sorry! [15:15:24] it was more about two questions that I have in mind [15:15:40] ah sure, yeah whats up? [15:16:16] 1) IIRC the time window for the SLO calculation is every quarter, meanwhile in the dashboards we have "last 90d". What is the correct procedure? Setting the right time interval every beginning of a new quarter? [15:16:51] like: first and last day of the quarter harcoded in the top-right time setting in grafana I mean [15:18:31] 2) related to the above, I may confuse the prom query meaning, but I see a lot of avg_over_time/increase/etc.. with [90d] of "range" [15:18:56] I took over from Tobias' work so I didn't put a lot of thoughts into it, but is it correct? (given 1) I mean) ? [15:24:24] re: 1) I'll defer to rzl for the current reporting approach but I think what is done is essentially what you describe but offset by -1 month [15:27:44] and re 2 yes that's what we're doing across the board, either in the query or baked into the recording rules [15:28:01] right - we evaluate them on calendar-quarters-offset-by-a-month, e.g. June 1 to August 31, so the dashboard only aligns with that only when the date picker is set to e.g. 2023-06-01 00:00:00 to 2023-08-31 23:59:59, which presently you have to just put in by hand [15:29:01] and, also right, the range should properly be 90d, 91d, or 92d depending on which quarter it is -- for the "official" SLO review at the end of the quarter I do tweak it to the correct length, but for the dashboards we had to pick one, which isn't ideal [15:29:20] my understanding is all of that will improve with Pyrra but I haven't actually synced with herron about that in a while :) [15:30:06] yes! we should, it got a bit of a setback with the cfssl thanos-fe issue but yeah would be good to talk about the path forward on it [15:30:56] elukey: does that help? sorry about the warts in the meantime but your understanding is right [15:33:04] rzl: yes definitely it helps! What I am trying to wrap my head on, at the moment, is how to use and review the SLO dashboards during the quarter [15:33:23] say that we are a month in, and I'd like to see how error budgets are doing etc... [15:34:04] IIUC, in theory, I can set the correct dates in the time window and see data coming in as the week passes, right? [15:34:43] (not 100% sure about the 90d range though, but with the correct time window it should pick end - 90d right?) [15:35:15] if I am asking weird non-sense question is because I am trying to dump my understanding and figure out what parts I am missing :) [15:35:43] no, 100% the right question [15:35:43] hi all i came accross this the other day and thught it might be intresting to the folks here https://github.com/ddosify/alaz [15:35:59] during the quarter, you should use the SLO quarter that's in progress -- so the end date will be in the future [15:36:59] right now, you'd set it to 2023-09-01 00:00:00 to 2023-11-31 23:59:59, so everything from the June-August period is no longer counted, and there's only a week's worth of data [15:46:03] rzl: ack, makes sense - just a question though - Sept IIRC is in Q1, so I'd have set 2023-07-01 -> 2023-09-31 [15:47:51] for SLOs we actually use different dates, offset earlier by a quarter! the brief reason is, when we have SLO excursions and need to do engineering work to fix it, we still have time to fit it into the next quarter's goals [15:48:15] ah right totally forgot about that [15:48:18] okok now it makes sense [15:48:37] my brain is a little entangled now :D [15:48:49] I'll review this again tomorrow with fresh eyes :) [15:48:53] thanks a lot for the info! [15:49:03] for sure, let me know if I can help :) [15:49:36] sounds good elukey cheers [15:49:37] um, I mean offset earlier by a *month, clearly