Application Real-Time Monitoring Service:Sağlanan Hizmetler

Bir API çağrısı için izleme yukarı akışı nedir?

Bu, yukarı akış uygulamalarının bu uygulamayı kaç kez çağırdığını ifade eder. Kayıtlar yalnızca yukarı akış uygulamasında bir ARMS izleme aracı (probe) yüklüyse görünür. Yukarı akış uygulamasında izleme aracı yoksa kayıt görünmez. Uygulamanın kendi kendine yaptığı çağrılar da yukarı akış olarak görünür.

Bazı API'lerde yukarı akış alım uç noktası eksik

Bir arayüz gerçekten yukarı akış çağrılarına sahipse ancak bu yukarı akış uygulamalarında ARMS izleme araçları yoksa yukarı akış çağrıları görünmez.

Bağlantı yukarı akış ve aşağı akış karışık

İzlemeniz SkyWalking bileşenlerini kullanıyorsa tüm izleme varsayılan olarak SkyWalking protokolünü kullanır. ARMS, 4,2.x sürümünden önce SkyWalking protokolünü desteklemede sorunlar yaşıyordu ve bu durum yukarı/aşağı akış tanımlama hatalarına neden oluyordu. 4,2.x veya daha sonraki bir sürüme yükseltin ya da Custom Configuration sayfasında Trace Context Propagation Protocol Settings altında izleme bağlamı yayılımı için SkyWalking dışı bir protokolü zorunlu kılın. Talimatlar için bkz. Trace Context Propagation Protocol Settings.

Dubbo arayüzü hata sayısı sıfır değil ancak izleme bulunamadı

3,2.x'ten önceki izleme aracı sürümlerinde Dubbo izlemeleri durum kodlarını doğru şekilde kaydetmiyordu ve bu durum hata izlemelerinin görünmesini engelliyordu. Bu sorun 3,2.x ve sonraki sürümlerde giderilmiştir.

API çağrılarında istisna sayısı sıfır değil ancak izleme aramasında istisna izleri görünmüyor

4,1.x sürümünden önce izleme araçları yalnızca hata ve yavaş izlemeleri kaydettiği için hatasız veya yavaş olmayan istisnalar örneklenmeyebilirdi. 4,1.x sürümünden başlayarak izleme araçları hata, yavaş ve istisna izlemelerini örnekler; bu nedenle istisnalar artık örneklemeyi tetikler.

Arayüz trafiği neden düştü?

Öncelikle düşüş zamanındaki CPU kullanımı, ağ G/Ç'si ve diğer ölçümleri kontrol ederek trafiğin gerçekten düşüp düşmediğini doğrulayın:

• Durum böyleyse genellikle gerçek trafikte bir düşüş söz konusudur.

• Değilse ARMS sunucu tarafında sorunlar olabilir. Bu durumda yardım almak için bir destek talebi gönderin.

Spring Cloud Gateway izleme trafiği yanlış

4.x öncesi izleme aracı sürümlerinde Spring Cloud Gateway enstrümantasyonunda hatalar vardı ve bu durum bazı senaryolarda trafik kaybına neden oluyordu. İzleme aracı sürümünü 4.x veya daha sonraki bir sürüme yükseltin.

Bir arayüz için yavaş SQL ifadelerini görüntüleyebilir miyim?

Eski Konsolda arayüzlerden önceki sarı noktalar ne anlama gelir?

Anlamını görmek için fare imlecini noktanın üzerine getirin.

• Sarı nokta yavaş bir çağrıyı gösterir. Varsayılan olarak 500 ms'den uzun süren istekler yavaş olarak işaretlenir. Bu eşiği Custom Configuration sayfasının Interface Call Configuration bölümünde ayarlayabilirsiniz.

• Kırmızı nokta bir hatayı gösterir.

Neden bazı 5xx durum kodları toplanmaz?

RFC7231'e göre 502 ve 504 gibi durum kodları ağ geçitleri tarafından oluşturulur ve mutlaka çağrılan hizmetten gelen gerçek yanıtı yansıtmaz. Ağ geçidinde ARMS izleme yoksa ancak arka uç hizmetinde varsa bu 5xx yanıtları sayılmaz.

NetWork And Dubbo Response Decode nedir?

Dubbo aktarım katmanı verilerinin seri durumdan çıkarılması için harcanan süreyi ölçen bir span'dir.

Arayüz adlarında neden * veya ARMS anahtar sözcükleri bulunur?

Bu durum arayüz adlarının son derece değişken olması durumunda ortaya çıkar. ARMS, benzer arayüzleri farklı kısımları değiştirerek birleştirir. Ayrıntılar için bkz. ARMS Convergence Mechanism.

Neden harici çağrı süresi gerçek aşağı akış hizmeti süresinden farklıdır?

Sunucu tarafındaki süre yalnızca arayüzün isteği işleme süresini ölçer. İstemci tarafındaki süre bağlantı kurulumu ve ağ süresini içerir. ARMS konsolu her iki süreyi ayrı ayrı gösterir ancak ağla ilgili süre kesin olarak belirlenemez.

Arayüz normal şekilde döndürüyor ancak tek çağrılı istisna sayısı sıfır değil

Bu beklenen bir durumdur. Bazı çerçeveler (OkHttp3 gibi) dahili olarak istisnalar fırlatır ve bunlar harici olarak yakalanır; bu nedenle iş mantığı normal kalır. ARMS bu çerçeveleri enstrümante ettiği için bu istisnaları kaydeder ancak bunlar gerçek iş sorunlarını göstermez. Bunları ele alıp almamaya siz karar verebilirsiniz. Bu istatistikler istisna mesajı ayrıntılarını yok sayar. Gerçek istisna mesajını görmek için istisnaya ait bir izlemeye tıklayın ve ardından yöntem yığınında istisnayı görüntülemek üzere arayüzün yanındaki simgesine tıklayın.

HTTP arayüz adları /error, /404, /, / gibi**

Bunlar genellikle ARMS'in bir rotayla eşleştiremediği beklenmeyen isteklerin sonucudur. Yaygın nedenler şunlardır:

• Var olmayan bir URL'ye istekte bulunma.

• Geçersiz karakterler içeren başlıklar gibi doğrulama hatalarına neden olan geçersiz istek başlıkları.

• Raw Netty gibi yönlendirme mekanizması olmayan HTTP sunucularını kullanma.

Neden arayüz çağrılarındaki istek sayıları izleme analizindeki sayılardan farklıdır?

İzleme analizi izleme verilerine dayanır ve örnekleme oranından etkilenir.

Neden arayüz ayrıntıları ve izleme analizi arasındaki kantil yanıt süreleri farklıdır?

Arayüz ayrıntıları, paketleme algoritmalarını kullanarak örnek başına kantilleri hesaplar. İzleme analizi ise arayüz için örneklenen span'lardan kantilleri hesaplar. Bu nedenle değerler farklılık gösterir. Ayrıntılar için bkz. ARMS Quantile Metric Calculation Principles.

API çağrı hacmi yaklaşık iki katına çıktı

Bu durum genellikle yükseltme sırasında hem 3.x hem de 4.x izleme araçlarının yanlışlıkla eklenmesi durumunda ortaya çıkar. Application Configuration > Agent Management yolunu izleyin, herhangi bir izleme aracını seçin ve JVM parametrelerini kontrol etmek için View Details seçeneğine tıklayın.

İki -javaagent parametresi hem 3.x hem de 4.x izleme araçlarının eklendiğini gösterir.

Örneğin, 3.x izleme aracı -javaagent:/home/admin/.opt/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar kullanırken 4.x izleme aracı -javaagent:/srv/ArmsAgent/aliyun-java-agent.jar kullanır.

Neden ARMS konsolu çağrı hacmi diğer kaynaklardan farklıdır?

Farklılıklar birden fazla şekilde ortaya çıkabilir. İki yaygın senaryo şöyledir:

• ARMS bir uygulama arayüzü için dakikada 500 çağrı gösterirken Nginx dakikada 200 çağrı gösteriyorsa bu durum genellikle bazı trafiğin Nginx'i atlayarak uygulamaya doğrudan eriştiği anlamına gelir.

• ARMS bir uygulamadan dakikada 400 VT erişimi gösterirken VT sunucusu izleme dakikada 1.000 yürütme gösteriyorsa bu durum genellikle birden fazla uygulamanın aynı VT'ye eriştiği; ARMS'in ise yalnızca belirtilen uygulamanın trafiğini gösterdiği anlamına gelir.

ARMS'in WebFlux senaryoları için desteği nedir?

4.x öncesi izleme aracı sürümleri yalnızca yerel Spring WebFlux ve spring-cloud-gateway'i destekler. Özel WebHandler değişiklikleri (Apache Shenyu gibi) desteklenmez.

Neden bana ait olmayan yukarı akış uygulamaları görüyorum ve neden ayrıntılarını görüntüleyemiyorum?

Bu uygulamalar genel hizmetler sağlıyorsa bu durum normaldir. Yukarı akış uygulaması başka bir kullanıcıya aittir ve bu durum kullanıcılar arası bir çağrı ilişkisi oluşturur. ARMS yukarı akış uygulama adını ve çağrı sayısını kaydeder ancak kullanıcı izolasyonu nedeniyle diğer kullanıcının uygulama ayrıntılarını görüntüleyemezsiniz.

Açık çağrı ilişkilerine rağmen neden beklenen yukarı/aşağı akış verilerini görmüyorum?

ARMS kullanıcı izlemelerini rastgele inceler ve LocalRootSpan içindeki trace.protocol.type alanını kontrol eder. Değer Jager ise büyük/küçük harf dönüştürme sorunları yukarı/aşağı akış tanımlama hatalarına neden olur. Bunu düzeltmek için başka bir protokole geçin veya bir destek talebi gönderin.

Trace Details sayfasında LocalRootSpan'i seçin ve sağ taraftaki Additional Information altında trace.protocol.type alanını kontrol edin. Normal bir değer örneği EagleEye şeklindedir.