Calendar-based periods

[metalmatze]

Hijacking the thread since I work with Keith on Pyrra :)

@metalmatze Hi! I wanted to get your thoughts about our use case (Wikimedia), and how/if Pyrra could support it. We have 3 months SLO windows corresponding to quarters, and we are oriented not to use rolling windows but fixed ones (so we pick the start and end day of each quarter, and we analyze the error budget etc..). We are currently hosting https://slo.wikimedia.org/, that everybody loves for its speed and clarity, but of course we cannot use it (since it is based on rolling windows) and we use the Pyrra Grafana dashboard template. Do you think that there is a way to add custom time windows for the time picker? I am thinking something simple that can be set in the Pyrra's config, and that gets displayed alongside of the current ones. For example, we could set in the config all the quarters' time windows and select them when visiting the Pyrra UI for a given SLO (the custom windows could have labels like "Q1" "Q2" etc.. for clarity). If it is something that you'd allow to be present, we'll contribute with a patch! I don't have anything ready but it doesn't seem impossible, lemme know your thoughts. Thanks a lot!

Originally posted by @elukey in #952

[metalmatze]

This touches on a fundamental design decision in Pyrra that's worth explaining.

Pyrra implements window-based SLOs (rolling windows) rather than calendar-based SLOs (fixed quarters/months) primarily due to Prometheus's architecture and limitations. Here's why:

Prometheus Limitations:

• Prometheus doesn't have native support for calendar boundaries or complex time arithmetic
• PromQL lacks functions to easily define "start of quarter" or "end of month" calculations
• Time-based queries in Prometheus work best with relative time ranges ([30d], [12w]) rather than absolute calendar periods

Technical Challenges with Calendar-Based SLOs:
While theoretically possible, implementing calendar-based SLOs with Prometheus would be quite complex:

1. Dynamic Query Generation: We'd need to dynamically calculate calendar boundaries and inject them into PromQL queries
2. Historical Data Alignment: Aligning historical data with calendar periods requires complex timestamp manipulation
3. Query Performance: More complex queries with absolute time ranges can impact performance
4. Maintenance Overhead: Calendar logic adds significant complexity to query generation and validation

Current Approach Benefits:
Rolling windows provide several advantages:

• Consistent query patterns that Prometheus handles efficiently
• Continuous monitoring without gaps between reporting periods
• Simpler alerting logic since the time window is always consistent
• Better alignment with Prometheus's time-series data model

That said, I understand the use case for fixed quarterly reporting!
A custom time picker with configurable periods (like your Q1/Q2 suggestion) could be a good middle ground - it would still use rolling windows under the hood but allow you to view specific calendar periods in the UI.

I would love to hear more about your specific requirements. This could help us prioritize future enhancements!

[elukey]

Thanks a lot for all the info! I didn't know in depth what were the limitations, indeed the design choices make a lot of sense now, really sad that this cannot be as easy as I hoped :)
About our use case - we have a 3-months SLO fixed window that is shifter earlier by a month compared to the Wikimedia Quarter, so when the SLO window is finished we have a month to plan the work for the next quarter (as part of completing the current one). At the moment the compromise that we have is the following:

• Pyrra configured via filesystem yaml files for every new SLO, so that all the recording rules etc.. are created for us.
• slo.wikimedia.org that points to the Pyrra UI
• The Grafana Pyrra template to easily set up calendar-based windows, and check the error budget from there.
  We are still experimenting with Pyrra, but people are already confused when they see both rolling and calendar window dashboards, so ideally in the medium to long term we'll have only one solution. The Pyrra UI is always something that people mention as a plus, they prefer it over Grafana :)

[elukey]

To keep archives happy - we decided to go for a mixture of calendar and rolling, see https://wikitech.wikimedia.org/wiki/SLO/Template_instructions/Dashboards_and_alerts for more info. Thanks a lot for the support!