Service Mesh (ASM), hizmet düzeyi hedeflerine (SLO) dayalı yerleşik izleme ve uyarı olanakları sunar. SLO izleme, uygulama hizmetleri arasındaki çağrı performansını — gecikme süresi ve hata oranı dahil — takip eder ve güvenilirlik düştüğünde uyarılar tetikler.
Temel kavramlar
Hizmet düzeyi göstergesi (SLI) Hizmet sağlığını ölçen nicel bir ölçümdür. Örneğin: başarılı yanıt döndüren isteklerin yüzdesi veya belirli bir gecikme süresi eşiği içinde karşılanan isteklerin yüzdesi.
Hizmet düzeyi hedefi (SLO) Belirli bir süre boyunca bir SLI için belirlenen hedef değer veya aralık. Bir SLO, bir veya daha fazla SLI'den oluşur ve uygulama geliştiricileri, platform operatörleri ile bakım ve işletim personelinin hizmet kalitesini ölçüp sürekli iyileştirmesine olanak tanıyan ortak bir güvenilirlik kıyas ölçütüdür.
Hata bütçesi SLO hedefinden türetilen, kabul edilebilir hata veya teknik borç miktarıdır. Şu şekilde hesaplanır: 100% - SLO target. %99,9'luk bir SLO, %0,1'lik bir hata bütçesi sağlar.
Tüketim oranı Hata bütçesinin ne hızla tüketildiğini gösterir. 1'e eşit bir tüketim oranı, hata bütçesinin uyumluluk dönemi sonunda tamamen tükeneceği anlamına gelir. Daha yüksek tüketim oranları, daha hızlı tükenmeye ve daha ciddi sorunlara işaret eder.
SLI türleri
ASM iki SLI türünü destekler:
| SLI türü | Ne ölçer? | Eklenti türü | Arıza koşulu |
|---|---|---|---|
| Hizmet kullanılabilirliği | Hizmet başarıyla yanıt verdi mi? | availability | HTTP durum kodu 429 veya 5XX'tir (5 ile başlayan herhangi bir kod) |
| Gecikme süresi | Hizmetin yanıt vermesi ne kadar sürdü? | latency | Yanıt süresi belirtilen maksimum gecikme süresini aşar |
Gerçekçi hedefler belirleyin
Birden fazla SLI içeren bir SLO, hizmet sağlığını tek başına kullanılan bir SLI'ye göre daha doğru tanımlar.
SLO örnekleri:
Ortalama saniye başına sorgu sayısı (QPS) > 100.000/s
İsteklerin %99'unun gecikme süresi < 500 ms
İsteklerin %99'u için dakika başına bant genişliği > 200 MB/s
Hedef belirlerken kullanıcıların gerçekten algıladığı unsurlara odaklanın. Kullanıcılarınız 200 ms ile 600 ms gecikme süresi arasında ayrım yapamıyorsa gecikme hedefini 600 ms olarak ayarlayın; daha sıkı bir hedef, kullanıcı deneyimini iyileştirmeden mühendislik çabasını boşa harcar.
Farklı hizmetler farklı hedefleri gerektirir. Örneğin:
| Kullanılabilirlik hedefi | Yıllık yaklaşık kesinti süresi | Tipik kullanım senaryosu |
|---|---|---|
| %99 | ~3 gün | Kritik olmayan hizmetler |
| %99,999 | ~5 dakika | Görev açısından kritik sistemler |
Uyumluluk dönemi
Uyumluluk dönemi, SLI'lerin SLO hedefine göre ölçüldüğü zaman penceresini tanımlar. Aynı hedef yüzdesi, uyumluluk dönemine bağlı olarak çok farklı anlamlar taşır:
1 günlük dönemde %99 kullanılabilirlik: Kesintisiz en fazla ~14 dakika kesinti süresi (24 saat x %1)
30 günlük dönemde %99 kullanılabilirlik: Kesintisiz en fazla ~7 saat kesinti süresi (30 gün x %1)
ASM, 7, 14, 28 ve 30 günlük uyumluluk dönemlerini destekler.
Hata bütçesi
Hata bütçesi, bir hizmetin SLO'sunu karşılamaya devam ederken tolere edebileceği güvenilirlik eksikliğini nicelendirir:
Error budget = 100% - SLO targetÖrnek hesaplama
| Parametre | Değer |
|---|---|
| SLI arıza tanımı | HTTP durum kodu 429 veya 5XX'tir |
| Uyumluluk dönemi | 30 gün |
| SLO hedefi | %99,9 |
| Hata bütçesi | %0,1 (%100 - %99,9) |
| 30 gündeki toplam istek sayısı | 10.000 |
| İzin verilen hatalı istek sayısı | 10 (10.000 x %0,1) |
Bu SLO'yu karşılamak için hizmetin 30 günlük pencerede en fazla 10 başarısız isteğe sahip olması gerekir.
Kararları yönlendirmek için hata bütçelerini kullanın
Hata bütçesi, uyumluluk dönemiyle aynı süreye sahip kayan bir pencere üzerinden güncellenir:
Hata bütçesi >= 0: Uyumluluk dönemi boyunca SLO karşılanır.
Hata bütçesi < 0: SLO ihlal edilir.
Değişiklikleri ne zaman dağıtacağınıza karar vermek için kalan hata bütçesini kullanın:
Bütçe neredeyse tükendi: Dağıtımları erteleyin. SLO ihlali riski yüksektir.
Uyumluluk dönemi sonunda bütçe yeterli: Güvenle dağıtım yapın. Yeni sürüm bazı hatalara neden olsa bile SLO'nun ihlal edilmesi olası değildir.
Tüketim oranı
Tüketim oranı, hata bütçesinin uyumluluk dönemine kıyasla ne hızda tüketildiğini ölçer. Mevcut hata oranının hata bütçesine oranıdır:
Burn rate = Error rate / (1 - SLO target)1'e eşit bir tüketim oranı, hata bütçesinin tam olarak uyumluluk dönemi sonunda tükeneceği anlamına gelir. 2'ye eşit bir tüketim oranı, bütçenin yarı zamanda biteceğini gösterir.
Tüketim oranı örnekleri (30 günlük uyumluluk dönemi)
| Tüketim oranı | Uyumluluk dönemi başına tüketilen bütçe | Bütçenin tükenme süresi |
|---|---|---|
| 1 | %100 | 30 gün |
| 2 | %200 | 15 gün |
| 60 | %6.000 | 12 saat |
Daha yüksek tüketim oranları daha ciddi arızalara işaret eder ve daha yüksek öncelikli uyarıları tetikler.
Uyarı kuralları
Uyarı kuralları, hata bütçesinin çok hızlı tüketilmesi durumunda sizi bilgilendirir; böylece bir SLO ihlali gerçekleşmeden önce müdahale edebilirsiniz.
ASM, çoklu pencere tüketim oranı uyarısı kullanır; bu yaklaşım, tespit için uzun bir pencereyi otomatik çözümleme için kısa bir pencereyle birleştirir. Bu yöntem hem ani artışları hem de yavaş gelişen sorunları yakalarken, kurtarma sonrası uyarıları hızla temizler.
Çoklu pencere uyarısı nasıl çalışır?
Her uyarı kuralı iki pencere tanımlar:
Uzun pencere: Tüketim oranının daha uzun bir süre boyunca eşiği aştığını tespit eder. Bu işlem uyarıyı tetikler.
Kısa pencere (uzun pencerenin 1/12'i): Yüksek hata oranının sürüp sürmediğini kontrol eder. Hata oranı kısa pencerede eşiğin altına düştüğünde uyarı otomatik olarak temizlenir.
Bu tasarım iki yaygın sorunu önler:
Hata bütçesini günler içinde tüketen kademeli artışı kaçırmak
Arıza çözüldükten çok sonra bile uyarıları aktif tutmak
Uyarı önem düzeyleri (30 günlük SLO örneği)
| Önem düzeyi | Koşul | Tüketim oranı | Müdahale |
|---|---|---|---|
| Sayfalama düzeyi | 1 saatte hata bütçesinin %2'si tüketildi | 14,4x | Acil eylem gerekli |
| Sayfalama düzeyi | 6 saatte hata bütçesinin %5'i tüketildi | 6x | Acil eylem gerekli |
| Destek bileti düzeyi | 1 günde hata bütçesinin %10'u tüketildi | 3x | Destek bileti ile takip edin |
| Destek bileti düzeyi | 3 günde hata bütçesinin %10'u tüketildi | 1x (eşik) | Destek bileti ile takip edin |
Pratikte kısa pencere
Hata oranının 3 gün boyunca eşiğin iki katında kaldığını ve arızanın 3. günde giderildiğini varsayalım:
Kısa pencere ile: Kısa pencere kurtarmayı tespit ettiği için uyarı, onarımdan yaklaşık 6 saat sonra temizlenir.
Kısa pencere olmadan: Arıza artık mevcut olmasa bile uyarı 3 gün daha devam eder.