Kafka

#Ne işe yarar

Kafka adımı bir topic'e kayıt produce eder ya da bir topic'ten kayıt consume eder. Produce adımı broker'ın onay (ack) süresini, consume adımı bir kaydı bekleme süresini ölçer. İki ek ölçüm, yükün pipeline'ınıza etkisini gösterir:

• Uçtan uca gecikme (kafka_e2e_latency): bir kaydın produce edilmesinden consume edilmesine kadar geçen süre.
• Consumer lag (kafka_consumer_lag): bir consumer group'un ne kadar geride kaldığı (kayıt sayısı). Kendi adımlarınızın group'unu ya da gerçek servisinizin group'unu izleyebilirsiniz.

#Ne zaman kullanılır

• Bir servisin Kafka'ya yazma kapasitesini (saniyede kaç kayıt, ack süresi) ölçmek için.
• Yük altında consumer servisinizin geride kalıp kalmadığını (lag) görmek için.
• Produce → consume arasındaki toplam gecikmeyi izlemek için.

#Bağlantı oluşturma

Kafka bağlantısı

1. Bağlantılar → Bağlantı ekle, Tür: Kafka.
2. Ad verin (ör. kafka-local).
3. Broker'lar (virgülle): en az bir broker, örneğin kafka-1:9092, kafka-2:9092. Zorunludur.
4. Client ID (isteğe bağlı, ör. spitfire): broker loglarında ve kotalarda görünür.
5. Acks: all (varsayılan, tüm replica'lar), leader ya da none. Produce süresi bu ayara göre ölçülür; production davranışınızla aynı değeri seçin.
6. Kimlik doğrulama gerekiyorsa SASL mekanizması (PLAIN, SCRAM-SHA-256, SCRAM-SHA-512), SASL kullanıcı ve SASL parola (secret) alanlarını doldurun.
7. Broker'lar TLS kullanıyorsa TLS bölümünü açıp TLS kullan'ı işaretleyin; özel CA için CA sertifikası ekleyin.
8. Kaydet ve Test et.

#Produce adımı

1. Adım ekle → Protokol: Kafka → Bağlantı: kafka-local.
2. Eylem: Üret (produce).
3. Topic adını yazın.
4. Anahtar (key; aynı anahtar aynı partition'a gider) ve Değer (value) yazın. İkisinde de {{değişken}} kullanılabilir.
5. Gerekirse Header'lar ekleyin.
6. Kayıtlara damga (spitfire-ts) ekle: uçtan uca gecikme için varsayılan olarak açıktır; her kayda spitfire-ts header'ı eklenir. Hedef sistem bilinmeyen header'ları kabul etmiyorsa kapatın ("noStamp": true). Aynı adla kendi koyduğunuz bir header'a dokunulmaz.
7. Gerçek servisinizin lag'ini izlemek için Diğer consumer group'ların lag'i alanına group adlarını virgülle yazın (ör. order-service; en çok 10).

Kafka produce ve consume adımları

#Consume adımı

1. Eylem: Tüket (consume).
2. Topic adını yazın.
3. Consumer group:
   • Boş bırakırsanız her VU topic'i en son kayıttan itibaren kendi başına okur.
   • Doldurursanız (ör. spitfire-load) VU'lar partition'ları paylaşır, gerçek bir consumer group gibi.
4. Bekleme süresi (varsayılan 10s): bu sürede kayıt gelmezse adım no record on <topic> within 10s hatasıyla başarısız olur.
5. Bu consumer group'un lag'ini izle: sabit bir consumer group verdiğinizde açılır ve varsayılan olarak işaretlidir ("noLag": true ile kapanır).

[
  {"id": "send", "name": "Sipariş gönder", "protocol": "kafka", "connection": "kafka-local",
   "kafka": {"action": "produce", "topic": "orders", "key": "{{__VU}}",
     "value": "{\"id\": \"{{$uuid}}\"}", "lagGroups": ["order-service"]}},
  {"id": "read", "name": "Siparişi oku", "protocol": "kafka", "connection": "kafka-local",
   "kafka": {"action": "consume", "topic": "orders", "groupId": "spitfire-load", "wait": "10s"}}
]

#Uçtan uca gecikme nasıl ölçülür

1. Produce adımı her kayda spitfire-ts header'ı ekler (<unix ns>;<kaynak>).
2. Bir consume adımı, aynı koşuda ve aynı runner'da damgalanmış bir kaydı okuduğunda gönderimden okumaya geçen süreyi kafka_e2e_latency olarak kaydeder.
3. Başka araçların, başka koşuların ya da başka runner'ların ürettiği kayıtlar normal consume edilir ama ölçülmez.

Neden aynı runner? Runner'ların saatleri, ölçülen gecikmeden daha fazla farklı olabilir. Spitfire iki makinenin saatini asla karşılaştırmaz; kaydı produce eden runner onu consume ettiğinde iki uç da aynı monoton saati okur. N runner'a yayılan bir koşuda kayıtların yaklaşık 1/N'i ölçülür; koşu ekranı bunu yazar: N runner: başka runner'da produce edilen kayıtlar ölçülmez; değerler trafiğin bir örneklemidir.

#Consumer lag nasıl ölçülür

• Lag = partition'ın end offset'i − group'un commit ettiği offset. Hiç commit olmayan partition'da tuttuğu bütün kayıtlar sayılır.
• Koşu başına tek bir runner (yükün ilk payını alan) Kafka admin API'siyle 2 saniyede bir sorgular.
• Sorgu salt okunurdur: offset'leri listeler; group'a asla katılmaz, commit etmez, offset sıfırlamaz.
• kafka_consumer_lag group başına toplamdır; kafka_consumer_lag_partition partition başına (group/partition etiketiyle; group başına en çok 64 partition serisi).
• Topic ve consumer group bir şablon ({{…}}) değil, sabit bir ad olmalıdır; şablonsa lag izlenmez ve editör uyarır.

Gerekli yetkiler: Bağlantının kullanıcısına topic üzerinde Describe (metadata, ListOffsets) ve izlenen her consumer group üzerinde Describe (OffsetFetch). Yetki yoksa koşu devam eder, bir uyarı yazılır; yalnızca lag raporlanmaz.

#Ürettiği metrikler ve eşikler

Koşu sayfasındaki Kafka kartı Uçtan uca gecikme (produce → consume) ve Consumer lag (kayıt) grafiklerini, group başına Bitişte ve En yüksek lag'i gösterir.

Eşik örnekleri:

[
  {"metric": "kafka_e2e_latency", "expr": "p(95)<500"},
  {"metric": "kafka_consumer_lag", "expr": "max<10000"},
  {"metric": "kafka_consumer_lag", "filter": {"check": "order-service"}, "expr": "value<100"}
]

max<10000: izlenen hiçbir group bundan fazla geride kalmadı. value<100: koşu bittiğinde kalan lag 100'den az. filter.check tek bir group'u seçer.

#Sık karşılaşılan sorunlar

Belirti: Test et başarısız, dial tcp …: connection refused ya da zaman aşımı. Neden: Broker adresi yanlış ya da broker'ın ilan ettiği adres (advertised.listeners) controller'dan çözülmüyor. Çözüm: Broker'ların ilan ettiği host adlarının controller ve runner'lardan çözülüp erişilebildiğini kontrol edin.

Belirti: SASL authentication failed. Neden: Mekanizma, kullanıcı ya da parola yanlış. Çözüm: SASL mekanizmasını broker'ın ayarıyla aynı yapın; parolayı yeniden yazıp kaydedin. SASL genellikle TLS ile birlikte kullanılır: TLS kullan'ı kontrol edin.

Belirti: TOPIC_AUTHORIZATION_FAILED ya da GROUP_AUTHORIZATION_FAILED. Neden: Kullanıcının topic'e yazma/okuma ya da group'a erişim yetkisi yok. Çözüm: Kafka ACL'lerinde gerekli Write/Read/Describe yetkilerini verin.

Belirti: Consume adımı sürekli no record on orders within 10s. Neden: Topic'e yeni kayıt gelmiyor; group'suz consume en son kayıttan başlar ve eski kayıtları okumaz. Çözüm: Aynı testte bir produce adımı ekleyin ya da topic'e yazan sistemi çalıştırın; Bekleme süresini artırın.

Belirti: Uçtan uca gecikme boş ya da çok az örnek. Neden: Produce ve consume farklı runner'larda, damga kapalı ya da kayıtları başka bir sistem üretiyor. Çözüm: Produce adımında damgayı açık tutun; produce ve consume adımlarını aynı senaryoya koyun. Çok runner'lı koşularda örneklemin küçüldüğünü unutmayın.

Belirti: Editörde consumer lag izlenmez: topic ya da consumer group bir şablon uyarısı. Neden: Topic ya da consumer group {{…}} içeriyor. Çözüm: Lag izlenecek adımlarda sabit ad kullanın.

Belirti: Koşu sürüyor ama lag grafiği yok; koşuda bir yetki uyarısı var. Neden: Bağlantının kullanıcısının topic ya da group üzerinde Describe yetkisi yok. Çözüm: Topic ve izlenen her group üzerinde Describe yetkisi verin.

#İlgili sayfalar

• Protokoller ve bağlantılar
• MQTT ve RabbitMQ
• gRPC