Jaeger Nedir? Jaeger Terminolojisi ve Bileşenleri | Distributed Tracing Nedir?
Merhabalar, bu yazımda Jaeger ürününden, terminolojisinden ve bileşenlerinden beraberinde ise Distributed Tracing kavramından bahsedeceğim.
Bunlara geçmeden önce ise OpenShift Cluster Monitoring konusuna değinmek istiyorum.
Kubernetes ekosisteminde neredeyse standart olmuş projeler yer almaktadır. Bu noktada Prometheus neredeyse bir standart. OpenShift de bu standartları kullanmakta.
Bu projeleri incelemek için CNCF Cloud Native Interactive Landscape, Cloud Native Computing Foundation (cncf.io) adreslerine göz atabilirsiniz. Burada Monitoring için Prometheus, Thanos ve Grafana, Tracing içinse Jaeger ve OpenTelemetry karşımıza çıkıyor.
Gelelim OpenShift Monitoring kısmına,
Openshift’ i kurduğumuz zaman beraberinde bir monitoring stack yapısı gelmekte. Uygulamaları, cluster’ ın kendi metriklerini, node’ların vs. default metriklerini alıp bir time series database de tutuyor. Prometheus burada metrikleri toplayan bir araç bunların dashboardlarını ise Grafana da görüntüleyebiliyoruz. Burada aynı zamanda alert/notification konfigürasyonlarını da yine Prometheus üzerinden yapabiliyoruz. Bir OpenShift Cluster’ ına sahipseniz halihazırda geldiğinden Cluster Monitor yapabiliyor olmalısınız.
Cluster Monitoring’ in varsayılan olarak OpenShift ortamınızda bulunduğundan bahsetmiştik. Aynı zamanda Horizontal Pod Autoscaling (HPA) için resource metrikleri ortaya çıkarmaktadır. Buradaki konfigürasyonları Config Maps ve Secrets aracılığıyla yapabiliyoruz. OpenShift UI, Prometheus ve Thanos’ a entegre olduğundan direkt metrikleri çekmekte böylece Cluster Monitoring kısmında Alerting, Metrics ve Dashboard kısımlarını görebilirisiniz.
OpenShift Container Platform’ da beraberinde gelen Monitoring için karşımıza aslında 2 level çıkıyor. Level 0; pod ayakta veya down, Level 1; CPU veya Memory kaynakları aynı zamanda diğer network metrikleri. Hiç bir işlem yapmasanız bile bu seviyede OpenShift metrikleri toplamakta.
OpenShift Cluster’ larda yer alan uygulamaların metriklerini monitör etmek istersek; uygulamanın bu metrikleri sağlaması gerekmekte. OpenShift, Cluster Monitoring’ in yanı sıra bir de User Workload Monitoring özelliği sunmaktadır. Bu da uygulama spesifik metrikleri toplayabiliriz demek 😉 Enable ettiğimiz takdirde uygulama özelinde konfigürasyonlar yapabiliyoruz.
Peki arka planda işler nasıl yürüyor?
OpenShift’in cluster-monitoring-operator’ü bir prometheus-operator oluşturuyor. Beraberinde Alertmanager’ ı kuruyor. cluster-monitoring-operator; Grafana, node-exporter vs gibi bir çok şeyi otomatik olarak oluşturuyor. Tüm bunlar openshift-monitoring namespace’i içinde çalışıyor.
Her bir worker node üzerinde node-exporter çalışıyor. Pod’ ların metrikleri (OpenShift’in tüm componentleri pod olarak yaşar) node-exporter’ a atılıyor. node-exporter bunu Prometheus’ atıyor. Grafana ile de biz tüm bu metrikleri izleyebiliyoruz.
OpenShift Distributed Tracing
Distributed tracing, dağıtık uygulamaları izlememize ve takibini yapmamıza olanak tanıyan bir çözüm aslında. OpenShift Distributed Tracing ise Jaeger’ ın RedHat tarafından desteklenen versiyonu şeklinde düşünebiliriz. Aynı zamanda Service Mesh’ in bir parçası olarak kullanılıyor. Ayrıca stand-alone proje mikroservisleri özelinde ilgili operatörün kurulmasıyla bir yapı sağlayabiliyoruz. Burada iki mod karşımıza çıkıyor. Eğer non-prod bir ortamdaysanız; her data için trace istemeyebilir ve all-in-one memory ile her şeyi memory de tutabilirsiniz. Ya da prod bir ortamdaysanız; arkada elasticsearch operatörünün bağlanmasıyla trace datasını elasticsearch üzerinde tutabilirsiniz.
Jaeger operatörü OpenShift’e kurulduktan sonra ilgili projelerin namespace’ inde jaeger instance’ ı yaratılabilir ve bu jaeger instance’ ı ile mikroservisler arasındaki mesajlaşmayı izleyebilirsiniz.
Jaeger Terminolojisi ve Bileşenleri
Jaeger tarafında her bir istek Trace olarak adlandırılmakta ve bir işlemin akışını baştan sona göstermektedir. Her trace birden fazla Span‘dan oluşabilir. Her Span içerisinde işlemin adını, başlangıç zamanını, süresini, tagları ve logları barındırır. Bu değerler key-value şeklinde tutulur. Jaeger bu Span’ları ve Trace’leri toplamak, depolamak ve görselleştirmek için birden fazla bileşeni barındırır.
Agent: Span’ leri dinlemek (UDP üzerinden gönderilen spanleri dinler.) için kullanılan bir servistir. Bu network’ de bir deamon olabilir. Toplanan spanler’ i collector’ e gönderir. All-in-one memory kurmuşsanız bu bir yere yazılmaz memory’ de tutulur. Jaeger’ ı production stratejisi ile kurmuşsanız toplanan span data’ sını ister Elasticsearch’ e isterseniz Kafka’ ya yazabilirsiniz.
Ingester: Eğer arada bir Kafka kullanıyorsanız burada span data’ larını Kafka’ da tutup oradan storage backendlere (Elasticsearch) yazabilirsiniz. Ingester bu işlem için var olan bir componenttir.
Query: Storage’ den traceleri getiren ve bunları Jaeger UI ile izlememize olanak tanıyan servistir.
Farklı Jaeger client’ ları olabilir. Bunların hepsi için OpenTracingAPI implement edilmelidir. Implementasyon sağlandığında, agent span’ leri toplar ve collector’ e gönderir.
OpenShift üzerinde Jaeger kullanmak isterseniz;
Bir Jaeger’ ı tüm namespace’ ler için kullanabilir ve tüm span data’ larını toplayabilirsiniz.
Her namespace özelinde bir Jaeger instance’ ı yaratabilirsiniz.
Service Mesh’ in bir parçası olarak da kullanabilirsiniz. Yine daha önce bahsettiğimiz gibi stand-alone olarak da kullanabilirsiniz.
Bir sonraki yazıda görüşmek üzere 😊
