Fetching the latest programs, projects, and workspace data.

Description: Cortex Ruler queries ingester directly for rule evaluation. This is okay but if Cortex Ruler could query Query Frontend instead for rule evaluation, it can benefit from more features in the Query Frontend like vertical sharding. This also simplifies the Cortex ruler to not embed a querier and uses less resources. For this project, we would like to switch Cortex Ruler to query Query Frontend. You are expected to work with a microservice architecture and write unit tests and end to end tests to make sure the feature works correctly. Expected Outcome: Cortex Ruler talks to Query Frontend for rules evaluation.
Showing 5 of 6 projects. Click any project card for scope, mentors, and proposal studio.
- Description: In order to make sure Cortex doesn’t introduce performance regressions across releases and major changes, we would like to introduce an automated way to run some nightly macro/micro benchmarks for Cortex clusters. This project could potentially involve setting up Kubernetes clusters, Cortex components, and load generators. We’d love to keep track of performance metrics for each test run and visualize them through a UI. - Expected Outcome: An automated workflow that runs performance macro/micro benchmarks everyday or on demand and performance metrics can be visualized through a UI.
Cortex provides horizontally scalable, multi-tenant, long term storage for Prometheus metrics when used as a remote write destination, and a horizontally scalable, Prometheus-compatible query API.
Description: Cortex server has a simple authentication mechanism (X-Scope-OrgId) but users can’t use the multi tenancy features out of the box without complicated proxy configuration. It’s hard to support all the different authentication mechanisms used by different companies but plan to have a simple but opinionated auth-gateway that provides value out of the box. Expected Outcome: A new experimental cortex component called auth-gateway that validates tenants requests and proxies valid requests to distributors and query-frontend.
- Description: [Cortex](https://github.com/cortexproject/cortex) is a cloud-native Prometheus compatible monitoring system. It is made up of a set of microservices that can be composed into an architecture that fits multiple use cases. However, this level of flexibility can lead to complexity in the configuration file. One way to handle this complexity is first-class validation support for the config. This is where [Cue](https://cuelang.org/) comes in. Cue provides data validation as a language feature and has solid support for Go. We think enabling Cortex to be configured using Cue and creating a Cue specification for the Cortex configuration file and other file types specific to Cortex would be a good step forward in improving the usability of the project.
Description: For users who want to migrate from Prometheus to Cortex, currently it is supported via a tool called [Thanosconvert](https://cortexmetrics.io/docs/blocks-storage/migrate-storage-from-thanos-and-prometheus/#when-migrating-from-prometheus). However, having this feature as part of the tool is limited in some usecase like SaaS because users usually don’t have permissions to access their storage layer directly. It would be nice to extend this feature into an API so that users can import their Prometheus TSDB compatible blocks for easier migration. Expected Outcome: An API that imports Prometheus blocks into Cortex.