Prometheus-spring-boot-starter yönetimi istisna bildirimi mesajı hatırlatıcısı

Önsöz

Her şeyden önce çok tembelim (orz ).Proje kodunu her gün yazdıktan sonra ilgili kod segmentlerini test etmek gerekli olsa da, ters etki yapar.Çoğu durumda test etmeyi unutabilirsiniz veya test iyi gelir. Aslında sorun şu şekildedir Maruz kalma yok (öznel test, test sonuçlarının fikirlerinize göre çıkarılmasını kolaylaştırır), ardından kodu birleştirip test sunucusuna gönderin ve sonra uykuya dalın. Ertesi gün uyandıktan sonra, programda çeşitli hatalar buldum. Şu anda önceki günden kodu çekip izlemeye başlıyorsunuz ... Bekle, önce bugları toplayayım, sonra sunucuyu açayım, çıktı logunu açayım ... Aman Tanrım, bu bir test sunucusu olduğu için çok açabilirsiniz Günlükler (örneğin: sql günlüğü, parametrelerle biçimlendirilmiş; arabirim arama günlüğü, vb.), Boş zamanın acısı nedeniyle bir meslektaşın belirli bir hata işlevini bir düzineden fazla kez denemiş olması mümkündür. Binlerce satırlık günlük kaydı ile karşılık gelen anormallikleri bulmak gerçekten bir baş ağrısıdır. Yani projede bir anormallik olduğu zaman, bana doğrudan haber ver.

Başlamak için en hızlı

  • Bu projeyi mvn clean install yoluyla yerel depoda paketleyin.
  • Projenizdeki pom.xml'de aşağıdaki bağımlılıkları yapın
  • < bağımlılık > < Grup kimliği > com.kuding < /Grup kimliği > < artifactId > prometheus-yay-önyükleme-marş < / artifactId > < versiyon > 0.2.3-kişisel < / version > < /bağımlılık >
  • Application.properties veya application.yml içinde aşağıdaki yapılandırmayı yapın: (Yukarıdaki yapılandırma açıklamasına gelince, sonraki bölümde bahsedilecektir)
  • bahar: uygulama: isim: Prometheus-demo istisna uyarısı: dinding: phone-num: Dingding kaydının telefon numarası ağ kancası: Dingding robot setinin ağ kancası dahil-izleme-paketi: istisna izleme için paket yolu bildirim türü: dingding dinleme türü: ortak açık bildirim: doğru istisnalar hariç: -java.lang.IllegalArgumentException
  • Dingding konfigürasyonu için lütfen şu adrese gidin: Dingding Robot
  • Yukarıdaki yapılandırma tamamlandıktan sonra, bir demo testi yazabilirsiniz. İlk olarak, bir fasulye oluşturun:
  • @Bileşen @ExceptionListener // İstisna bildiriminin izlenmesi bu açıklamadan gelir public class NoticeComponents { public void someMethod (Dize adı) { System.out.println ("Bu bir parametredir:" + ad); yeni NullPointerException ("İlk istisna"); } public void anotherMethod (Dize adı, int yaş) { System.out.println ("Bu başka bir parametredir" + yaş); yeni IllegalArgumentException (isim + ":" + yaş); } }
  • Yukarıdakilerin tümü oluşturulduktan sonra, birim testleri yazabilirsiniz. İlk olarak, ilk testi gerçekleştirin:
  • @RunWith (SpringRunner.class) @Hayalhanemersin public class DemoApplicationTests { @Autowired private NoticeComponents noticeComponents; @Ölçek public void contextLoads () { noticeComponents.someMethod ("Bu bir parametredir"); } }

    Birim testini çalıştırdıktan sonra, DingTalk konfigürasyonunda herhangi bir sorun yoksa, DingTalk'ınızda aşağıdakine benzer bir mesaj görünecektir:

    Ayrıca başka bir test noticeComponents.anotherMethod ("Zhao Si", 55); yapabilirsiniz, ancak yapılandırıldığı için sonuç bildirimi olmadığını açıkça söyleyebilirsiniz

    istisnalar hariç: -java.lang.IllegalArgumentException

    Ve yöntemin ortaya koyduğu şey tam olarak bu istisnadır:

    public void anotherMethod (Dize adı, int yaş) { System.out.println ("Bu başka bir parametredir" + yaş); yeni IllegalArgumentException (isim + ":" + yaş); }

    Yani doğal olarak hiçbir sonuç olmayacak.

    Özetle, basit bir örnek tamamlandı

    Nasıl yapılır

    Bu çerçeve, yaylı önyükleme başlatıcısının otomatik konfigürasyon spesifikasyonuna uygun olarak geliştirilen otomatik bir istisna bildirim çerçevesidir. Genel iş süreci aşağıdaki gibidir:

    Yapılandırma

    Bu çerçeve yapılandırması temel olarak 4 bölüme ayrılmıştır:

  • Global yapılandırma
  • Bildirim yapılandırması
  • Politika yapılandırması
  • Dış yardım yapılandırması
  • Global yapılandırma

    • Genel konfigürasyon esas olarak ExceptionNoticeProperty sınıfına dahil edilir En temel konfigürasyon istisna bildirimi konfigürasyonunun istisna bildirimi.open-notu etkinleştirilip etkinleştirilmeyeceğidir.Geliştirme ortamında, test ve hata ayıklama gerçek zamanlı geri bildirimler olduğundan, hatalar hemen düzeltilebilir. Anormal bildirimi yapılandırmanız gerekiyor, ancak çevrimiçi test veya üretim ortamının yine de açılması gerekiyor
    • Her istisna atıldığında, istisnanın izleme bilgisi çok uzundur.Exceptionnotice.included-trace-paketi bu sorunu çözmek için vardır.Genel olarak, bu yapılandırma öğesi, projenizin paket yolunu yapılandırmak içindir. , Projenizde bir istisna meydana geldiğinde, exceptionnotice.included-trace-package, paket yolunu içeren izleme bilgilerini filtreler ve aracı tarafından oluşturulan izleme bilgilerini kaldırır, böylece neyin yanlış gittiğini bir bakışta açıkça anlayabilirsiniz.
    • Her projenin bir proje adı olacak.Ne de olsa hangi projenin yanlış olduğunu bilmem gerekiyor. Konfigürasyon proje adı istisnanotice.project-adı. Proje adı yapılandırılmamışsa, çerçeve önce spring.application.name'yi arayacak. Bu da böyleyse Yapılandırma yok, o zaman projenin ne olduğunu bilmiyorum, bu yüzden adı: Bilinmeyen Proje
    • Çerçeve konfigürasyonundaki en önemli konfigürasyon şudur: exceptionnotice.listen-type, bu projenin izleme yöntemini temsil eder. Şu anda iki izleme yöntemi vardır: ortak izleme (ortak) ve mvc izleme (web-mvc). Bu iki izleme yönteminin kendi yararları vardır: Ortak izleme yöntemi esas olarak açıklamalı yöntemleri veya sınıfları izlemek için aop kullanır ve herhangi bir sınıf ve yönteme eklenebilir. Bununla birlikte, MVC izleme yalnızca denetleyici katmanını izleyebilir ve diğer katmanlar için geçersizdir.Ancak, istisna bildiriminin bilgileri daha zengindir.Sadece sıradan izlemenin tüm bilgilerini (parametreler hariç) değil, aynı zamanda istekteki parametre bilgilerini de içerir (param) , Talep gövdesinde gövde bilgisi (gövde) ve başlık bilgisi (başlık) talep edin:

    • Exceptionnotice.listen-type = web-mvc ile, istek başlıkları filtrelenebilir ve tüm istek başlıkları varsayılan olarak döndürülür
    exceptionnotice.include-başlık-adı = başlıkAdı1, başlıkAdı2
    • Projedeki istisnalar genellikle iki kategoriye ayrılır: birinci kategori yakalanmamış istisnalar ve ikinci kategori iş istisnalarıdır. İş istisnaları genellikle kullanıcıların kendileri tarafından tanımlanır.Javaweb projelerinde, kullanıcının talebi sonuçları döndürme koşullarını karşılamıyorsa, genellikle özel istisnaların aktif olarak atılması gerekir, bu nedenle bu tür istisnaların bildirilmesine gerek yoktur. İstisna bildirimi içermeyen yapılandırma aşağıdaki gibidir:
    exceptionnotice.exclude-exceptions = java.lang.IllegalArgumentException, com.yourpackage.SomeException
    • Genişletmeyi ve geliştirmeyi kolaylaştırmak için, bu çerçeve aynı zamanda istisna bilgilerinin kalıcılığını da destekler. Şu anda yalnızca yeniden kalıcılığı desteklenmektedir. Yeniden kalıcılığı etkinleştirmek için aşağıdaki yapılandırma gereklidir
    exceptionnotice.enable-redis-storage = true exceptionnotice.redis-key = Kendi redis anahtarınız

    Redis depolamanın yapısı, redis'in HASH arayüzüdür. HASH'ın anahtarı, istisna bildirim bilgilerinde hesaplanan benzersiz bir kimliktir ve HASH'ın değeri, karşılık gelen istisna bilgisidir. Benzersiz kimliğin algoritması da çok basittir:

    private String calUid () { String md5 = DigestUtils.md5DigestAsHex ( String.format ("% s-% s", istisnaMessage, traceInfo.size () > 0? TraceInfo.get (0): "") .getBytes ()); dönüş md5; }

    Buradaki redis depolamayı açmak, yay önyükleme başlatıcı veri redisine güvenmeli ve kullanıcı tarafından yapılandırılmalıdır

    Bildirim yapılandırması

    • Şu anda, çerçeve tarafından sağlanan iki istisna bildirimi yapılandırması vardır: DingTalk yapılandırması ve e-posta yapılandırması Yukarıdaki ikisine ek olarak, kullanıcılar bildirim yapılandırmasını kendi koşullarına göre özelleştirebilirler.Yalnızca INoticeSendComponent arabirimini miras almaları ve yönetim için IOC konteynerine devretmeleri gerekir. Evet; hangi bildirimin yapılandırılacağı application.properties dosyasındaki exceptionnotice.notice-type ile seçilir.
    • Dingding bildirimini seçmek için, exceptionnotice.notice-type = dingding'i yapılandırmanız ve Dingding ile ilgili bilgileri yapılandırmanız gerekir:
    istisna uyarısı: dinding: phone-num: Dingding'in kayıt sırasında cep telefonu numarası ağ kancası: Dingding robot setinin ağ kancası
    • E-posta bildirimini seçmek için, exceptionnotice.notice-type = email'i yapılandırmanız ve e-posta ile ilgili bilgileri yapılandırmanız gerekir:
    istisna uyarısı: e-posta: kime: kime cc: Kim bilgi CC'ye bcc: Gizli CC kime

    E-posta bildirimi, baharın e-posta yapılandırmasına dayanır, bu nedenle yukarıdaki yapılandırmaya ek olarak, Spring'in e-posta ile ilgili yapılandırma bilgileri de gereklidir:

    bahar: posta: host: smtp.xxx.com bağlantı noktası: 25 kullanıcı adı: smtp izni etkinleştirilmiş posta kutusu kullanıcı adı şifre: şifre

    Politika yapılandırması

    Genel olarak, bir yöntemde istisna bilgilerinin ortaya çıkması, aynı yöntem her çağrıldığında aynı istisna yönteminin atılacağı anlamına gelir.Bunu tek başına bırakırsanız, Dingding istisna bildirimi ve e-posta istisna bildirimi aynı istisnayı tekrar tekrar alacaktır, bu nedenle Gönderme sıklığını sınırlamak için varsayılan olarak bir yöntemdeki bir istisnanın bildirilmesi gerekir, bu nedenle bu bildirim yalnızca günde bir kez görünecektir. Elbette bu da sorunlara neden olabilir E-posta veya Dingding mesajı alınmazsa, bildirimin gözden kaçması muhtemeldir, bu nedenle burada bir bildirim stratejisi oluşturulur.

    • Bildirim stratejisine karşılık gelen yapılandırma sınıfı ExceptionNoticeFrequencyStrategy'dir. Stratejiyi etkinleştirmek için application.properties dosyasında aşağıdaki yapılandırmayı eklemeniz gerekir.
    exceptionnotice.strategy.enabled = true
    • Şu anda iki bildirim stratejisi var
    • Zaman stratejisi
    • Ortaya çıkma sıklığı stratejisi İlgili yapılandırma şudur:
    exceptionnotice.strategy.frequency-type = timeout / showcount
    • Zaman stratejisine karşılık gelen yapılandırma öğesi, exceptionnotice.strategy.notice-time-interval'dir ve tür, süre'dir; bu, son bildirim zamanından bu yana yapılandırılan süre geçtikten sonra tekrar bildirileceği anlamına gelir.
    • Sıklık stratejisine karşılık gelen konfigürasyon öğesi, exceptionnotice.strategy.notice-show-count şeklindedir; bu, son bildirimden bu yana, oluşumların sayısı konfigürasyon testlerinin sayısını aştıktan sonra tekrar bildirileceği anlamına gelir.

    Temel olarak, yukarıdaki stratejiyi kullanmak yeterlidir, daha iyi bir yapılandırma stratejisi varsa benimle iletişime geçebilirsiniz

    Dış yardım yapılandırması

    Şu anda dış yardım konfigürasyonuna ihtiyaç duyan bilgiler şu şekildedir, aslında yukarıda da bahsedilmektedir.

  • Redis depolamayı etkinleştirmek için, pom.xml dosyasına aşağıdaki bağımlılıkları eklemeniz gerekir
  • < bağımlılık > < Grup kimliği > org.springframework.boot < /Grup kimliği > < artifactId > Spring-boot-starter-data-redis < / artifactId > < /bağımlılık >

    Bağımlılıkları ekledikten sonra, redis'i yapılandırmaya başlamanız gerekir

    bahar: redis: ana bilgisayar: 127.0.0.1 bağlantı noktası: 6379 veritabanı: 0 şifre: şifre
  • Bir e-posta bildirimi varsa, pom.xml'ye aşağıdaki bağımlılıkları eklemeniz gerekir
  • < bağımlılık > < Grup kimliği > org.springframework.boot < /Grup kimliği > < artifactId > Spring-boot-starter-mail < / artifactId > < /bağımlılık >

    Bağımlılıkları ekledikten sonra, e-posta bilgilerini yapılandırmaya başlayın

    bahar: posta: host: smtp.xxx.com bağlantı noktası: 25 kullanıcı adı: smtp izni etkinleştirilmiş posta kutusu kullanıcı adı şifre: şifre
  • Web-mvc modunu açarsanız, bilmiyorsunuz bile, kesinlikle aşağıdaki bağımlılıkları tanıtacaksınız:
  • < bağımlılık > < Grup kimliği > org.springframework.boot < /Grup kimliği > < artifactId > Spring-boot-starter-web < / artifactId > < /bağımlılık >

    açıklama

    • Yukarıda bahsedilen yapılandırma aslında bu açıklamaya hizmet eder.Çerçevedeki tek açıklama @ExceptionListener'dir. Bu açıklamanın istisna bildirimi gerektiren herhangi bir sınıfa veya yönteme eklenmesi gerektiğine dikkat edilmelidir.
    • Exceptionnotice.listen-type yapılandırma türüne göre, yapılandırma bilgi notunun konumu da farklıdır.
    • Exceptionnotice.listen-type = common olduğunda, @ExceptionListener herhangi bir sınıfa ve herhangi bir yönteme eklenebilir
    • Exceptionnotice.listen-type = web-mvc olduğunda, @ExceptionListener yalnızca Controller katmanına eklenebilir, yani @Controller veya @RestController ile sınıf veya yöntem ve ilgili @ RequestMapping ile ilgili ek açıklamalar da yöntemde gereklidir.

    Bağlantı adresini almak, isterseniz takip etmek ve birlikte yeni teknolojileri öğrenmek ve keşfetmek için özel bir mesajla "prometheus" a yanıt verin.

    Çok seviyeli önbellek çözümü (TMC)
    önceki
    Genel jar, dinamik konfigürasyon ve bileşen düzenlemesine dayalı üye görev merkezi sistemi tasarımı
    Sonraki
    api izleme sistemi - apimonitor
    Bir dahaki sefere öldürüldüğümde, serialVersionUID'yi gelişigüzel değiştirmeye cesaret edemeyeceğim
    Düşük kodlu hızlı geliştirme platformu JEPaaS
    Tam bağlantı izleme: çözüme genel bakış ve karşılaştırma | gerçekten kuru
    hanbo-push dağıtılmış mesaj push, IM servisi
    Ali Great God, mikro hizmet mimarisindeki API ağ geçidi uygulamasını paylaşıyor
    mallcloud-platform, springboot bulutuna dayalı bir alışveriş merkezi projesidir
    MyBatis bu 9 tasarım modelini içerir, kaç tanesini biliyorsunuz?
    Hurricane Sheep Knife Ashe için standart hale geldi, Polar Ranger Genting'e hükmediyor
    Çift sunucu beş güçlü en iyi tek envanter: Nuoshou Jianji güçlü bir şekilde hakim
    Her şeye gücü yeten kan emici teknoloji silahı ana akım haline geldi ve ejderha kızın dul eşi bir kaplan gibi
    9.18 National Service Tüm Kahramanlar TOP5 oranını kazanır, iki AP ormancısı hakimdir
    To Top