SLI
Service Level Indicator. A quantitative measure of some aspect of a service level, such as availability, latency, or throughput.
Detailed Explanation
SLIs are the measurements that feed SLOs. They are specific, measurable metrics that indicate how well a service is performing. Common SLIs: availability (percentage of successful requests), latency (response time distribution), throughput (requests per second), and error rate (percentage of failed requests).
SLIs should be: directly measurable, meaningful to users, and precise enough to detect degradation. For example, measuring availability as "percentage of requests returning 2xx" is better than "server is up" because it captures application-level failures.
Why It Matters
SLIs provide the data needed to evaluate SLO compliance. Without accurate SLIs, SLOs are meaningless and error budgets cannot be tracked.
Real-World Example
A team defines an SLI for availability: "Percentage of requests that return HTTP 2xx or 3xx." They measure this with Prometheus queries and track it against their 99.9% SLO.
When to Use
For every production service. Define SLIs for the aspects of service level that matter to users: availability, latency, throughput, and error rate.
Advantages
- Quantitative measurement of service quality
- Feeds SLOs and error budgets
- Enables data-driven decisions
- Detects degradation before users notice
- Provides baseline for capacity planning
Disadvantages
- Requires accurate measurement infrastructure
- Choosing wrong SLIs can mislead
- Measurement overhead
- Distributed tracing adds complexity
- SLI definition requires understanding user needs
Related Terms
Frequently Asked Questions
What are common SLIs?
Availability: percentage of successful requests. Latency: percentage of requests under a time threshold (e.g., p99 under 200ms). Throughput: requests per second. Error rate: percentage of failed requests.
How do I measure SLIs?
Use monitoring tools: Prometheus (query metrics), Datadog (built-in SLI tracking), or custom instrumentation. Measure at the service level, not infrastructure level (e.g., HTTP response time, not CPU usage).
What is the difference between SLI and SLA?
SLI is what you measure (actual performance). SLA is what you promise customers (contractual commitment). SLIs feed SLOs (internal targets), which inform SLAs (external commitments).
How many SLIs should I have?
Start with 3-5 per service: availability, latency, error rate, and throughput. Add domain-specific SLIs as needed. Too many SLIs create noise; too few miss important signals.
Should SLIs measure infrastructure or application?
Application-level SLIs are more meaningful (HTTP response time, error rate). Infrastructure SLIs (CPU, memory) are useful for debugging but should not be SLOs. Users care about application behavior, not infrastructure metrics.