Monolith'i Datadog ile İzleme: Seyirci Etkisinden Nasıl Kaçınılır

Büyük monolitik uygulamalarda, açık bir sahiplik eksikliği nedeniyle hata izleme ve izleme genellikle etkisiz hale gelir. Bu kılavuz, alan adı ek açıklamaları aracılığıyla hesap verebilirliği atamak için yapılandırılmış bir yaklaşım önererek sorunu ele almaktadır.

Birden fazla ekibin bulunduğu büyük monolitik sistemler için etkili izlemeyi ayarlamak zor olabilir. Açık bir sahiplik olmadan, hata izleme genel hale gelir ve çoğu zaman göz ardı edilir. Çözümlerden biri, nöbetçi mühendislerin izleme alarmlarına hangi ekibin yanıt vermesi gerektiğini belirlemesini sağlamaktır. Ancak daha verimli bir yaklaşım, her günlüğe ve Datadog aralığına etki alanı ve ekip bilgilerini dahil etmektir.

Etki Alanı Ek Açıklamalarını Anlamak

Uygulamamızın çeşitli bölümlerinden hangi ekibin sorumlu olduğunu takip etmek için Etki Alanı Ek Açıklamaları adı verilen bir sistem kullanıyoruz. Etki Alanı Ek Açıklamaları, uygulamanızın kodunun her bölümünü etiketleyerek kimin neden sorumlu olduğunu açıkça belirtir. Bu, sorumlulukların yönetilmesinde açık bir organizasyon ve hesap verebilirlik sağlar.

Etki Alanı Ek Açıklamalarını Kullanmanın Yararları

Etki alanı ek açıklamaları, yekpare bir uygulama içinde ekip sorumluluklarını izlemek için açık ve düzenli bir yöntem sağlar. Kodunuzun bazı kısımlarını alan adı ek açıklamalarıyla etiketleyerek şunları yapabilirsiniz:

• Günlük ve İzleme Yönetimini Basitleştirin : Günlükleri ve izleri ekip sorumluluğu gibi belirli kriterlere göre filtreleyerek sorunların hızlı tanımlanmasını ve çözülmesini sağlayın.
• Doğru Takibi Sürdürün : Ek açıklamalar ekip adlarından ziyade etki alanına bağlı olduğundan, ekip sorumluluklarındaki değişikliklere sorunsuz bir şekilde uyum sağlayın.
• Sorumluluğu Artırın : Her alandan hangi ekibin sorumlu olduğunu açıkça tanımlayın, organizasyonu ve hedefli izlemeyi iyileştirin.
• İzleme Verimliliğini Artırın : Kesin hesap verebilirlik sağlayarak ve genel verimliliği artırarak daha iyi izleme uygulamalarını kolaylaştırın.

Etki Alanı Ek Açıklamalarının İşlenmesi

Etkin izleme ve izlenebilirlik sağlamak için her web isteği uygun alan bilgileriyle etiketlenir. Bu, birkaç bileşenin işbirliğiyle elde edilir: DomainProvider , DomainSpanService , DomainMdcProvider ve DomainHandlerInterceptor .

Aşağıda, aşağıdaki diyagramda gösterilen sürece ilişkin üst düzey bir genel bakış yer almaktadır:

Temel Bileşenlerin Açıklaması

• DomainProvider : Belirli işleyici yöntemleri veya fasulyelerle ilişkili etki alanını tanımlar. AOP (Görünüm Odaklı Programlama) ve MVC (Model-Görünüm-Denetleyici) çağrılarında etki alanı ek açıklamalarının bulunmasına yardımcı olur.
• DomainSpanService : İzleme sistemlerinde iş birimleri olan yayılmalara etki alanı etiketleri ekler. Bu hizmet, her bir yayılma alanının uygun etki alanı bilgileriyle etiketlenmesini sağlar.
• DomainMdcProvider : Günlük girişlerinin bağlamsal bilgilerle etiketlenmesine olanak tanıyan bir günlük kaydı çerçeveleri özelliği olan MDC (Eşlenen Tanılama Bağlamı) içindeki etki alanı etiketlerini yönetir.
• DomainHandlerInterceptor : Daha iyi izleme ve izlenebilirlik için her isteğin uygun alan bilgileriyle etiketlenmesini sağlayarak web isteklerini yakalar.

Bu bileşenlerin ayrıntılı uygulaması, büyük monolitik uygulamalarda web isteklerinin etiketlenmesi ve izlenmesi için yeniden kullanılabilir bir çözüm sağlayacak şekilde paylaşılan bir kitaplıkta kapsüllenecektir.

Kimin Hangi Kodun Sahibi Olduğunu Ayırmak

Etki alanı ek açıklamalarıyla sınıf düzeyinde sahipliğin tanımlanması basittir. Ana sınıflara üst düzey ek açıklamalar uygulandığında sahiplik, bu sınıflardaki tüm ayrıntılı kaynaklara yayılır. Her ekip, sahip olduğu sınıfları uygun alan adı açıklamalarıyla etiketleyebilir, böylece her yöntemi işaretlemeye gerek kalmadan netlik ve hesap verebilirlik sağlanır.

Birden fazla ekibin tek bir sınıfta kod sahibi olduğu ve anında yeniden düzenlemenin uygun olmadığı durumlarda, sınıf düzeyindeki ek açıklamalara göre öncelikli yöntemleri farklı etki alanı açıklamalarıyla ayrı ayrı işaretleyebilirsiniz. Bu, belirli yöntemlerin farklı ekiplere atanmasına olanak tanır ve genel yapıyı karmaşıklaştırmadan esneklik sağlar.

Ek Açıklamalar Tarafından Desteklenmeyen Durumların Aşılması

Alan adı ek açıklamaları inanılmaz derecede faydalı olsa da kullanılamayacakları nadir durumlar da vardır. Örneğin, Quartz işi oluşturmada, Quartz'ın AOP mantığı ile alan adı açıklamaları için kullanılan AOP mantığı arasındaki çakışma nedeniyle alan adı açıklamalarıyla sorunsuz bir şekilde çalışmayan sorunlarla karşılaştık.

Doğrudan açıklama eklenemeyen işler ve süreçler için iş uygulamalarında doğrudan DomainTagsService'i kullandık. Bu yaklaşım, işin yürütme mantığı dahilinde etki alanı etiketlerini manuel olarak eklememize olanak sağladı.

Aşağıda DomainTagsService'i bir Quartz işine nasıl entegre ettiğimize dair bir örnek verilmiştir:

 final override fun execute(context: JobExecutionContext) { domainTagsService.invoke(domain) { withLoggedExecutionDetails(context, ::doExecute) } }

Yapay Hizmetlerle İzlemeyi ve Görünürlüğü İyileştirin

Her ekip için ayrı hizmetlere sahip olmak, izleme ve sahiplenme açısından önemli avantajlar sunarken, monolitin bölünmesi için yüksek maliyetler ve çabaların yanı sıra potansiyel ek geliştirme giderlerini de beraberinde getiriyor. Monolit modüllere bölündüğünde Gradle ile yapım sürelerini iyileştirme olasılığı göz önüne alındığında, çoğu durumda bir monorepo sürdürmek en etkili çözüm olabilir.

Yapay Hizmetlerin Tanıtımı

Datadog'da her ekibin faaliyetlerini izlemeyi kolaylaştırmak için farklı ekiplerin aralıklarına yapay hizmet adları atayabilirsiniz. Bu yaklaşım, Datadog'un izleme araçlarında her ekibin kendine özel bir bölümünün olmasını sağlar. Yapay hizmet adlarını kullanmak, yönetmeniz gereken çok sayıda hizmet varsa kafa karıştırıcı olabilir ancak sınırlı sayıda arka uç hizmetiyle yönetilebilir hale gelir. Bu yapay hizmet adlarına öneklerin eklenmesi, Datadog kurulumunuzda düzeni ve netliği korumaya yardımcı olarak farklı ekipler ve sorumlulukları arasında ayrım yapmayı kolaylaştırır.

ekran görüntüsü yerine diyagram mı kullanıyorsunuz? işçi/web uygulamasına sahip olmanın burada bir anlamı yok

Neden Günlükler için Yapay Hizmetleri Kullanmıyorsunuz?

Günlükler için yapay hizmet adlarının kullanılması, aynı günlük girişinin farklı hizmetler altında görünebilmesi nedeniyle kafa karışıklığına neden olabilir.

Örneğin, aynı kimlik doğrulama hizmetini kullanan iki uç noktayı düşünün. Bu uç noktalara farklı alan adları eklenirse, kimlik doğrulama mantığı farklı yapay hizmetler altında günlükler üretecektir. Bu, günlükler birden fazla hizmet adı altında göründüğünden, günlükler araştırılırken karışıklığa neden olabilir. Bu sorunu önlemek için yapay hizmet adlarını yalnızca izler halinde bir araya toplanan kapsamlara uygulamak daha iyidir; böylece daha az karışıklık olur

Bir anlam ifade ediyor mu? öyle olduğunu düşünmüyorum

İşte bu sorunun görsel bir temsili:

İzleme ve Kontrol Panellerinde Yapay Hizmetlerin Kullanımı

Yapay hizmetlerin kullanılması, yalnızca APM izlemeleriyle çalışmanıza değil, aynı zamanda uzun bir süre boyunca saklanan Datadog Metrics'te hizmete göre filtreleme yapmanıza da olanak tanır ve değişikliklerin uzun bir süre boyunca izlenmesine olanak tanır.

Monitör Örneği

Aşağıda, sorguda konsus-assets yapay hizmet adını kullanan Datadog'daki bir monitörün ekran görüntüsü bulunmaktadır:

Kontrol Paneli Örneği

Aşağıda, filtrede konsus-assets yapay hizmet adını kullanan Datadog'daki bir kontrol panelinin ekran görüntüsü bulunmaktadır:

İzleme stratejinizde sahte hizmetleri kullanarak, yekpare bir uygulama içinde her ekibin faaliyetlerinin görünürlüğünü ve hesap verebilirliğini artırabilirsiniz. Bu yaklaşım, ekibe özel monitörler ve gösterge tabloları oluşturma ve sürdürme sürecini basitleştirerek Datadog'da daha etkili ve düzenli izleme sağlar.

Kapanış

Etki alanı ek açıklamaları, Datadog'daki monolitik uygulamaların izlenmesini basitleştirmeye yönelik basit bir yaklaşım sağlar. Bu stratejiyi uygulayarak günlüklerin, aralıkların ve ölçümlerin yönetilebilirliğini geliştirebilir, izleme kurulumunuzu belirli ekiplere özel olarak tasarlanmış bir araca dönüştürebilirsiniz. Bu, sorumluluğu ve organizasyonu geliştirir ve uygulamanız genelinde daha etkili ve verimli sorun giderme ve performans analizini kolaylaştırır.

Temel Çıkarımlar

1. Gelişmiş Sahiplik ve Sorumluluk : Kodunuzun bazı bölümlerine alan adı ek açıklamaları ekleyerek, her alan adından hangi ekibin sorumlu olduğunu açıkça tanımlayabilirsiniz. Bu, daha iyi organizasyonu ve hedefe yönelik izlemeyi kolaylaştırır.
2. Geliştirilmiş Günlük ve İzleme Yönetimi : Etki alanı ek açıklamaları, hem günlükleri hem de izlemeleri ekip sorumluluğu gibi belirli kriterlere göre filtrelemenize olanak tanıyarak sorunların hızlı tanımlanmasını ve çözülmesini sağlar.
3. Yapay Hizmetlerde Esneklik : Aralıklar için (günlükler değil) yapay hizmet adlarının kullanılması, günlüklerin net kalmasını ve gerçek kökenlerine göre izlenebilir olmasını sağlayarak karışıklığı önler.
4. Entegrasyon Zorluklarının Üstesinden Gelmek : Quartz gibi belirli iş yürütme çerçeveleri gibi ek açıklamaların doğrudan uygulanamadığı durumlarda, iş uygulamalarında DomainTagsService gibi hizmetlerin doğrudan kullanılması, alana özgü izlemenin hâlâ sürdürülebilmesini sağlar.

Etki Alanı Ek Açıklamalarını Kullanmaya Adım Adım Yaklaşım:

1. Etki Alanlarını ve Ekipleri Tanımlayın

   Bu, kütüphaneyle değişecek!!!

   Uygulamanızda farklı etki alanlarını ve ekipleri temsil eden numaralandırmalar oluşturun:

   • @Domain sınıflara veya işlevlere uygulanabilen ve onları belirli bir etki alanı değeriyle işaretleyen bir açıklamadır.
   • DomainValue her biri bir ekiple ilişkili farklı etki alanlarını temsil eden bir numaralandırmadır.
   • Team , uygulama üzerinde çalışan çeşitli ekipleri temsil eden bir numaralandırmadır.

    @Retention(AnnotationRetention.RUNTIME) @Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION) annotation class Domain(val value: DomainValue) enum class DomainValue(val team: Team) { USER_MANAGEMENT(Team.TEAM_A), PAYMENT_PROCESSING(Team.TEAM_B), NOTIFICATIONS(Team.TEAM_C) } enum class Team { TEAM_A, TEAM_B, TEAM_C }

2. Sınıflara Açıklama Ekleyin (ve gerekirse Yöntemler)

    @Domain(DomainValue.USER_MANAGEMENT) class UserService { @Domain(DomainValue.PAYMENT_PROCESSING) fun processPayment() { ... } }

3. Desteklenmeyen Vakaları İşleme

   Doğrudan açıklama eklenemeyen durumlarda mantığı sarmak için doğrudan DomainTagsService kullanın.

    fun executeNotSupportedByAnnotationsLogic() { domainTagsService.invoke(domain) { executeLogic() } }

4. Datadog ile izleme

   Monitörler, kontrol panelleri ve APM izleme filtrelemesi için yapay hizmet filtreleri kullanın

Bu adımları izleyerek, monolitik uygulamanızda etki alanı ek açıklamalarını etkili bir şekilde uygulayabilir, böylece daha iyi izleme, hesap verebilirlik ve genel verimlilik sağlayabilirsiniz.

Yazıyı okuduğunuz için teşekkürler!