slo-exporter
aperture
slo-exporter | aperture | |
---|---|---|
1 | 28 | |
165 | 590 | |
0.0% | 1.0% | |
4.6 | 9.8 | |
13 days ago | 1 day ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
slo-exporter
-
SRE tools?
SLO exporter (https://github.com/seznam/slo-exporter)
aperture
-
Defcon: Meta's system for preventing overload with graceful feature degradation
Anyone interested in load shedding and graceful degradation with request prioritization should check out the Aperture OSS project.
https://github.com/fluxninja/aperture
-
Queues Don't Fix Overload
I agree that queues can problem especially when misconfigured. But some amount of queuing is necessary, to absorb short spikes in demand vs capacity. Also, queues can be helpful to re-order requests based on criticality which won't be possible with zero queue size - in which case we have to immediately drop a request or admit it without considering it's priority.
I think it is beneficial to re-think how we tune queues. Instead of setting a queue size, we should be tuning the max permissible latency in the queue which is what a request timeout actually is. That way, you stay within the acceptable response time SLA while keeping only the serve-able requests in the queue.
Aperture, an open-source load management platform took this approach. Each request specifies a timeout for which it is willing to stay in the queue. And weighted fair queuing scheduler then allocates the capacity (a request quota or max number of in-flight request) across requests based on the priority and tokens (request heaviness) of each request.
Read more about the WFQ scheduler in Aperture: https://docs.fluxninja.com/concepts/scheduler
Link to Aperture's GitHub: https://github.com/fluxninja/aperture
Would love to hear your thoughts on our approach!
-
Kelsey Hightower's Twitter Spaces on Rate Limits & Flow Control
For those keen to dive deeper, I highly recommend exploring both the Twitter Space and Aperture: [Twitter Spaces]: https://twitter.com/kelseyhightower/status/1689355284802629633?s=20 [GitHub repo]: https://github.com/fluxninja/aperture
-
Graceful Behavior at Capacity
Very interesting blog post! Our team has been working intensively in this area for the last couple of years - flow control, load shedding, controllability (PID control), and so on.
We have open-sourced our work at - https://github.com/fluxninja/aperture
We would love feedback from folks reading this blog post!
Disclaimer: I am one of the co-authors of the Aperture project. There are several interesting ideas we have built into this project and I will be happy to dive into the technical details as well.
-
Why Adaptive Rate Limiting Is a Game-Changer
It's a blog on an open-source project that precisely tells you how to implement adaptive rate limiting.
Just click around a bit:
- https://github.com/fluxninja/aperture
- https://docs.fluxninja.com/use-cases/adaptive-service-protec...
Note: I am one of the authors' of this project.
-
Show HN: Review GitHub PRs with AI/LLMs
At the time of writing, the first sample image on that page is this:
https://coderabbit.ai/assets/section-1-f9a48066.png
which recommends adding a "maxIterations" counter to the "for len(executedComponents) ..." loop here:
https://github.com/fluxninja/aperture/blob/26e00ea818c7c28da...
HOWEVER
- the review has failed to notice the logic using "numExecutedBefore" (around line 377) that already prevents the specific bug it is suggesting a fix for
- the suggested change decrements "maxIterations" inside the "for ... range circuit.components {" loop which means it isn't counting iterations, it's counting components
This kind of suggestion is particularly nasty because it's unlikely that the test suite populates enough components to hit "maxIterations" - so an inattentive reader could accept it, get a green build, and then deploy a production bug!
-
June 25th, 2023 Deno Deploy Postmortem
The need an adaptive protection system like Aperture[0] to mitigate overloads.
[0]: https://github.com/fluxninja/aperture
-
Jsonnet – The Data Templating Language
It’s customized to our policy spec. But you can learn from this and adapt it to your spec.
https://github.com/fluxninja/aperture/blob/main/scripts/json...
- Show HN: Aperture – Unified Reliability Management for Microservices
- Failure Mitigation for Microservices: An Intro to Aperture
What are some alternatives?
fixinventory - Fix Inventory consolidates user, resource, and configuration data from your cloud environments into a unified, graph-based asset inventory.
rules_jsonnet - Jsonnet rules for Bazel
awesome-sre-tools - A curated list of Site Reliability and Production Engineering Tools
slogen - tool to create and manage content for reliability tracking from logs/event data.
now-boltwall - Vercel lambda deployment for a Nodejs Lightning-powered Paywall
awesome-sre - A curated list of Site Reliability and Production Engineering resources.
ai-pr-reviewer - AI-based Pull Request Summarizer and Reviewer with Chat Capabilities.
sireus - Sireus - SRE Utility System - Decision System for tracking SRE and DevOps operational state and executing commands
etleneum - the centralized smart contract platform
prometheus - The Prometheus monitoring system and time series database.