gRPC Monitor

gRPC servislerinizi standart gRPC Health Checking Protocol ile izleyin; servisler arası hataları dış HTTP kontrolleriyle aynı ciddiyetle yakalayın.

Pek çok mikro servis birbiriyle gRPC üzerinden konuşur. Sıradan bir uptime kontrolü bir gRPC servisinin sağlıklı olup olmadığını anlayamaz; servis bunu standart health RPC'si üzerinden kendisi bildirir (SERVING veya NOT_SERVING). gRPC monitör, platform readiness probe'larının kullandığı grpc.health.v1.Health/Check RPC çağrısını yapar.

Ne zaman kullanmalı?

  • Dahili API'ler: diğer servislerin gRPC üzerinden çağırdığı ödeme, kimlik doğrulama veya envanter servisleri.
  • Mobil ve web gateway'ler: uygulamalar genellikle çekirdek servislerin önündeki gRPC-Web gateway'e ulaşır.
  • ML serving: TensorFlow Serving, Triton ve çoğu inference sunucusu gRPC sağlık uç noktası açar.
  • İş ortaklarına sağlık yayını: bir müşteri gRPC ile entegre olduğunda dış uptime sayısı gerekir.

Kontrol nasıl çalışır?

Monitör, gRPC Health Checking Protocol v1'i uygular:

  1. Dial, host:port adresine gRPC bağlantısı açar.
  2. Call, grpc.health.v1.Health/Check'i boş servis adıyla çağırır.
  3. Evaluate, SERVING bekler. Başka bir cevap (NOT_SERVING, UNKNOWN, SERVICE_UNKNOWN) monitörü down yapar.
  4. Close, bağlantıyı kapatır.

Kontrol için .proto dosyalarınızı yüklemeniz gerekmez; health-check proto'su her gRPC implementasyonunda standarttır.

Monitör oluşturma

  1. Monitörler → Yeni Monitör.

  2. Tip olarak gRPC seçin.

  3. Alanları doldurun:

    • İsim: Örneğin PaymentService health
    • URL: Aşağıdakilerden biri:
      • host:port, düz metin
      • grpc://host:port, düz metin, açık şema
      • grpcs://host:port. TLS
    • Zaman aşımı: Varsayılan 10 sn.
    • Kontrol Sıklığı: Plana bağlı minimum aralık (güncel değerler için fiyatlandırma sayfasına bakın).

  4. Kaydet.

TLS ve düz metin

URL ön ekiBağlantı türüTipik kullanım
grpcs://payment.example.com:443TLS (genel güven deposu)Gerçek sertifikalı load balancer arkasındaki internete açık servisler.
grpc://payment.example.internal:9000Düz metinService mesh içi (Linkerd, Istio, Consul). Kontrol mesh içinden çalışmalıdır; internet üzerinden düz metin hiçbir zaman güvenli değildir.
payment.example.com:443 (şema yok)Düz metinEski kısaltma, grpc:// ile aynı. Açık şema tercih edilmelidir.

Dahili servislere ulaşmak

UptimeWarden varsayılan olarak yalnızca public hedeflere bağlanır. Cluster içi gRPC uç noktalarını izlemek için ortamınızda kendi agent'ınızı çalıştırın; özel ağ erişimi her agent için ayrı ayrı etkinleştirilebilir.

"SERVING" gerçekte ne anlama gelir?

SERVING'in neyi gerektirdiğine servisiniz karar verir. Çerçevelerin tipik varsayılanları:

  • Go: gRPC sunucusu açıldığı anda SERVING döner.
  • Java: aynı, HealthStatusManager üzerinden.
  • Node.js: aynı, yerleşik sağlık servisi üzerinden.

Bu bir liveness kontrolüdür, derin sağlık kontrolü değil. Veritabanı bağlantısı veya kuyruk sağlığını doğrulamak istiyorsanız sunucunuzda isimli sağlık servisleri kayıt edin. UptimeWarden'ın standart kontrolü boş servis adı gönderir; bu da genel sunucu sağlığına denk düşer.

Sık görülen hata mesajları

Hata mesajıOlası neden
gRPC connection failed: ...Servis dinlemiyor, port yanlış veya TLS uyumsuzluğu (düz metin istemci, TLS sunucu).
gRPC health check failed: ... code = UnimplementedSunucu standart sağlık proto'sunu uygulamamış. HealthStatusManager (Java), health.NewServer() (Go) veya eşdeğerini ekleyin.
gRPC service status: NOT_SERVINGServis proto'yu uygulamış ve bilerek "sağlıksız" raporluyor. Readiness mantığınıza bakın.
... certificate signed by unknown authoritygrpcs:// hedefi genel güven deposunda bulunmayan bir sertifika kullanıyor. Mesh içindeki bir agent'tan grpc:// ile bağlanın.

SLA ve bildirimler

  • Down: dial hatası, çağrı hatası veya NOT_SERVING.
  • Recovery: bir sonraki kontrol SERVING döner.
  • Multi-location consensus: desteklenir; çok bölgeli mesh'lerde özellikle değerlidir.
  • SLO takibi: desteklenir; her servis için bir availability SLO kurun.

Sık sorulan sorular

S: Sunucunun tamamı yerine belirli bir gRPC servisini (örneğin payment.orders) izleyebilir miyim? C: Standart kontrol genel sunucu sağlığı için boş servis adı gönderir. Çözüm: alt servisi ayrı bir gRPC sunucusu olarak açın ve onu ayrı izleyin.

S: Servisim bir proxy arkasında gRPC-Web kullanıyor. gRPC mi HTTP mi izlemeli? C: İkisinin de yeri var. gRPC monitör upstream servis hatalarını yakalar; gRPC-Web uç noktasına yönelik HTTP monitör proxy veya CORS sorunlarını yakalar. Paralel çalıştırın.

S: Kontrol "Unimplemented" diyor; sunucumun sağlık uç noktası var, sorun ne? C: Sunucu bir sağlık servisi uyguluyor ama grpc.health.v1.Health değil. Birçok ekip kendi yapısını yazıyor, standart proto'ya (grpc/health/v1/health.proto) geçin; beş satırlık bir iştir.

İlgili konular