Atlassian, hizmet ekiplerinden başlangıçta metrik gönderme yöntemlerini değiştirmelerini istemeden metrik platformunu OpenTelemetry Collector etrafında yeniden oluşturdu. Şirket, eski işlem hattını kaldırıp binlerce hizmeti yeniden yapılandırmak yerine UDP üzerinden StatsD arayüzünü korudu ve arkasındaki toplama, işleme ve yönlendirme katmanlarını kademeli olarak değiştirdi.
Önceki platform, on yılın büyük bölümünde Atlassian'ın geliştirdiği açık kaynaklı bir StatsD uygulaması olan gostatsd'ye dayanıyordu. Bu uygulama ana bilgisayarlarda yan araç, diğer tarafta ise toplama katmanı olarak çalışıyordu. Platform, bir hizmet seviyesi hedefi olan %99,95 ve düşük gecikme süresi doğrultusunda, 14 bölgeye dağıtılmış yaklaşık 100 bin ana bilgisayardan gelen metrikleri işliyordu.
Arayüzü sabit tutarak motoru değiştirmek
Atlassian ekipleri, altyapıyı değiştirmeden önce her hizmeti OpenTelemetry SDK kullanacak şekilde yeniden yapılandırmanın yıllar sürecek bir işlem olacağını ve uyarıların dayandığı verilerin kaybolması riskini taşıdığını değerlendirdi. Bu nedenle platformun arayüzü iç bileşenlerinden ayrıldı: Hizmetler aynı adrese ve StatsD biçiminde iletişim kurmaya devam ederken, iç katmanlar OpenTelemetry Collector'ın özel dağıtımlarıyla değiştirildi.
Tasarım; toplama, alma, birleştirme ve yönlendirme olmak üzere dört bağımsız aşamaya dayandırıldı. Toplama katmanı aynı zamanda StatsD ve OTLP'yi kabul edebilecek şekilde tasarlandı. Böylece ekipleri istemci kitaplıklarını değiştirmeye zorlamadan geçiş başlatılabildi ve doğrudan OpenTelemetry kullanılarak üretilen metriklerin önünü açtı.
Uygulamada ne değişti?
Toplama aşamasında, gostatsd yan aracı, daha önce izleme ekibi tarafından kullanılan OpenTelemetry Collector dağıtımıyla değiştirildi ve uygulamaların önceki davranışı korundu. Bu sayede her ana bilgisayarda iki yan araç çalıştırmak yerine metrikler ve izleme tek bir yan araçta birleştirilebildi.
Atlassian, bu birleştirmenin yüksek maliyetli Micros hizmetlerinde hizmet başına ortalama yaklaşık %3,9 CPU tüketimi azalttığını belirtiyor. Bu, filo genelinde yan araç maliyetinde yaklaşık %30'luk bir düşüşe karşılık geliyor. Ayrıca toplama katmanının OpenTelemetry metriklerini kabul edip doğrudan yeniden yönlendirebilmesi için bir OTLP alıcısı eklendi.
Alma aşamasında ise temel sorun zaman serisi durumuyla ilgiliydi. Aynı seriye ait her veri noktasının tek bir toplayıcıya gönderilmesi gerekiyordu. Eski sistem, nomad adlı dahili bir araç aracılığıyla hizmet ve ortam çiftine dayalı bir parçalama kullanıyordu. Ancak hizmet boyutlarındaki farklılıklar bazı toplayıcıların aşırı yüklenmesine, bazılarının ise düşük kullanımda kalmasına yol açtı.
Atlassian bunu, OpenTelemetry deposundaki loadbalancingexporter bileşenini kullanarak ve parçalamayı streamID'ye, yani tek tek zaman serilerinin kimliğine göre yaparak çözdü. Bu yaklaşım, büyük bir hizmetin verilerinin toplayıcı grubu genelinde dağıtılmasını, tek bir serinin ise aynı toplayıcıda kalmasını sağladı. Bunun sonucunda toplayıcılar arasındaki CPU dağılımı daha dengeli hale geldi, otomatik ölçeklendirme kapasitesi iyileşti ve yüksek yük uyarıları azaldı.
Toplama katmanında veri ve maliyet azaltma
Toplama katmanı dakikada yaklaşık 4,8 milyar veri noktasını işliyor, ancak yalnızca yaklaşık 220 milyon veri noktası depoluyor; bu da yaklaşık %96'lık bir azaltma anlamına geliyor. Metriklerin çoğu delta temporality kullandığından ve önceki bileşenler bu farkları kullanıcıların beklediği şekilde birleştirmediğinden, Atlassian metrik deltalarını birleştirmek için özel bir işlemci geliştirdi ve bunu atlassian-labs kapsamı altında açık kaynak olarak yayımladı.
Geçişin ardından toplama katmanı önceki CPU kaynaklarının yaklaşık yarısına ihtiyaç duymaya başladı. Kaynak, bu iyileşmeyi gostatsd biçiminin ayrıştırılmasının ortadan kaldırılması, yükün daha iyi dağıtılması ve OpenTelemetry topluluğundaki iyileştirmelerden yararlanılması gibi çeşitli faktörlere bağlıyor.
Son aşamada özel bir dahili yönlendirici, şirketin metrics-gateway adını verdiği durum bilgisi tutmayan bir Collector dağıtımıyla değiştirildi. Bu dağıtım, SignalFx ve S3 gibi birden çok hedefe gönderimi desteklemek için upstream dışa aktarıcılara dayanıyor; yeniden deneme, kuyruklar ve geri basınç denetimi özelliklerini de içeriyor. Açıklanan tasarıma göre yeni bir hedef eklemek, bağımsız bir entegrasyon projesi yerine yapılandırma değişikliği haline geliyor.
Kademeli geçişten alınan dersler
- Doğru ekiplerle başlayın: Atlassian, daha az hassas bir kapsamda erken geri bildirim almak için geliştirme ve test ortamlarını ve sorunlardan en fazla etkilenen hizmetleri seçti.
- Üretimi sürekli izleyin: Üretim yükleri altında gerçekleştirilen profiling, bileşenlerin davranışını ve maliyetini küçük testlerin veya yapay benchmark'ların ortaya koyamadığı şekilde gösterdi.
- Operasyonel benzerliği koruyun: Geçiş, sistemlerin paralel çalışmasıyla aylar veya yıllar sürebileceğinden şirket, ortak operasyon araçlarını ve prosedürlerini mümkün olduğunca korumayı önerdi.
- Kapsamı aşamalı olarak genişletin: Dağıtım süreci önce %1, ardından %10 ve %50, son olarak %100 oranlarını izledi; sorunlar kritik akışlardan önce daha az hassas hizmetlerde test edildi.
Bu yaklaşım neden önemli?
Bu deneyim, altyapıda yeni bir standardı benimsemenin tüm tüketicilerin arayüzlerini aynı anda değiştirmeyi gerektirmediğini gösteriyor. Dış sözleşmenin korunması, geçişi tüm ekipleri kapsayan kurumsal bir projeden altyapı platformunun yönettiği bir projeye dönüştürdü ve OTLP ile OpenTelemetry bileşenlerinin kademeli olarak kullanılmasına olanak sağladı.
Atlassian, gostatsd ve nomad'ın birlikte metrik kümelerindeki CPU isteklerinin yaklaşık %38'ini oluşturduğunu, nomad'ın tek başına ise toplam kaynakların yaklaşık %13'ünü temsil ettiğini belirtiyor. Bu nedenle geçişin etkisi yalnızca araçları birleştirmekle sınırlı değil; aynı zamanda maliyetli özel bileşenlerin kaldırılması ve dahili olarak bakımı gereken parça sayısının azaltılmasıyla da ilgili.
Ancak bu, hizmet enstrümantasyonu düzeyinde geçişin tamamlandığı anlamına gelmiyor. Şirketin belirttiği sonraki adım, enstrümantasyon araçlarını OpenTelemetry SDK'ye taşımak ve hâlâ kullanılan Datadog ile DogStatsD istemcilerinden ve dahili StatsD kitaplıklarından kademeli olarak vazgeçmek. Ayrıca burada verilen performans sonuçları ve rakamlar Atlassian'ın kendi ortamındaki deneyimini açıklıyor; aynı değerlerin her gözlemlenebilirlik altyapısında tekrarlanacağının garantisi değil.