Observability kavramı ve araçların gelişim süreci

• Observability kavramı:

  • Bir sistemin dış çıktılarının sonuçlarından (bilgi), sistemin iç durumunun ne kadar iyi çıkarımlanabildiğini gösteren ölçü
  • Çıktı değerlerinin ölçümünden sistem durumunun tahmin edilmesini sağlayacak şekilde tasarlanmış dinamik sistem
  • Bulut ortamları yaygınlaştıkça ve Docker tabanlı uygulamalar ile mikroservis mimarileri genel hale geldikçe Observability ihtiyacı ortaya çıktı

• Observability ile izleme arasındaki farklar:

  • İzleme: Kullanıcının yaptığı bir şeydir. Neyin yanlış olduğunu gösterir
  • Observability: İzlemeyi kapsayan daha üst bir kavramdır. İç çalışma hakkında zengin bağlam bilgisi sağlar ve derin sistem sorunlarını çözmeye yardımcı olur. Sadece neyin değil, ‘neden’ yanlış gittiğini de gösterir

• Kurumlarda Observability gereken durumlar:

  • Production’da bir sorun çıktığında, ‘Sorunun nedenini anlamaya yarayacak veri nedir, bu veri nerededir ve veriye nasıl bakılmalıdır?’ sorusu ortaya çıktığında
  • Bir dakika öncesine kadar sorunsuz çalışan bir hizmette problem oluştuğunda, ‘Kök nedeni nerede aramalıyım?’ sorusuyla karşılaşıldığında
  • Kurum içinde, ‘Geliştirme ekibi hizmetteki anormal belirtileri müşteri ya da destek/operasyon ekibinden önce nasıl fark edebilir?’ diye düşünüldüğünde
  • Mikroservislerdeki hizmet hatalarını ve performans sorunlarını etkili biçimde izlemek için hangi yöntemin kullanılacağı ya da ‘Bunu log veya uygulama performans izleme (APM) biçiminde görebilir miyiz?’ diye merak edildiğinde

• Observability araçlarının gelişim süreci:

  • 2010’lardan sonra BT sektöründe çeşitli Observability araçları ortaya çıktı
  • 2010’da Google, büyük ölçekli dağıtık sistem izleme altyapısı ‘Dapper’ı tanıttı
  • Ardından Uber ve Twitter, sırasıyla dağıtık izleme sistemleri ‘Jaeger’ (Uber) ve ‘Zipkin’i (Twitter) geliştirdi
  • Dağıtık sistemlerin çalışmasını sürekli modellemek ve açıklamak için standart API kümesi olan ‘Open Tracing’ ortaya çıktı
  • ‘Open Census’ yayımlandı: uygulama metrikleri ve dağıtık izleri toplayıp verileri gerçek zamanlı olarak backend’e aktaran, çeşitli diller için bir kütüphane seti
  • Sonrasında ‘Prometheus’ ortaya çıktı
  • 2019’da ise Open Tracing ile Open Census’u birleştiren araç, API ve SDK koleksiyonu ‘Open Telemetry (OTel)’ yayımlandı

• Open Telemetry:

  • Vendor bağımsız, açık kaynak bir Observability framework’ü
  • Yazılım performansını ve davranışını analiz etmeye yardımcı olan telemetri verileri arasında loglar, metrikler ve izler bulunur; Open Telemetry bunları enstrümante etmek, üretmek, toplamak ve dışa aktarmak için kullanılır
    • Loglar: Zaman damgalı metadata. Sorunun kök nedenini belirlemede kullanılır
    • Metrikler: Hizmette ölçülen key/value etiketli istatistik veya toplu veriler. Çalışma anında yakalanan hizmet ölçümleri
    • İzler: Kullanıcıda ve uygulamada meydana gelen olay kayıtları. Tekil request’in yayıldığı yolun kaydı
  • Kullanım şekli: Observability aracından uyarı gelir -> uyarı içeriği kontrol edilir ve dashboard’a gidilip sorunlu nokta bulunur -> bu noktada belirli bölümler ayrıntılı olarak sorgulanır -> loglar bulunup incelenir -> bu loglarla ilişkili iz verileri aranıp örüntü çıkarılır -> buradan sorun tespit edilip düzeltilerek Observability uygulanır
  • Günümüzde geliştirilen Observability araçlarının çoğu Open Telemetry’yi varsayılan olarak destekliyor

• Open Telemetry’nin ortaya çıkma nedeni:

  • Geçmişte her bir Observability backend’inin, verileri araca göndermek için kendine özgü enstrümantasyon kütüphaneleri ve ajanları vardı; kodu enstrümante etme yöntemleri de farklıydı
  • Observability backend’lerine veri göndermek için standartlaştırılmış bir veri biçimi yoktu
  • Daha sonra tek bir standart oluşturmak için Open Tracing ile Open Census birleştirildi ve Open Telemetry ortaya çıktı

• SigNoz: açık kaynak APM aracı

  • Uygulamaları izlemeye ve sorunları çözmeye yardımcı olur
  • Dağıtık izleme teknolojisini kullanarak kullanıcının yazılım stack’ini anlamayı sağlar
    • latency, requests per second, error rates gibi uygulama metriklerini izler
    • CPU kullanımı veya bellek tüketimi gibi altyapı metriklerini de gözlemler
    • Hizmet genelinde kullanıcı request’lerini izler
    • Metriklere uyarı tanımlanabilir
    • Soruna neden olan tam ize giderek problemin kök nedeni bulunabilir
    • Tekil request izlerinin ayrıntılı flame graph’ları da görülebilir

[ninebow]

Güzel yazı için teşekkürler!

[ironlung]

Yorumunuz için teşekkürler! :)

[kaistj]

Güzel yazı için teşekkürler~

[ironlung]

Yorumunuz için teşekkürler! :)

[jujumilk3]

İzlemenin düzgün çalışıp çalışmadığını nasıl izlersin?

Watchmen adlı çizgi romanda geçen bir sorgulamaya benzer bir şey düşünmüştüm; demek ki observability diye bir kavram varmış, teşekkürler.

[ironlung]

Teşekkürler! Bu aralar yapay zeka ile Observability’yi sadeleştiren araçlar geliştiren yerler de dikkat çekiyor. Daha fazla öğrenmek istediğim bir alan! :)

[inthelife]

Güzel yazı için teşekkürler :)

[ironlung]

Teşekkürler! :D