Etcd’ye Giriş ve Temel Kavramlar
Etcd, dağıtık sistemler için özel olarak tasarlanmış, yüksek erişilebilirlik sunan ve tutarlı bir anahtar-değer deposudur. Kubernetes ekosisteminin temel taşı olan bu teknoloji, kümenin mevcut durumu hakkındaki tüm kritik verileri güvenilir bir şekilde saklar.
Etcd Nedir?
Etcd, en basit tanımıyla, yapılandırma bilgilerini, durum verilerini ve metadata’yı depolamak için kullanılan açık kaynaklı bir dağıtık anahtar-değer (key-value) deposudur. “Distributed etc directory” (dağıtık vb. dizini) konseptinden esinlenerek adlandırılmıştır. Verileri basit bir hiyerarşik dosya sistemi gibi düzenler; her veri parçası, benzersiz bir “anahtar” ile ilişkilendirilen bir “değer” olarak saklanır.
Dağıtık Bir Anahtar-Değer Deposu Olarak Etcd
Etcd’nin “dağıtık” olması, tek bir sunucu yerine birden çok sunucudan oluşan bir küme (cluster) üzerinde çalıştığı anlamına gelir. Bu mimari, tek bir noktanın arızalanmasına karşı sistemi dayanıklı hale getirir. Veriler, kümedeki tüm üyelere çoğaltılır ve bu sayede herhangi bir sunucu çökse bile veri kaybı yaşanmaz ve sistem çalışmaya devam eder. Bu yapı, yüksek erişilebilirlik (high availability) için zorunludur.
Etcd’nin Geliştirilme Amacı ve Tarihçesi
Etcd, başlangıçta CoreOS ekibi tarafından, konteyner tabanlı işletim sistemi olan CoreOS’un ihtiyaçları için geliştirilmiştir. Amaç, dağıtık sistemlerin paylaşılan yapılandırma ve servis keşfi gibi temel sorunlarına güvenilir ve basit bir çözüm sunmaktı. Güçlü tutarlılık garantileri ve basit API’si sayesinde kısa sürede popülerlik kazandı ve Google tarafından Kubernetes’in birincil veri deposu olarak benimsendi. Bugün, Cloud Native Computing Foundation (CNCF) altında mezun olmuş bir projedir.
Kubernetes Mimarisi İçinde Etcd’nin Kritik Rolü
Etcd, Kubernetes kontrol düzleminin (control plane) vazgeçilmez bir parçasıdır. Kümenin tüm yapılandırma verilerini ve durumunu depolayarak, sistemin “tek doğruluk kaynağı” olarak hizmet eder. Bu rolü, Kubernetes’in tutarlı ve güvenilir bir şekilde çalışmasını sağlar.
Kubernetes Kontrol Düzleminin (Control Plane) Veri Deposu
Kubernetes kontrol düzlemi, kümenin beyni gibi çalışan bir dizi bileşenden (kube-apiserver, kube-scheduler, kube-controller-manager) oluşur. Bu bileşenlerin hepsi, görevlerini yerine getirmek için ihtiyaç duydukları tüm bilgileri etcd’den alır ve yaptıkları değişiklikleri yine etcd’ye yazar. Etcd, bu bileşenler arasındaki koordinasyonu sağlayan merkezi veri tabanıdır.
Kümenin “Tek Doğruluk Kaynağı” (Single Source of Truth) Olarak İşlevi
Bir Kubernetes kümesinde, “istenilen durum” (desired state) ve “mevcut durum” (current state) olmak üzere iki temel durum kavramı vardır. Kullanıcılar, `kubectl` gibi araçlarla istedikleri durumu (örneğin, “üç adet Nginx pod’u çalışsın”) API sunucusuna bildirir. Bu bilgi etcd’ye yazılır. Kontrol düzlemi bileşenleri, etcd’deki bu “istenilen durumu” sürekli olarak izler ve kümenin “mevcut durumunu” bu hedefe ulaştırmak için gerekli işlemleri yapar. Etcd, bu sürecin merkezinde yer alarak tüm sistem için tek ve güvenilir referans noktası olur.
Kubernetes Nesnelerinin (Objects) Etcd’de Saklanması
Kubernetes’te yönetilen her şey bir “nesne” olarak kabul edilir ve bu nesnelerin tamamı etcd içinde birer anahtar-değer çifti olarak saklanır.
Pod’lar, Servisler, Deployment’lar
Çalışan konteyner gruplarını temsil eden Pod’lar, uygulamalara ağ erişimi sağlayan Servisler ve uygulama dağıtımlarını yöneten Deployment’lar gibi temel Kubernetes nesnelerinin tüm tanımları, yapılandırmaları ve anlık durumları etcd’de tutulur.
ConfigMap’ler ve Secret’lar
Uygulama yapılandırma verilerini içeren ConfigMap’ler ve parolalar, API anahtarları gibi hassas bilgileri barındıran Secret’lar da etcd’de saklanır. Bu durum, etcd’nin güvenliğinin tüm kümenin güvenliği için ne kadar kritik olduğunu göstermektedir. Hassas verilerin korunması için simetrik şifreleme gibi yöntemlerle etcd’deki verilerin şifrelenmesi (encryption at rest) önem taşır.
Küme Konfigürasyonu ve Durumu (State)
Yukarıdakilere ek olarak, düğümlerin (node) durumu, roller, ağ yapılandırmaları ve diğer tüm küme genelindeki ayarlar da etcd’de saklanır. Kısacası, bir Kubernetes kümesi hakkındaki her şey etcd’de bulunur.
Kube-apiserver ve Etcd Arasındaki Doğrudan İlişki
Kubernetes mimarisinde etcd ile doğrudan iletişim kuran tek bileşen kube-apiserver’dır. Diğer tüm bileşenler (kubelet, scheduler, controller-manager) ve kullanıcılar (örneğin, kubectl komut satırı aracı aracılığıyla) API sunucusu üzerinden etcd’ye dolaylı olarak erişir. Bu tasarım, veri doğrulama, kimlik doğrulama ve yetkilendirme gibi işlemlerin merkezi bir noktadan yapılmasını sağlayarak kümenin güvenliğini ve tutarlılığını artırır.
Etcd’nin Temel Çalışma Prensipleri ve Mimarisi
Etcd’nin güvenilirliğini ve tutarlılığını sağlayan temel mekanizma, Raft konsensüs algoritmasıdır. Bu algoritma, dağıtık bir sistemdeki birden çok düğümün aynı durum üzerinde anlaşmasını sağlayarak veri bütünlüğünü garanti eder.
Raft Konsensüs Algoritması Nedir?
Raft, dağıtık sistemlerde fikir birliğine varmayı sağlayan bir protokoldür. Anlaşılabilirliği ve uygulanabilirliği kolay olacak şekilde tasarlanmıştır. Raft, etcd kümesindeki tüm düğümlerin (member) veri üzerinde hemfikir olmasını ve işlemlerin doğru sırada uygulanmasını sağlar.
Lider Seçimi (Leader Election)
Raft tabanlı bir kümede, herhangi bir anda yalnızca bir “lider” (leader) düğüm bulunur. Tüm yazma işlemleri ilk olarak lider tarafından alınır. Eğer lider ulaşılamaz hale gelirse, geri kalan düğümler (“takipçiler” veya followers) aralarından yeni bir lider seçmek için bir seçim süreci başlatır. Bu, sistemin kesintisiz çalışmasını sağlar.
Günlük Çoğaltma (Log Replication)
Lider, aldığı her yazma isteğini kendi işlem günlüğüne (log) bir girdi olarak ekler. Daha sonra bu günlüğü diğer takipçi düğümlere kopyalar. Bir işlemin güvenli bir şekilde kaydedildiğinden emin olmak için çoğaltma işlemi kritik öneme sahiptir.
Çoğunluk (Quorum) Mekanizması
Bir yazma işleminin “onaylanmış” (committed) kabul edilmesi için, liderin bu işlemi kümedeki üyelerin çoğunluğuna (quorum) başarıyla çoğaltması gerekir. Örneğin, 5 üyeli bir kümede çoğunluk 3’tür. Lider, işlemi kendisi dahil en az 3 üyeye yazdığında, bu değişiklik kalıcı hale gelir ve istemciye başarı onayı gönderilir. Bu mekanizma, az sayıda düğüm çökse bile veri kaybını önler.
Etcd Kümesi (Cluster) Yapısı
Etcd, yüksek erişilebilirlik sağlamak için her zaman bir küme olarak çalıştırılmalıdır. Bu küme, Raft algoritması tarafından yönetilen lider ve takipçi rollerinden oluşur.
Lider (Leader) ve Takipçi (Follower) Rolleri
Lider: Kümedeki tüm yazma isteklerini yönetir ve veri çoğaltmasını koordine eder. Takipçi: Liderden gelen günlük girdilerini kopyalar ve kendi yerel durumunu günceller. Okuma isteklerine hizmet edebilirler, ancak tüm yazma isteklerini lidere yönlendirirler.
Tek Sayıda Üye (Member) Bulundurmanın Önemi
Etcd kümelerinin her zaman tek sayıda (3, 5, 7 gibi) üyeye sahip olması şiddetle tavsiye edilir. Bunun nedeni çoğunluk (quorum) hesaplamasıdır. Örneğin, 3 üyeli bir küme 1 üyenin kaybını tolere edebilir (çoğunluk 2’dir). 4 üyeli bir küme de yine sadece 1 üyenin kaybını tolere edebilir (çoğunluk 3’tür). Bu durumda, 4. üye fazladan kaynak tüketmesine rağmen hata toleransını artırmaz. Bu nedenle tek sayılı küme boyutları, kaynak verimliliği ve hata toleransı arasında en iyi dengeyi sunar.
Veri Yazma ve Okuma Süreçleri
Bir yazma işlemi, istemciden lidere gönderilir. Lider, değişikliği günlüğüne ekler, takipçilere çoğaltır ve çoğunluk onayı aldığında işlemi onaylar. Okuma işlemleri ise varsayılan olarak liderden yapılır (en güncel veriyi garantilemek için), ancak daha esnek tutarlılık ayarlarıyla takipçilerden de yapılabilir.
Etcd’yi Kubernetes İçin İdeal Yapan Teknik Özellikler
Etcd, sadece dağıtık bir anahtar-değer deposu olmanın ötesinde, Kubernetes gibi karmaşık sistemlerin ihtiyaç duyduğu bir dizi kritik teknik özelliğe sahiptir. Bu özellikler, onu Kubernetes’in veri deposu rolü için mükemmel bir seçim haline getirir.
Tutarlılık (Consistency) ve Güvenilirlik
Raft konsensüs algoritması sayesinde etcd, güçlü tutarlılık garantileri sunar. Bu, bir veri yazıldıktan sonra, kümedeki tüm okuma işlemlerinin o verinin en güncel halini döndüreceği anlamına gelir. Kubernetes için bu, bir Pod oluşturulduğunda tüm kontrol düzlemi bileşenlerinin bu değişikliği anında ve doğru bir şekilde görmesi demektir.
Yüksek Erişilebilirlik (High Availability)
Etcd’nin dağıtık küme yapısı, donanım arızalarına veya ağ sorunlarına karşı doğal bir dayanıklılık sağlar. Üyelerden biri veya birkaçı (çoğunluk kaybedilmediği sürece) devre dışı kalsa bile, küme yeni bir lider seçerek çalışmaya devam eder. Bu, Kubernetes kontrol düzleminin kesintisiz hizmet vermesini sağlar.
Değişiklikleri İzleme (Watch) Yeteneği ve Kubernetes’teki Kullanımı
Etcd’nin en güçlü özelliklerinden biri, belirli anahtarlardaki veya dizinlerdeki değişiklikleri “izleme” (watch) yeteneğidir. Kubernetes bileşenleri bu özelliği yoğun olarak kullanır. Örneğin, kube-scheduler, yeni oluşturulan ve henüz bir düğüme atanmamış Pod’ları izler. Bir değişiklik tespit ettiğinde (yani yeni bir Pod oluşturulduğunda), hemen harekete geçerek o Pod’u uygun bir düğüme yerleştirir. Bu olay tabanlı mimari, Kubernetes’in reaktif ve verimli olmasını sağlar.
İşlem (Transaction) Desteği
Etcd, birden çok operasyonun tek bir atomik işlem içinde birleştirilmesine olanak tanır. “Compare-and-Swap” (CAS) gibi işlemler, bir anahtarın değerinin yalnızca beklenen değerle eşleşmesi durumunda güncellenmesini sağlar. Bu, birden çok bileşenin aynı anda aynı nesneyi değiştirmeye çalıştığı durumlarda yarış koşullarını (race conditions) önler ve veri bütünlüğünü korur.
Zaman Aşımı (Time-to-Live – TTL) Anahtarları
Etcd, anahtarlara bir yaşam süresi (TTL) atanmasına izin verir. Bu süre dolduğunda anahtar otomatik olarak silinir. Bu özellik, geçici durumları veya kilit mekanizmalarını yönetmek için kullanışlıdır. Örneğin, bir düğümün belirli aralıklarla kendi “sağlıklı” durumunu bildirmesi için kullanılabilir; eğer bildirim gelmezse TTL dolduğunda anahtar silinir ve Kubernetes o düğümün sorunlu olduğunu anlar.
Kubernetes’te Etcd Kurulum Topolojileri
Bir Kubernetes kümesi kurarken, etcd’nin nasıl dağıtılacağına dair iki temel mimari yaklaşım vardır: Yığılmış (Stacked) ve Harici (External). Her birinin kendine özgü avantajları ve dezavantajları bulunur ve seçim, kümenin boyutu, yönetim kolaylığı ve esneklik gereksinimlerine bağlıdır.
Yığılmış Etcd (Stacked/Colocated Etcd) Mimarisi
Bu topolojide, etcd üyeleri doğrudan Kubernetes kontrol düzlemi bileşenlerinin (kube-apiserver, kube-scheduler vb.) çalıştığı master düğümleri üzerinde çalışır. Yani, her master düğümü hem bir kontrol düzlemi bileşenine hem de bir etcd üyesine ev sahipliği yapar.
Avantajları ve Dezavantajları
Avantajları: Kurulumu ve yönetimi daha basittir çünkü daha az sunucu gerektirir. Kontrol düzlemi ve veri deposu tek bir birim olarak yönetilebilir, bu da yedekleme ve geri yükleme işlemlerini kolaylaştırır. Dezavantajları: Kontrol düzlemi bileşenleri ile etcd arasında kaynak çekişmesi yaşanabilir (CPU, RAM, I/O). Bir master düğümünün kaybedilmesi, hem bir kontrol düzlemi üyesinin hem de bir etcd üyesinin aynı anda kaybedilmesi anlamına gelir, bu da hata toleransını azaltır.
Harici Etcd (External Etcd) Mimarisi
Bu yaklaşımda, etcd kümesi, kontrol düzleminin çalıştığı master düğümlerinden tamamen ayrı, kendi adanmış sunucuları üzerinde çalışır. Kontrol düzlemi düğümleri, etcd’ye ağ üzerinden bağlanır.
Avantajları ve Dezavantajları
Avantajları: Veri katmanı (etcd) ile yönetim katmanı (kontrol düzlemi) birbirinden ayrılmıştır. Bu, daha iyi performans ve kararlılık sağlar çünkü kaynak çekişmesi yoktur. İki katman bağımsız olarak ölçeklendirilebilir. Örneğin, kontrol düzlemini etkilemeden etcd kümesine daha güçlü sunucular ekleyebilirsiniz. Dezavantajları: Daha fazla sunucu gerektirdiği için kurulumu ve yönetimi daha karmaşıktır. Ağ yapılandırması ve güvenliğin sağlanması ek bir çaba gerektirir.
Hangi Topolojinin Ne Zaman Seçilmesi Gerektiği
Yığılmış Etcd: Genellikle daha küçük, daha az kritik veya kaynakların sınırlı olduğu ortamlar için iyi bir başlangıç noktasıdır. Kurulumu kolaylaştıran `kubeadm` gibi araçlar varsayılan olarak bu topolojiyi kullanır. Harici Etcd: Büyük ölçekli, yüksek performans gerektiren ve yüksek erişilebilirliğin kritik olduğu üretim ortamları için en iyi pratiktir. Küme üzerinde tam kontrol ve esneklik istendiğinde tercih edilir.
Etcd Yönetimi ve Operasyonları
Etcd, Kubernetes kümesinin kalbidir ve sağlığının, güvenliğinin ve performansının sürekli olarak yönetilmesi gerekir. Bu, özel komut satırı araçları, izleme ve güvenlik en iyi uygulamalarını içerir.
`etcdctl` Komut Satırı Aracı ve Kullanımı
`etcdctl`, etcd kümesiyle doğrudan etkileşim kurmak için kullanılan birincil komut satırı aracıdır. Kümenin sağlığını kontrol etmek, anlık görüntüler (snapshot) alarak yedekleme yapmak, üyeleri listelemek ve doğrudan anahtar-değer verilerini sorgulamak gibi bakım ve sorun giderme görevleri için vazgeçilmezdir. Örneğin, `etcdctl member list` komutu kümedeki tüm üyeleri ve durumlarını gösterir.
Etcd Küme Sağlığının İzlenmesi
Etcd kümesinin sağlığını proaktif olarak izlemek, olası sorunları felakete dönüşmeden önce tespit etmek için kritiktir. Prometheus gibi izleme araçları, etcd tarafından sunulan metrikleri toplayarak kümenin durumu hakkında değerli bilgiler sağlar. Lider değişiklikleri, disk senkronizasyon süreleri ve ağ gecikmesi gibi metrikler yakından takip edilmelidir.
Etcd Güvenliğinin Sağlanması
Etcd, kümenin tüm sırlarını ve yapılandırmasını içerdiğinden, güvenliği en üst düzeyde olmalıdır. Bu, iletişimin her katmanında şifreleme ve kimlik doğrulama ile sağlanır.
TLS ile İstemci-Sunucu Şifrelemesi
kube-apiserver (istemci) ile etcd kümesi (sunucu) arasındaki tüm iletişim, TLS (Transport Layer Security) kullanılarak şifrelenmelidir. Bu, ağ üzerinden geçen verilerin dinlenmesini ve değiştirilmesini önler.
TLS ile Eşler Arası (Peer-to-Peer) Şifreleme
Etcd kümesindeki üyelerin kendi aralarındaki (eşler arası) iletişim de (örneğin, veri çoğaltma sırasında) TLS ile şifrelenmelidir. Bu, küme içindeki trafiğin de güvenli olmasını sağlar. Güçlü şifreleme algoritmaları, örneğin asimetrik şifreleme tabanlı sertifikalarla bu güvenlik katmanı oluşturulur.
Kimlik Doğrulama ve Yetkilendirme
Etcd’ye erişimin yalnızca yetkili istemcilerle (öncelikle kube-apiserver) sınırlandırılması gerekir. Bu, istemci sertifikaları kullanılarak karşılıklı TLS (mTLS) kimlik doğrulaması ile yapılır. Etcd ayrıca, belirli kullanıcılara veya rollere belirli anahtar aralıkları için okuma/yazma izinleri veren rol tabanlı erişim kontrolü (RBAC) özelliklerini de destekler.
Yedekleme, Geri Yükleme ve Felaket Kurtarma
Etcd verilerinin kaybedilmesi, tüm Kubernetes kümesinin durumunun kaybedilmesi anlamına gelir. Bu nedenle, düzenli yedekleme ve test edilmiş bir geri yükleme planına sahip olmak, her türlü üretim ortamı için mutlak bir zorunluluktur.
Etcd Yedeklemesinin Kritik Önemi
Etcd yedeği, Kubernetes kümenizin sigortasıdır. Donanım arızası, veri bozulması veya insan hatası gibi durumlarda kümenizi en son bilinen kararlı durumuna geri döndürmenizi sağlar. Yedekleme olmadan, kümenizi sıfırdan yeniden oluşturmanız gerekebilir, bu da ciddi bir kesinti ve veri kaybı anlamına gelir.
Anlık Görüntü (Snapshot) Yöntemi ile Yedekleme
Etcd’yi yedeklemenin standart ve en güvenilir yolu, `etcdctl snapshot save` komutunu kullanarak bir anlık görüntü (snapshot) oluşturmaktır. Bu komut, belirli bir andaki tüm anahtar-değer deposunun tek bir dosyaya tutarlı bir kopyasını alır. Bu yedekleme işlemi, canlı bir küme üzerinde çalışırken bile güvenle yapılabilir.
Yedekten Geri Yükleme (Restore) Prosedürleri
Bir felaket durumunda yedekten geri yükleme yapmak dikkatli bir prosedür gerektirir. Genel adımlar şunlardır:
- Mevcut etcd kümesini ve kube-apiserver’ı durdurun.
- `etcdctl snapshot restore` komutunu kullanarak yedek dosyasından yeni bir veri dizini oluşturun.
- Etcd servisini, bu yeni veri dizinini kullanacak şekilde yeniden yapılandırın.
- Etcd kümesini ve ardından kontrol düzlemi bileşenlerini yeniden başlatın.
Bu süreçte, RPO (Recovery Point Objective) ne kadar veri kaybını tolere edebileceğinizi, RTO (Recovery Time Objective) ise sistemin ne kadar sürede tekrar çalışır hale getirilmesi gerektiğini belirler.
Felaket Kurtarma Senaryoları
Felaket kurtarma planları, farklı senaryoları kapsamalıdır. Örneğin, küme üyelerinin çoğunluğunun kalıcı olarak kaybedilmesi durumunda, kalan üyelerle yeni bir küme oluşturmak yerine, en son sağlıklı anlık görüntüden tamamen yeni bir tek üyeli küme başlatmak ve daha sonra bu kümeye yeni üyeler eklemek genellikle daha güvenli ve hızlı bir yoldur.
Etcd Performans Optimizasyonu ve Sorun Giderme
Etcd’nin performansı, doğrudan Kubernetes kümesinin genel performansını ve kararlılığını etkiler. Yavaş etcd istekleri, API sunucusunda gecikmelere ve tüm kümede yavaşlamalara neden olabilir. Bu nedenle, performansı etkileyen faktörleri anlamak ve yaygın sorunları giderebilmek önemlidir.
Performansı Etkileyen Faktörler
Etcd’nin performansı temel olarak üç ana faktöre bağlıdır: disk hızı, ağ gecikmesi ve kümenin üzerindeki yük.
Disk G/Ç (I/O) Hızı
Etcd, her yazma işlemini diske kalıcı olarak kaydeder. Bu nedenle, disk yazma gecikmesine (latency) son derece duyarlıdır. Yavaş diskler (HDD’ler gibi), etcd’nin yavaşlamasına ve isteklerin zaman aşımına uğramasına neden olabilir. Bu yüzden, etcd veri dizini için her zaman düşük gecikmeli katı hal sürücüleri (SSD’ler), tercihen NVMe kullanılması şiddetle tavsiye edilir.
Ağ Gecikmesi (Network Latency)
Raft konsensüs algoritması, etcd üyeleri arasında sürekli bir iletişim gerektirir. Üyeler arasındaki ağ gecikmesinin yüksek olması, lider seçimlerinin daha uzun sürmesine ve hatta sık sık gereksiz lider değişikliklerine yol açabilir. İdeal olarak, etcd üyeleri aynı veri merkezinde ve birbirine yakın ağ anahtarları üzerinde konumlandırılmalıdır.
Küme Boyutu ve Kaynak Tüketimi
Kubernetes kümesindeki nesne sayısı (Pod’lar, ConfigMap’ler vb.) ve bu nesnelerin ne sıklıkla güncellendiği, etcd üzerindeki yükü doğrudan etkiler. Çok büyük veya çok aktif kümeler, etcd’nin daha fazla CPU ve bellek tüketmesine neden olabilir. Etcd üyelerine yeterli kaynakların ayrıldığından emin olunmalıdır.
Yaygın Karşılaşılan Sorunlar
Performans sorunları genellikle belirli semptomlarla kendini gösterir.
Yavaş İstekler ve Zaman Aşımları
Bu, genellikle disk G/Ç veya ağ gecikmesi sorunlarının bir belirtisidir. İzleme metriklerinde `wal_fsync_duration_seconds` (diske yazma süresi) ve `etcd_network_peer_round_trip_time_seconds` (üyeler arası gidiş-dönüş süresi) değerlerinin kontrol edilmesi sorunun kaynağını bulmaya yardımcı olabilir.
Sık Lider Değişimleri
Eğer kümede sürekli olarak liderin değiştiğini görüyorsanız, bu genellikle lider düğümün aşırı yüklendiğinin veya ağda bir istikrarsızlık olduğunun işaretidir. Lider, diğer üyelere zamanında “heartbeat” mesajları gönderemediğinde, takipçiler liderin çöktüğünü varsayar ve yeni bir seçim başlatır.
İzleme (Monitoring) için Temel Metrikler
Etcd’nin sağlığını ve performansını izlemek için takip edilmesi gereken bazı temel metrikler şunlardır:
- has_leader: Kümenin bir lideri olup olmadığını gösterir (1 olmalı, 0 olmamalı).
- leader_changes_seen_total: Lider seçimlerinin sayısını gösterir. Bu sayının hızla artması bir soruna işaret eder.
- wal_fsync_duration_seconds: İşlem günlüğünün diske yazılma süresidir. Yüksek değerler disk performansının zayıf olduğunu gösterir.
- grpc_server_handled_total: Etcd sunucusuna gelen isteklerin sayısını ve türünü gösterir. Bu, kümenin ne kadar meşgul olduğunu anlamak için kullanılır.
Bu metriklerin bir bulut işlem izleme platformu üzerinden düzenli olarak takip edilmesi, sorunları erkenden tespit etmenin en iyi yoludur.
