Ele.me İzleme Sistemi EMonitor ve Meituan Dianping CAT Karşılaştırması
Yazar | Li Çetesi
Bu makale, Alibaba Middleware'den (ID: ilieyun) yeniden yazdırmak için yetkilidir.
Arka plan tanıtımı
Ele.me izleme sistemi EMonitor: Sistem izleme, konteyner izleme, ağ izleme, ara katman izleme, iş izleme, erişim katmanı izleme ve ön uç izleme gibi Ele.me'nin tüm teknik departmanlarına hizmet veren tek noktadan izleme sistemidir. Veri depolama ve sorgulama. Günde işlenen toplam veri miktarı neredeyse PB, her gün yazılan gösterge verisi miktarı 100T, günlük gösterge sorgusu miktarı on milyonlarca, yapılandırma çizelgelerinin sayısı onbinlerce ve kanban sayısı binler.
CAT: Meituan Dianping için kapsamlı gerçek zamanlı izleme ve uyarı hizmetleri sunan, Java tabanlı geliştirilmiş gerçek zamanlı bir uygulama izleme platformudur.
Bu makale, izleme sisteminin olası görünümünü tartışmak ve izleme sisteminin gelişiminin çeşitli aşamalarını tartışmak için bir fırsat olarak bu ikisi tarafından yapılan şeylerin karşılaştırmalı bir analizini kullanır.
CAT ne yapar (açık kaynak sürümü)
Vurgulamamız gereken ilk şey, sadece CAT'in açık kaynak sürümünün en son sürümünü GitHub'da alabileceğimizdir. 3.0 .0, dolayısıyla karşılaştırma buna dayanmaktadır. Sonra, CAT ne yaptı?
Monitör modelini soyutlayın
İşlem, Olay, Sinyal ve Metrik'in dört izleme modeli soyutlanmıştır.
-
İşlem: bir kod parçasının yürütme zamanını ve sıklığını kaydetmek için kullanılır.
-
Olay: bir olayın meydana gelme sayısını kaydetmek için kullanılır.
-
Heartbeat: CPU kullanımı gibi programda düzenli olarak üretilen istatistiksel bilgileri gösterir.
-
Metrik: İş göstergelerini kaydetmek için kullanılır, bu göstergelerin sayısı ve toplamı kaydedilebilir.
Hem İşlem hem de Etkinlik için iki boyut sabitlenmiştir; tür ve ad ile tür ve ad bir raporda toplanır ve dakikalar içinde eğrileri görüntüler.
Örnekleme bağlantısı
Yukarıdaki İşlem ve Etkinliğin türü ve adı için karşılık gelen dakika düzeyinde örnekleme bağlantıları vardır.
Özelleştirilmiş Metrik yönetimi
Şu anda, sayaç ve zamanlayıcı yönetim türleri desteklenmektedir ve etiketler desteklenmektedir.Tek bir makinede tek bir metrik için etiket kombinasyonlarının sayısı 1000 ile sınırlıdır. Ve aşağıdaki şekilde gösterildiği gibi basit bir izleme panosu var:
Diğer bileşenlerle entegrasyon
Örneğin, Mybatis ile entegre edin, istemcide ilgili SQL yürütme istatistiklerini açın ve istatistikleri İşlem İstatistikleri Kanbanındaki tür = SQL sütununa bölün.
Uyarmak
Yukarıdaki İşlem, Etkinlik vb. İçin bazı basit eşik alarmları yapabilirsiniz.
Aç mısın EMonitor ve CAT Karşılaştırması
Aç mısın EMonitor, CAT ile ilgili fikirlerden yararlanır ve aynı zamanda iyileştirmeler yapar.
İşlem ve Etkinlik kavramlarını tanıtın
Hem İşlem hem de Etkinlik için tür ve ad olmak üzere iki boyut sabitlenmiştir. Fark, kullanıcılar tarafından gönderilen verilerin toplanmasında yatmaktadır.
CAT mimari şeması aşağıdaki gibidir:
CAT tüketici makinesinin aşağıdaki iki şeyi yapması gerekir:
-
İşlem ve Olay gibi mesaj modellerinin türüne ve adına göre mevcut saatin toplanmasını gerçekleştirin ve geçmiş saatin toplanmış verilerini mysql'e yazın;
-
Bağlantı verilerini yerel dosyalara veya uzak HDFS'ye yazın.
EMonitor'un mimari şeması aşağıdaki gibidir:
EMonitor, verileri iki şekilde izole eder:
-
Gerçek Zamanlı Akış Hesaplaması: Kullanıcı tarafından gönderilen bağlantıdaki işlem, olay ve diğer izleme modellerini gösterge verisine dönüştürerek 10s ön toplama gerçekleştirir.Aynı zamanda kullanıcı tarafından gönderilen Metrik veriler üzerinde 10s ön toplama gerçekleştirir. Son olarak, 10'ların önceden toplanmış verileri LinDB zaman serisi veritabanına yazılır (açık kaynak, ilgilenenler Dikkat Yıldız altında) ve Kafka'da, alarm modülü bekçi köpeğinin gerçek zamanlı alarmlar için Kafka'yı tüketmesine izin verin;
-
Gerçek Zamanlı Veri Yazıcısı: Kullanıcı tarafından gönderilen bağlantı verileri için bir bağlantı dizini oluşturun, dizini ve bağlantı verilerini HDFS ve HBase'e yazın ve aynı zamanda uygulamalar arasındaki bağımlılık ilişkisini kurun ve bağımlılık ilişkisini Neo4j'ye yazın.
Bu nedenle, EMonitor ve CAT arasındaki büyük bir fark, göstergelerin işlenmesinde yatmaktadır. EMonitor, bunu profesyonel bir zaman serisi veri tabanına aktarırken, CAT'ın kendi toplaması aşağıda gösterildiği gibi çok sınırlıdır:
-
CAT, tür ve ad verilerini yalnızca saat boyunca değil, tüm bir saat için görüntüleyebilir, yani herhangi iki zaman arasındaki rapor verilerini görüntüleyemezsiniz .. EMonitor bu kısıtlamaya sahip değildir;
-
Tüm türler toplandıktan sonra CAT yanıt süresini ve QPS'yi görüntüleyemez EMonitor, toplama için türü ve adı esnek bir şekilde birleştirebilir;
-
CATın türü ve adı raporları dakika düzeyinde, EMonitorunki ise 10s düzeyindedir;
-
CAT tipi ve adı doğrudan geçmiş rapor eğrisi ile karşılaştırılamaz EMonitor sorunları daha kolay bulmak için geçmiş rapor eğrisini karşılaştırabilir;
-
CAT türü ve ad listesinin ana sayfası bir grup sayı gösterir ve yanıt süresi TP99100ms gibi bazı sezgisel bilgiler hemen elde edilemez. Bu iyi mi yoksa kötü mü? EMonitor, doğrudan değerlendirilebilecek mevcut eğriye ve geçmiş eğriye sahiptir. tamam tamam değil;
-
CAT'in TP99 ve TP999'u, tek bir makinede belirli bir saat içindeki rapora göre doğrudur.Ayrıca, birden çok makinenin veya birden çok saatin toplanmış TP99 ve TP999'u ağırlıklı ortalamaya göre hesaplanır ve doğruluğunun iyileştirilmesi gerekir.
Ancak CAT'ın kendi avantajları da vardır:
-
CAT, TP999 ve TP9999 satırları içerir (ancak yine de doğrulukla ilgili bazı sorunlar vardır), EMonitor yalnızca TP99 kadar iyi olabilir;
-
CAT tipi ve adı makine boyutuna göre filtrelenebilir EMonitor bu kadar ince taneli olmamıştır.
Örnekleme bağlantısı
Şu anda hem CAT hem de EMonitor, örnekleme bağlantılarını türe ve ada göre filtreleyebilir. Farklılıklar şunlardır:
-
CAT'in örnekleme bağlantısı dakika düzeyinde ve EMonitor 10'lar düzeyindedir;
-
CAT, belirli bir tür ve isim için şu anda istenen bağlantıyı kolayca bulamamaktadır.EMonitor, belirli bir anda veya belirli bir süre içinde yanıt süresinde istenen bağlantıyı kolayca bulabilir (patent başvurusu yapılmıştır).
EMonitor'un bağlantıları aşağıdaki gibidir:
-
Bu resim, belirli bir 10 saniye süresinde belirli bir tür ve ad filtreleme koşulları altında bir örnekleme bağlantısıdır;
-
İlk satır, yanıt süresine göre sıralanmış, 10 saniye içindeki örnekleme bağlantısıdır;
-
İlgili bağlantı ayrıntılarını görüntülemek için bir yanıt süresine tıklayabilirsiniz.
Özelleştirilmiş Metrik yönetimi
EMonitor sayaç, zamanlayıcı, Histogram, Yük, Gösterge ve diğer yönetim yöntemlerini destekler ve etiketi destekler:
-
Sayaç: birikim türünü say;
-
Zamanlayıcı: çalıştırma sayısı, maksimum zaman tüketimi, minimum değer ve ortalama değer dahil olmak üzere bir kod parçasının zaman tüketimini kaydedebilir;
-
Histogram: Zamanlayıcı ile ilgili her şeyi içerir ve TP99 çizgilerinin ve diğer TP hatlarının (0'dan 100'e kadar) hesaplanmasını destekler;
-
Yük: Veri paketlerinin sayısı, maksimum değer, minimum değer ve paketin ortalama değeri dahil olmak üzere bir veri paketinin boyutunu kaydedebilir;
-
Gösterge: Genellikle kuyruk boyutunu, bağlantı sayısını, CPU'yu, belleği vb. Ölçmek için kullanılan ölçüm değeri.
Yani, herhangi bir metrik yönetimi, işlemek ve LinDB zaman serisi veritabanına taşımak için EMonitor üzerinden akabilir. Bu noktada, EMonitor herhangi bir izleme göstergesini birleştirebilir.Örneğin, makine izleme, tek noktadan izleme sisteminin temelini oluşturan EMonitor aracılığıyla kaydedilebilir.
Özel Metrik Kanban
CAT'in yalnızca bir basit Metrik Kanban EMonitor, Grafana for Metric ile karşılaştırılabilir bir dizi Kanban göstergesi geliştirmiştir. Grafana'nın avantajları ile karşılaştırıldığında:
-
SQL'e benzer göstergeleri yapılandırmanın çok basit bir yolu vardır;
-
Şirketin personel organizasyon yapısı ile entegre, daha zarif erişim kontrolü, farklı departmanlar kendi Kanbanlarını oluşturabilir;
-
Gösterge ve kanban koleksiyonu, kaynak göstergesi veya kanban değiştirildiğinde, koleksiyoncuların onu değiştirmesine gerek yoktur;
-
Farklı alfa, beta ve prod ortamları arasında göstergelerin ve reklam panolarının tek tıklamayla senkronizasyonu, birden çok kez yapılandırmaya gerek yoktur;
-
PC ve mobil terminallerdeki göstergeleri ve reklam panolarını aynı anda görüntüleyin.
SQL benzeri yapılandırma sorgu indeks yöntemi aşağıdaki gibidir:
-
Grafiğin görüntüleme formu yapılandırılabilir;
-
Sorgulanacak alanları ve alanlar arasında toplama, çıkarma, çarpma, bölme gibi zengin ifadeleri yapılandırabilirsiniz;
-
Herhangi bir etiket için birden çok filtre koşulu yapılandırabilirsiniz;
-
Grubu yapılandırabilir ve göre sıralayabilirsiniz.
Genel Kanban aşağıdaki gibidir:
Mobil terminal aşağıdaki gibi görüntülenir:
Diğer bileşenlerle entegrasyon
Şu anda EMonitor, IaaS katmanının, PaaS katmanının ve uygulama katmanının tüm bağlantılarının ve göstergelerinin izlenmesini açtı.Aşağıda gösterildiği gibi, birden fazla izleme sistemi arasında geçiş yapmaya gerek yoktur:
-
IaaS katmanındaki fiziksel makinelerin, bilgisayar odası ağ anahtarlarının vb. İzleme göstergeleri;
-
PaaS katman ara yazılım sunucusu izleme göstergeleri;
-
Uygulama katmanı SOA, İstisna, JVM, MQ ve müşteriyle ilgili diğer göstergeler;
-
Uygulama katmanı tarafından özelleştirilmiş izleme göstergeleri.
Ele.me'yi örnek olarak alın:
Bilgisayar odasına, yürütme durumuna, tabloya, işlem türüne (Ekle, Güncelle, Seç vb.) Göre filtreleyebilir ve görüntüleyebilirsiniz:
-
Soldaki liste, her SQL'in ortalama yürütme süresini verir;
-
Sağdaki iki grafik, bu SQL'in DAL ara yazılım seviyesinde, DB seviyesinde ve QPS çağrısındaki zaman tüketimini gösterir;
-
Arka uç DAL'ın ortasında ve DB'de SQL'in dağıtımı verilebilir, bu da bazı sorunların olup olmadığını gidermek için kullanılabilir;
-
SQL sorgu sonuçlarının veri paketi boyutunun bazı eğrileri de vardır, SQL'in DAL ile sınırlandırıldığı durum vb .;
-
SQL çağrı bağlantı bilgilerini herhangi bir zamanda görüntüleyebilirsiniz.
Ele.me SOA hizmetini kullanma örneğini ele alalım:
-
Bilgisayar odası ve durum bilgilerine göre filtreleyebilir;
-
Soldaki sütun, ortalama yanıt süresi ve dün ile karşılaştırmanın yanı sıra uygulama tarafından sağlanan SOA hizmeti arabirimlerini listeler;
-
Sağdaki iki grafik sırasıyla ilgili servis arayüzünün servis cevap süresini ve QPS'sini ve dün ile karşılaştırmasını gösterir.Aynı zamanda ortalama cevap süresi TP99 veya diğer TP değerlerine çevrilebilir ve ilgili eğriye hızlıca alarm ekleyebilen bir jumper ile donatılmıştır. Yönlendirme bağlantısı
-
Belirli bir makinenin problemini bulmak için her makinenin SOA arayüzünün yanıt süresini ve QPS'sini görüntülemek için tek makine boyutuna geçebilirsiniz;
-
SOA arayüzü çağrılarının farklı kümelerdeki dağıtım oranı verilebilir;
-
SOA arayüzünün tüm arayanları ve QPS'leri verilebilir;
-
SOA arayüzünün arama bağlantı bilgilerini herhangi bir zamanda görüntüleyebilirsiniz.
Uyarmak
Tüm izleme göstergeleri için aşağıdaki alarm yöntemleri yapılandırılabilir:
-
Eşik: CPU, bellek vb. İçin uygun basit eşik alarmı;
-
Aynı zil oranı: geçmişte aynı dönemle karşılaştırıldığında alarmlar;
-
Trend: Eşiksiz nispeten düzgün ve sürekli akıllı alarmlar için uygundur;
-
Diğer uyarı türleri.
İzleme Sisteminin Gelişim Trendinden Bahsetmek
Günlük izleme aşaması
Bu aşamanın uygulama yöntemi: program günlüğü, program çalışma günlüğünü depolamak ve sorgulamak için ELK kullanın, ELK ayrıca gösterge eğrisini de basitçe görüntüleyebilir.
Sorun giderme süreci: Bir sorun olduğunda, analiz ve sorun giderme için olası anormal günlükleri aramak için ELK'ya gidin.
Bağlantı izleme aşaması
Önceki aşamadaki sorunlar: ELK yalnızca günlükleri satır satır toplar veya arar ve analiz eder ve günlükler arasında bağlam yoktur. Bir talebin hangi aşamada uzun sürdüğünü bilmek zordur.
Bu aşamanın uygulama yöntemi: CAT, modelleme yoluyla İşlem ve Metrik gibi izleme modellerinin bir soyutlaması, bağlantı analizi ve basit raporları herkesin görüş alanına getirdiği ortaya çıktı.
Alarm yöntemi: Raporlar için eşik izleme ve sorun giderme süreci: Bir alarm olduğunda, hangi tür veya adın belirli bir sorunu olduğunu ayrıntılı olarak bulmak için rapora tıklayabilir ve ayrıntılı bilgileri görüntülemek için ilgili bağlantıyı bulabilirsiniz.
Gösterge izleme aşaması
Önceki aşamadaki sorunlar: CAT'in özel göstergeler için desteği nispeten zayıftır ve daha çeşitli sorgu toplama gereksinimlerini karşılayamaz veya gösteremez.
Bu aşamanın uygulama yöntemi: Zengin metrik göstergeleri destekleyin, bağlantıdaki bazı rapor verilerini göstergelere bölün ve bunları gösterge depolaması ve sorgulama için profesyonel zaman serisi veritabanına aktarın, yerleştirme veya kendi geliştirdiği gösterge panoları Grafana.
Alarm yöntemi: Göstergeler için daha bol bir alarm stratejisi sorun giderme süreci: Bir alarm olduğunda, temel nedeni kabaca bulmak için her sistemdeki gösterge kartlarını kontrol etmeniz ve ardından bağlantı toplamı analizini birleştirmeniz gerekebilir.
Platform entegrasyon aşaması
Önceki aşamadaki sorunlar: sistem izleme, ara yazılım ve iş izleme, bazı iş izleme, bağlantı izleme ve gösterge izleme, her birinin bir dizi veri toplama, ön işleme, depolama, sorgulama, görüntüleme ve alarm süreçleri vardır ve her sistem verileri işler. Biçim ve kullanım tek tip değildir.
Bu aşamanın gerçekleştirilmesi: sistem seviyesinden, konteyner seviyesinden, ara yazılım seviyesinden, iş seviyesinden vb. Olası bağlantıları ve gösterge izlemeyi açın, veri işleme sürecini birleştirin ve sürüm, değişim, alarm ve izleme eğrilerini entegre edin. Tek noktadan izleme platformu.
Alarm yöntemi: Tüm izleme verileri seviyeleri için birleşik bir alarm sorun giderme işlemi yapılabilir: tüm izleme eğrileri ve bağlantı bilgileri tek bir izleme sisteminde görüntülenebilir.
Şu anda, EMonitor'umuz bu aşamayı tamamlayarak şirketin uzun süredir var olan üç bağımsız izleme sistemini mevcut sisteme entegre etti.
Derinlemesine analiz aşaması
Önceki aşamadaki sorunlar:
-
Kullanıcılar tek bir sistemde tüm izleme verileri düzeylerini görebilseler de, her sorun giderme işlemlerinde her düzeyde bir sorun olup olmadığını kontrol etmek için yine de çok zaman harcamak zorundadırlar. Bir öğeyi gözden kaçırdıklarında, sorunun kökenini gözden kaçırabilirler. Çünkü;
-
Tüm işletmenin küresel bir izleme perspektifi yoktur, ancak ilgili uygulamaların perspektifi vardır.
Kısaca: önceki aşama bir izleme platformu oluşturmaktır, kullanıcı ilgili verileri kullanıcının sorguladığı herhangi bir göstergede gösterecektir, izleme platformu kullanıcı tarafından depolanan verilerin içeriği ile ilgilenmez. Şimdi düşüncemizi değiştirmemiz gerekiyor İzleme platformunun, kullanıcıların içinde depolanan veri içeriğini analiz etmelerine aktif olarak yardımcı olması gerekiyor.
Bu aşamanın uygulanması: Yapılması gereken tek şey, kullanıcıların analiz etmelerine yardımcı olma sürecini soyutlamak, kullanıcılar için uygulama pazarını ve iş pazarını oluşturmak ve pazar için ilgili kök neden analizi yapmaktır.
-
Uygulama pazarı: Mevcut uygulama için yukarı ve aşağı uygulama bağımlılıklarının izlenmesini, mevcut uygulama ile ilişkili makine izlemenin izlenmesi, redis, MQ, veritabanı vb. Oluşturmaktır ve kullanıcıların gitmesini beklemek yerine sorunları aktif olarak ortaya çıkarmak için her zaman uygulama için fiziksel incelemeler yapabilirsiniz. Göstergeleri tek tek kontrol edin ve ardından sorunu bulun;
-
İş piyasası: Piyasayı işletmeye göre ayırmak veya piyasayı otomatik olarak üretmek için bağlantıyı kullanmaktır Pazar, kullanıcıya hangi iş bağlantılarının sorunlu olduğunu hızlı bir şekilde söyleyebilir.
Kök neden analizi: Büyük bir pazarda çok sayıda bağlantı vardır ve her bağlantıda birçok gösterge vardır.Her alarm çıktığında her bir bağlantının göstergelerini detaylı bir şekilde analiz etmek gerekebilir.Örneğin Kafka'nın tüketiminin gecikmesi artar. Her türlü neden buna yol açabilir.Bir alarm her kontrol edildiğinde, analiz sürecinin manuel olarak analiz edilmesi ve kontrol edilmesi gerekir ki bu çok yorucudur.Bu nedenle, kök nedeni bulma sürecinin birleşik bir çözüm için modelleme yoluyla soyutlanması gerekir.
Trend raporu analizi: Kullanıcıların sorunun kademeli olarak biraz kötüleştiğini fark etmelerine aktif olarak yardımcı olun, örneğin, kullanıcı serbest bırakıldıktan sonra arayüzün zaman tüketimi artar ve kullanıcı onu bulamamış olabilir.Şu anda bir sorun olmamasına rağmen, sorunun yarının en yoğun döneminde ortaya çıkması çok muhtemeldir. Bunlar gerçekte meydana gelen kazalardır.
Aktif analiz yapmak istiyorsanız, ayrıca indikatör detaya inme analizine de güvenirsiniz, yani belirli bir göstergenin çağrı hacmi azaldığında, hangi etiket boyutu kombinasyonlarının azalmaya neden olduğunu aktif olarak analiz edebilirsiniz. Bu, yukarıdaki akıllı analizlerin çoğunun temelidir. Bu basit değildir. .
Alarm yöntemi: Her seviyedeki verileri izlemek için birleşik bir alarm sorun giderme süreci gerçekleştirilebilir: NOC, iş göstergelerine veya iş pazarına dayalı olarak hangi işletmenin veya uygulamanın bir sorunu olduğunu hızlı bir şekilde bilir ve uygulama sahibi, uygulama pazarının fiziksel incelemesiyle bilir Sorunu hızlı bir şekilde bulmak veya piyasada kök neden analizi gerçekleştirerek temel nedeni bulmak için dalgalanmaları, veritabanı dalgalanmalarını, belirli bir yukarı akış ve aşağı akış uygulamalarındaki dalgalanmalar gibi ilgili değişiklik bilgileri.
Günlük Kaydı, İzleme, Metrikler hakkında konuşun
Üçü arasındaki ilişki aşağıdaki şekilde gösterilmektedir:
Üçü gerçekten vazgeçilmezdir ve birbirini tamamlar, ancak şunu söylemek istiyorum:
-
Üçünün izleme ve sorun gidermedeki oranları oldukça farklıdır: Metrikler başı çeker, İzleme sonra gelir ve Günlüğe kaydetme en son gelir;
-
İzleme, uygulamalar arasındaki önemli bağımlılık bilgilerini içerir. Metrikler, derinlemesine analiz ve madencilik için daha fazla alana sahiptir. Bu nedenle, gelecekte, daha derin bir küresel analiz yapmak için İzleme'deki uygulama bağımlılıkları ile birlikte Metrikler üzerinde büyük bir yaygara çıkması kaçınılmazdır. Metrikler ve İzleme kombinasyonu daha fazla olasılık sağlar.
Referans bağlantısı:
CAT: https: // github .com / dianping / kedi
Açık kaynak dağıtılmış izlemenin derinlemesine analizi KAT:
https: //tech.meituan .com /2018/11/01/cat-in-depth-java-application-monitoring.html
Yazar hakkında: Li Çetesi Ele.me'nin dahili zaman serisi veritabanının LinDB projesinin lideri olan Ele.me izleme grubunun araştırma ve geliştirme uzmanı Ping Pong Kuangmo ekran adı şu anda akıllı izleme analizi alanına kendini adamıştır.
Bu makalenin küçük resmi: icon by dmbcjl
SON
