New Relic ile Loglama ve Monitoring

Mehmet Kürşad Yuca
TurkNet Technology
Published in
7 min readNov 20, 2023

Loglama ve Monitoringin Avantajları

Uygulamaların karmaşıklığı arttıkça, bu uygulamaların izlenmesi, performans sorunlarının tespiti ve çözümü de daha kritik hale gelmektedir. Bu noktada loglama ve monitoring, geliştiricilerin ve operasyon ekiplerinin uygulamalarını başarılı bir şekilde yönetmelerini sağlayan temel unsurlardan biridir. Uygulamalarımız birçok farklı sistem ve uygulama arasında veri alışverişi yaparken veyahut farklı durumlarda zaman zaman sorunlarla karşılaşabilir. Hızlı bir şekilde yanıt verememe, hatalı istekler veya sunucu problemleri gibi durumlar, kullanıcı deneyimini olumsuz etkileyebilir ve uygulama güvenilirliğini zedeleyebilir. İşte bu gibi durumların önceden tespit edilmesi ve çözülmesi için loglama ve monitoring büyük önem taşır.

1. Hızlı Sorun Tespiti ve Çözümü

Monitoring, uygulamalardaki performans sorunlarını hızlı bir şekilde tespit etmeyi sağlar. Anlık veri izleme, hataları ve performans düşüşlerini anında fark etmeyi ve bu sorunlara hızlı çözümler bulmayı mümkün kılar.

2. Kullanıcı Deneyimi İyileştirilmesi

Uygulamaların izlenmesi sayesinde, kullanıcıların deneyimini olumlu yönde etkileyebilirsiniz. Hızlı yanıt süreleri ve düşük hata oranları, kullanıcı memnuniyetini artırır ve uygulamanızın güvenilirliğini pekiştirir.

3. Verimlilik ve Performans Optimizasyonu

Monitoring, uygulamaların performansını anlamak için kritik metrikleri sağlar. Bu metrikler üzerinden yapılan analizler, uygulamaların daha verimli çalışmasını sağlamak için gerekli optimizasyonları belirlemede yardımcı olur.

4. Altyapı Yönetimi

Monitoring, sunucu, veritabanı ve diğer altyapı bileşenlerinin performansını izleyerek sorunları tespit eder. Bu, altyapınızın sağlığını sürdürmeniz ve gerektiğinde ölçeklendirmeniz için önemli bir unsurdur.

5. Proaktif Sorun Çözümü

Monitoring, potansiyel sorunları önceden tespit ederek proaktif bir yaklaşım sunar. Bu sayede, kullanıcılar sorunları fark etmeden önce çözümler geliştirilebilir, bu da iş sürekliliğini artırır.

6. Güvenlik

Monitoring, uygulamalarınızdaki güvenlik olaylarını takip etmenize yardımcı olur. Anomalileri ve potansiyel güvenlik tehditlerini tespit ederek, güvenlik önlemlerinizi güçlendirebilirsiniz.

Monitoring, genel olarak uygulamaların güvenilirliğini artırarak, geliştiricilere ve operasyon ekiplerine daha sağlam bir altyapı sağlar.

Şimdi new relic ile nasıl monitoring ve loglama yapıldığına bakalım.

New Relic ile neler yapabiliriz?

APM & Services

Uygulamalarımızın yanıt sürelerini (response time), apex skorlarını (yazının devamında bahsediyorum), hataları (error rate) gibi bir çok parametreyi bizlerin takip edebilmesini sağlar.

Infrastructure

Sunucu veya veritabanı gibi bileşenlerin performanslarını izler ve sorunları tespit eder.

Loglama

Loglarımızı izleyebilmemizi sağlar. Hataların kaynağını bulmak için raporlama imkanı sağlar.

Synthetic Monitoring

Availability

Bir url’e ping atarak availability durumunu bildirir.

Endpoint Availability

Endpointlere HTTP isteği göndererek healthcheck gibi bilgiler verir.

Crawler

Kırık linkleri tespit eder.

Page Load Performance

Bir sayfayı yükler ve first time response gibi değerleri verir.

Certificate Check

SSL sertifikalarının geçerliliğini kontrol eder.

Alerts

Policy

Oluşan issue’lara göre bildirim ayarını yaptığınız bu bölümde webhook, jira, slack, email gibi bildirim seçeneklerini yapılandırırsınız.

Conditions

Tanımlamalarınızı yaptığınız containerları, hostları veya servislerinizi seçererek metrik tanımlarınızı ve thresholdlarınızı belirlersiniz.

New Relic’in Kubernetes, Network, Mobile App Performance, Vulnerability Management gibi bir çok hizmeti daha bulunmaktadır. Bu yazım loglama ve monitoring üzerine olduğu için APM & Services ile devam edelim.

APM & Services

Newrelic’e kayıt olduktan sonra ilk uygulamamızı oluşturalım. Monitoringe başlamadan önce uygulamanızın platformunu ve buna bağlı olarak New Relic Agentini yüklemeniz gerekmektedir. Adım adım gidecek olursak aşağıdaki gibi bir ekran sizleri karşılayacaktır.

Newrelic Karşılama Ekranı
Uygulamanın Çalışma Yöntemi

Ben burada .NET ile örnek bir proje oluşturdum ve bu projeyi localimde dockerize etmeden önce New Relic’in dockerfile’a eklememi istediği kısmı da ekleyerek projemi dockerize ettim ve 8080 portunda çalıştırdım.

Containerlar

NewRelicExampleDb containeri: Üzerinde tek bir database ve tablo bulunan uygulamamın bağlandığı veritabanı containeri.

Newrelic-infra containeri: New Relic agentinin containeri. Yukardaki adımları uygularken size gereken komutu veriyor.

newrelicexample containeri: 8080 portunda çalışan uygulama containerim.

Benim projem localimde bulunan postgresql’e bağlanarak Product tablosunu veren tek bir endpointten oluşan bir apidir. Yazının sonunda projenin kaynak kodlarını paylaştım.

Eğer başarılı bir şekilde kurulumları tamamladıysanız APM & Service bölümünde aşağıdaki gibi bir ekran sizleri karşılayacaktır.

Web Transaction Time

Bir isteğin işlenip kullanıcıya geri dönmesine kadar geçen süreyi ölçer.

Apdex Score

Apdex skoru aşağıdaki gibi hesaplanır:

Apdex Skoru = (Satisfactory sayısı + (Tolerable sayısı / 2)) / Toplam ölçüm sayısı

Burada 3 farklı threshold vardır.

SatisFactory: Kullanıcıların kabul edilebilir olarak değerlendirdiği tepki süresini ifade eder.

Tolerable: Kullanıcıların kabul edebileceği maksimum süreyi ifade eder.

Frustrating: Kullanıcıların tatmin olmadığı süreyi ifade eder.

Buna göre;

  • Satisfactory sayısı: Tolerans eşiği (T) değerinden daha hızlı yanıt veren ölçümlerin sayısını temsil eder.
  • Tolerable sayısı: Tolerans eşiği (T) ile rahatsız edici eşiği (F) arasında olan yanıtların sayısını temsil eder.
  • Toplam ölçüm sayısı: Tüm ölçümlerin toplam sayısını temsil eder.

Apdex skoru genellikle 0 ile 1 arasında bir değer alır, burada 1 en iyi performansı ve kullanıcı deneyimini, 0 ise en kötü performansı ve kullanıcı deneyimini temsil eder. Apdex skoru ne kadar yüksekse, uygulamanın performansı ve kullanıcı deneyimi o kadar iyidir.

Throughput

Dakika da kaç isteğin işlendiğini gösterir.

Errors

Alınan isteklerin yüzdelik olarak ortalamasını verir. Buradan alert mekanizmaları da kurabilirsiniz.

Sol menü de yer alan kısımlar ile devam edelim.

Distributed tracing

Distributed Tracing

Özellikle mikroservis mimarilerinde kullanıcıların her bir isteğine trace id atanır. İstek servislerden geçerken her sistem işlemi span olarak adlandırır. İlk oluşan span root spandır.

Bu bölümde trace count’ı istek sayısı gibi olarak kabul edebiliriz.

Trace duration ise isteğin işlenme süresi olarak kabul edilebilir.

En alt bölümde ise apimizin trace gruplarını bir bakıma en çok istek alan endpointlerini görmekteyiz.

Transactions

Transaction Dashboard

Burada top 20 transactionı alan endpointleri, throughput(dakika başı istek) grafiğini, cpu usage ve memory usage grafiklerini görebilirsiniz.

Databases

Database Operations Dashboard

Top 20 database operasyonunu, database’e atılan isteklerin query timelarını ve database throughputlarını görebilirsiniz.

Errors

Error Dashboard

Son 24 saatte alınan hataları gruplayarak sayısını görebilirsiniz. Bu hatalara göre alarm oluşturabilirsiniz. Yazının devamında alert bölümünde daha detaylı bahsediliyor.

Logs

Log Dashboard

Belirlediğiniz saat dilimine göre logları görebilirsiniz. Yukardaki gibi bir görüntü elde edebilmek için kolon ekleyerek log leveli seçebilirsiniz.

Log Detail

Log kayıtlarının üzerine gelerek log detaylarını görebilirsiniz.

Ayrıca sol menüde olan Dashboards kısmından Logs Analysis dashboardını create ederek de daha detaylı bir log analizi çıkartmak mümkündür.

Log Analysis Dashboard
Log Analysis Dashboard 2
Log Analysis Dashboard 3

SLA

SLA Report

Bir hizmetin belirli bir süre zarfında ne kadar iyi veya ne kadar kötü performans gösterdiğini gösteren bir rapordur.

Request, response time, apdex, satisfied, tolerating, frustrated ve error rate’i rapor olarak görebildiğimiz bölümdür.

Ayrıca işlenen request sayısı, ortalama response time’i ve apdex skorunu da grafik olara görebilirsiniz.

Performance

Performance Dashboard

Endpointleriniz arasında son 24 saat, önceki 24 saat ve 7 günlük ortalama throughputlarını, apdex skorlarını ve ortalama zamanlarını görerek karşılaştırma yapabilirsiniz.

Percentil Analizi: P90, P95 ve Daha Fazlası

Monitoring sırasında kullanılan metriklerden biri de percentil değerleridir. Bu değerler, veri kümesinin belirli yüzdelik dilimlerini temsil eder ve performans analizi için önemli bilgiler sağlar.

1. P90 (Percentil 90)

P90, veri kümesinin %90'lık dilimini temsil eder. Yani, değerlerin %90'ı bu belirli noktadan düşük olacaktır. P90 değeri, uygulamanın genel performansını değerlendirmek için kullanılır ve outlier’ları (aykırı değerleri) göz ardı eder.

Örneğin, bir P90 değeri şu şekilde yorumlanabilir: “Uygulamanın %90'ı zaman içinde bu belirli yanıt süresine sahiptir veya bu süreden daha hızlı yanıt verir.”

2. P95 (Percentil 95)

P95, veri kümesinin %95'lik dilimini temsil eder. Bu değer, P90'a benzer şekilde uygulamanın performansını değerlendirir, ancak daha geniş bir perspektif sunar. P95, outlier’ları azaltarak daha genel bir resim çizer.

P95 değeri şu şekilde yorumlanabilir: “Uygulamanın %95'i zaman içinde bu belirli yanıt süresine sahiptir veya bu süreden daha hızlı yanıt verir.”

3. Percentil Analizi ve Performans İyileştirmesi

Percentil analizi, uygulamanızın performansını daha ayrıntılı bir şekilde anlamanıza yardımcı olabilir. Özellikle P90 ve P95 gibi değerlere odaklanmak, tipik kullanıcı deneyimini ölçmek ve nadir görülen ancak kritik performans sorunlarını belirlemek açısından önemlidir.

Monitoring araçları, bu percentil değerlerini görselleştirerek, performans hedeflerine ulaşılıp ulaşılmadığını değerlendirmenize olanak tanır. Eğer P90 veya P95 değerleri istenilen seviyelerin üzerindeyse, bu, belirli optimize edilmesi gereken alanları işaret edebilir.

4. Diğer Percentil Değerleri

P90 ve P95 dışında P50 (ortanca), P99 gibi diğer percentil değerleri de kullanılabilir. Bu değerler, genel performansın farklı yüzdelik dilimlerini temsil eder ve uygulamanın kullanıcı deneyimini daha kapsamlı bir şekilde değerlendirmenize olanak tanır.

Alerts

Yazının başında bahsettiğim alert kısmında olduğu gibi kendi tercihlerinize göre alert policy ve alert conditionlarını belirleyebilirsiniz. Ya da new relicin oluşturduğu alert policylerini seçebilirsiniz. Ben bu şekilde örnek bir policy seçerek üzerinde değişiklikler yaptım. Aşağıdaki örnekte görebileceğiniz üzere memory usage, high cpu utilization, apdex score, transaction error gibi bir çok condition belirleyebilirsiniz. Daha sonra bu conditionlara göre açılan issuelara notification (email,slack,jira vb.) belirleyebilir ve overview bölümünden açılan issueların yüzdeliklerini, zamanlamalarını görebilirsiniz.

Alert Conditions
Alert Overview
Alert Email Notification

Oluşturduğum projenin kodlarına ve dockerfile’a aşağıdaki linkten erişebilirsiniz.

--

--