Yazılım sistemlerinin endüstriyel gelişimi, son ürünün hata toleransına büyük önem verilmesinin yanı sıra, arızalara ve arızaların meydana gelmesi durumunda hızlı tepki verilmesini gerektirir. İzleme elbette arızalara ve arızalara daha verimli ve hızlı bir şekilde müdahale edilmesine yardımcı olur, ancak yeterli değildir. Öncelikle çok sayıda sunucuyu takip etmek çok zordur; çok sayıda insana ihtiyaç vardır. İkinci olarak, uygulamanın durumunu tahmin edebilmek için uygulamanın nasıl çalıştığını iyi anlamanız gerekir. Bu nedenle geliştirdiğimiz sistemleri, performanslarını ve özelliklerini iyi anlayan çok sayıda insana ihtiyacımız var. Bunu yapmaya istekli yeterince insan bulsanız bile onları eğitmenin hala çok zaman aldığını varsayalım.
Ne yapalım? Yapay zekanın yardımımıza geldiği yer burasıdır. Makale hakkında konuşacak
Giriş
Geliştirilen yazılım sistemi er ya da geç faaliyete geçer. Sistemin hatasız çalışması kullanıcı açısından önemlidir. Acil bir durum ortaya çıkarsa, minimum gecikmeyle çözülmelidir.
Bir yazılım sisteminin teknik desteğini basitleştirmek için, özellikle de çok sayıda sunucu varsa, genellikle çalışan bir yazılım sisteminden ölçümler alan, durumunu teşhis etmeyi mümkün kılan ve arızaya tam olarak neyin sebep olduğunu belirlemeye yardımcı olan izleme programları kullanılır. Bu işleme yazılım sistemi izleme adı verilir.
Şekil 1. Grafana izleme arayüzü
Metrikler, bir yazılım sisteminin, yürütme ortamının veya sistemin çalıştığı fiziksel bilgisayarın, metriklerin alındığı anın zaman damgasıyla birlikte çeşitli göstergeleridir. Statik analizde bu metriklere zaman serisi adı verilir. Yazılım sisteminin durumunu izlemek için ölçümler grafikler biçiminde görüntülenir: zaman X eksenindedir ve değerler Y eksenindedir (Şekil 1). Çalışan bir yazılım sisteminden (her düğümden) birkaç bin ölçüm alınabilir. Bir metrik uzayı (çok boyutlu zaman serileri) oluştururlar.
Karmaşık yazılım sistemleri için çok sayıda ölçüm toplandığından, manuel izleme zor bir iş haline gelir. Yönetici tarafından analiz edilen veri miktarını azaltmak için izleme araçları, olası sorunları otomatik olarak belirleyecek araçlar içerir. Örneğin, boş disk alanı belirli bir eşiğin altına düştüğünde tetiklenecek bir tetikleyici yapılandırabilirsiniz. Ayrıca sunucu kapanmasını veya hizmet hızındaki kritik yavaşlamayı otomatik olarak teşhis edebilirsiniz. Uygulamada, izleme araçları halihazırda meydana gelen arızaları tespit etme veya gelecekteki arızaların basit semptomlarını belirleme konusunda iyi bir iş çıkarır, ancak genel olarak olası bir arızayı tahmin etmek, onlar için çözülmesi zor bir ceviz olmaya devam etmektedir. Metriklerin manuel analizi yoluyla tahmin, nitelikli uzmanların katılımını gerektirir. Düşük verimliliktir. Olası başarısızlıkların çoğu gözden kaçabilir.
Son zamanlarda, yazılım sistemlerinin tahmine dayalı bakımı, büyük BT yazılım geliştirme şirketleri arasında giderek daha popüler hale geldi. Bu yaklaşımın özü, yapay zekayı kullanarak sistem bozulmasına yol açan sorunları erken aşamalarda, başarısızlıkla sonuçlanmadan önce bulmaktır. Bu yaklaşım, sistemin manuel olarak izlenmesini tamamen dışlamaz. Bir bütün olarak izleme sürecine yardımcıdır.
Kestirimci bakımı uygulamanın ana aracı, zaman serilerindeki anormallikleri arama görevidir, çünkü bir anormallik oluştuğunda verilerde bir süre sonra yüksek bir olasılık var bir başarısızlık veya başarısızlık olacak. Anormallik, bir yazılım sisteminin performansındaki belirli bir sapmadır; örneğin, bir tür isteğin yürütme hızındaki bozulmanın belirlenmesi veya sabit bir müşteri oturumu düzeyinde hizmet verilen isteklerin ortalama sayısındaki azalma.
Yazılım sistemleri için anormallikleri arama görevinin kendine has özellikleri vardır. Teorik olarak, her yazılım sistemi için mevcut yöntemlerin geliştirilmesi veya iyileştirilmesi gerekir, çünkü anormalliklerin araştırılması, gerçekleştirildiği verilere büyük ölçüde bağlıdır ve yazılım sistemlerinin verileri, sistemi uygulamaya yönelik araçlara bağlı olarak büyük ölçüde farklılık gösterir. , hangi bilgisayarda çalıştığına bağlı.
Yazılım sistemlerinin arızalarını tahmin ederken anormallikleri arama yöntemleri
Her şeyden önce, başarısızlıkları tahmin etme fikrinin makaleden ilham aldığını söylemekte fayda var.
Tüm metrikler sistemden grafit kullanılarak alınır. Başlangıçta, fısıltı veritabanı grafana için standart bir çözüm olarak kullanıldı, ancak müşteri tabanı büyüdükçe grafit, DC disk alt sisteminin kapasitesini tükettiğinden artık başa çıkamadı. Bundan sonra daha etkili bir çözüm bulunmasına karar verildi. Seçim lehine yapıldı
Şekil 2. Metrik toplama şeması
Diyagram dahili belgelerden alınmıştır. Grafana (kullandığımız izleme arayüzü) ile grafit arasındaki iletişimi gösterir. Bir uygulamadan metriklerin kaldırılması ayrı bir yazılım tarafından gerçekleştirilir -
Web Konsolidasyon sistemi, arızaların tahmin edilmesinde sorun yaratan bir dizi özelliğe sahiptir:
- Trend sıklıkla değişiyor. Bu yazılım sistemi için çeşitli versiyonlar mevcuttur. Her biri sistemin yazılım kısmında değişiklikler getirir. Buna göre geliştiriciler bu şekilde belirli bir sistemin metriklerini doğrudan etkileyerek bir trend değişikliğine neden olabilirler;
- uygulama özelliği ve müşterilerin bu sistemi kullanma amaçları, genellikle önceden bozulma olmaksızın anormalliklere neden olur;
- tüm veri setine göre anormalliklerin yüzdesi küçüktür (< %5);
- Göstergelerin sistemden alınmasında boşluklar olabilir. Bazı kısa sürelerde izleme sistemi ölçümleri elde etmekte başarısız olur. Örneğin, sunucu aşırı yüklenmişse. Bu, bir sinir ağının eğitimi için kritik öneme sahiptir. Boşlukların sentetik olarak doldurulmasına ihtiyaç vardır;
- Anormalliklerin olduğu vakalar genellikle yalnızca belirli bir tarih/ay/saat (mevsimsellik) ile ilgilidir. Bu sistemin kullanıcılar tarafından kullanımına ilişkin açık düzenlemeler bulunmaktadır. Buna göre metrikler yalnızca belirli bir süre için geçerlidir. Sistem sürekli olarak kullanılamaz, ancak yalnızca birkaç ayda kullanılabilir: yıla bağlı olarak seçici olarak. Bir durumda metriklerin aynı davranışının yazılım sisteminin arızasına yol açabileceği, ancak diğerinde aynı durumun söz konusu olamayacağı durumlar ortaya çıkar.
Başlangıç olarak, yazılım sistemlerine ait verilerin izlenmesindeki anormallikleri tespit etmeye yönelik yöntemler analiz edildi. Bu konuyla ilgili makalelerde, anormalliklerin yüzdesi veri setinin geri kalanına göre küçük olduğunda, çoğunlukla sinir ağlarının kullanılması önerilmektedir.
Sinir ağı verilerini kullanarak anormallikleri aramanın temel mantığı Şekil 3'te gösterilmektedir:
Şekil 3. Sinir ağını kullanarak anormallikleri arama
Mevcut ölçüm akışı penceresinin tahmini veya restorasyonu sonucuna dayanarak, çalışan yazılım sisteminden alınan sapma hesaplanır. Yazılım sisteminden ve sinir ağından elde edilen metrikler arasında büyük bir fark varsa mevcut veri segmentinin anormal olduğu sonucuna varabiliriz. Sinir ağlarının kullanımında aşağıdaki sorunlar dizisi ortaya çıkar:
- Akış modunda doğru şekilde çalışmak için, sinir ağı modellerini eğitmeye yönelik veriler yalnızca "normal" verileri içermelidir;
- Doğru tespit için güncel bir modele sahip olmak gerekir. Metriklerdeki değişen trendler ve mevsimsellik, modelde çok sayıda hatalı pozitif sonuca neden olabilir. Güncellemek için modelin güncel olmadığı zamanı açıkça belirlemek gerekir. Modeli daha sonra veya daha erken güncellerseniz, büyük olasılıkla çok sayıda yanlış pozitif sonuç gelecektir.
Yanlış pozitiflerin sıklıkla ortaya çıkmasını araştırmayı ve önlemeyi de unutmamalıyız. Bunların çoğunlukla acil durumlarda ortaya çıkacağı varsayılmaktadır. Ancak yetersiz eğitimden kaynaklanan bir sinir ağı hatasının sonucu da olabilirler. Modelin yanlış pozitif sayısını en aza indirmek gerekir. Aksi takdirde, yanlış tahminler, sistemi kontrol etmek için yöneticinin çok fazla zamanını boşa harcayacaktır. Er ya da geç yönetici "paranoyak" izleme sistemine yanıt vermeyi bırakacaktır.
Tekrarlayan sinir ağı
Zaman serilerindeki anormallikleri tespit etmek için şunları kullanabilirsiniz:
Şekil 4. LSTM bellek hücrelerine sahip tekrarlayan bir sinir ağı örneği
Şekil 4'ten görülebileceği gibi RNN LSTM bu zaman diliminde anormallik arayışıyla başa çıkabilmiştir. Sonucun yüksek tahmin hatasına (ortalama hata) sahip olduğu durumlarda, göstergelerde gerçekte bir anormallik meydana gelmiştir. Tek bir RNN LSTM kullanmak, az sayıda metrik için geçerli olduğundan açıkça yeterli olmayacaktır. Anormallikleri araştırmak için yardımcı bir yöntem olarak kullanılabilir.
Arıza tahmini için otomatik kodlayıcı
Şekil 5. Otomatik kodlayıcı işlemi örneği
Otomatik kodlayıcılar normal veriler üzerinde eğitilir ve ardından modele beslenen verilerde anormal bir şey bulur. Tam da bu görev için ihtiyacınız olan şey. Geriye kalan tek şey bu göreve hangi otomatik kodlayıcının uygun olduğunu seçmektir. Otomatik kodlayıcının mimari açıdan en basit biçimi, ileri geri dönmeyen bir sinir ağıdır.
Bununla birlikte, otomatik kodlayıcılar ile MLP'ler arasındaki farklar, bir otomatik kodlayıcıda çıktı katmanının giriş katmanıyla aynı sayıda düğüme sahip olması ve bir X girişi tarafından verilen Y hedef değerini tahmin etmek üzere eğitilmek yerine otomatik kodlayıcının eğitilmiş olmasıdır. kendi X'lerini yeniden yapılandırmak için Otomatik Kodlayıcılar denetimsiz öğrenme modelleridir.
Otomatik kodlayıcının görevi, X giriş vektöründeki anormal öğelere karşılık gelen r0 ... rn zaman endekslerini bulmaktır. Bu etki, hatanın karesi aranarak elde edilir.
Şekil 6. Senkron otomatik kodlayıcı
Otomatik kodlayıcı için seçildi
Yanlış pozitifleri en aza indirme mekanizması
Geliştirilmekte olan anormallik tespit modeli için, çeşitli anormal durumların ortaya çıkması ve sinir ağının yetersiz eğitiminin muhtemel olması nedeniyle, yanlış pozitifleri en aza indirecek bir mekanizma geliştirilmesinin gerekli olduğuna karar verilmiştir. Bu mekanizma, yönetici tarafından sınıflandırılan bir şablon tabanına dayanmaktadır.
Yanlış pozitifleri en aza indirmenin temel prensibi, sinir ağları kullanılarak tespit edilen şüpheli vakaları sınıflandıran bir operatörün yardımıyla standartlardan oluşan bir veri tabanı toplamaktır. Daha sonra sınıflandırılan standart, sistemin tespit ettiği durumla karşılaştırılarak, durumun yanlış mı yoksa arızaya mı yol açtığı konusunda bir sonuca varılır. DTW algoritması tam olarak iki zaman serisini karşılaştırmak için kullanılır. Ana minimizasyon aracı hala sınıflandırmadır. Çok sayıda referans vaka toplandıktan sonra, çoğu vakanın benzerliği ve benzer vakaların ortaya çıkması nedeniyle sistemin operatöre daha az soru sormaya başlaması bekleniyor.
Sonuç olarak, yukarıda açıklanan sinir ağı yöntemlerine dayanarak, “Web-Konsolidasyon” sisteminin arızalarını tahmin etmek için deneysel bir program oluşturuldu. Bu programın amacı, mevcut izleme verileri arşivini ve önceki arızalarla ilgili bilgileri kullanarak, bu yaklaşımın yazılım sistemlerimiz için yeterliliğini değerlendirmekti. Programın şeması aşağıda Şekil 7'de sunulmaktadır.
Şekil 7. Metrik alan analizine dayalı arıza tahmin şeması
Diyagramda iki ana blok ayırt edilebilir: izleme veri akışında (metrikler) anormal zaman aralıklarının aranması ve yanlış pozitifleri en aza indirme mekanizması. Not: Deneysel amaçlar için veriler, grafitin kaydedeceği veritabanından JDBC bağlantısı aracılığıyla elde edilir.
Geliştirme sonucunda elde edilen izleme sisteminin arayüzü aşağıdadır (Şekil 8).
Şekil 8. Deneysel izleme sisteminin arayüzü
Arayüz, alınan ölçümlere göre anormallik yüzdesini görüntüler. Bizim durumumuzda makbuz simüle edilmiştir. Birkaç haftadır tüm verilere sahibiz ve arızaya yol açan bir anormallik durumunu kontrol etmek için bunları yavaş yavaş yüklüyoruz. Alttaki durum çubuğu, bir otomatik kodlayıcı kullanılarak belirlenen belirli bir zamandaki veri anormalliğinin genel yüzdesini görüntüler. Ayrıca, tahmin edilen metrikler için RNN LSTM tarafından hesaplanan ayrı bir yüzde görüntülenir.
RNN LSTM sinir ağını kullanan CPU performansına dayalı bir anormallik algılama örneği (Şekil 9).
Şekil 9. RNN LSTM keşfi
Aslında sıradan bir aykırı değer olan ancak sistem arızasına yol açan oldukça basit bir durum, RNN LSTM kullanılarak başarıyla hesaplandı. Bu zaman dilimindeki anormallik göstergesi %85-95'tir; %80'in üzerindeki her şey (eşik deneysel olarak belirlenmiştir) anormallik olarak kabul edilir.
Bir güncellemeden sonra sistem önyükleme yapamadığında ortaya çıkan anormallik tespitine bir örnek. Bu durum otomatik kodlayıcı tarafından tespit edilir (Şekil 10).
Şekil 10. Otomatik kodlayıcı algılama örneği
Şekilden de görebileceğiniz gibi PermGen bir seviyede sıkışmış durumda. Otomatik kodlayıcı bunu garip buldu çünkü daha önce hiç böyle bir şey görmemişti. Burada anormallik, sistem çalışma durumuna dönene kadar %100 olarak kalır. Tüm metrikler için bir anormallik görüntüleniyor. Daha önce de belirtildiği gibi, otomatik kodlayıcı anormalliklerin yerini belirleyemez. Operatörün bu durumlarda bu işlevi yerine getirmesi istenir.
Sonuç
PC "Web Konsolidasyonu" birkaç yıldır geliştirilmektedir. Sistem oldukça istikrarlı bir durumda ve kaydedilen olayların sayısı az. Ancak arızanın meydana gelmesinden 5 – 10 dakika önce arızaya yol açan anormallikleri bulmak mümkündü. Bazı durumlarda, bir arızanın önceden bildirilmesi, “onarım” işinin yürütülmesi için ayrılan planlı süreden tasarruf edilmesine yardımcı olabilir.
Gerçekleştirilen deneylere dayanarak nihai sonuçlara varmak için henüz çok erken. Şu ana kadar sonuçlar çelişkili. Bir yandan, sinir ağlarına dayalı algoritmaların "yararlı" anormallikleri bulma yeteneğine sahip olduğu açıktır. Öte yandan, yanlış pozitiflerin büyük bir yüzdesi mevcut ve bir sinir ağında kalifiye bir uzman tarafından tespit edilen tüm anormallikler tespit edilemiyor. Dezavantajları arasında artık sinir ağının normal çalışma için bir öğretmenden eğitim gerektirmesi yer alıyor.
Arıza tahmin sistemini daha da geliştirmek ve onu tatmin edici bir duruma getirmek için çeşitli yollar öngörülebilir. Bu, sistemin durumunu büyük ölçüde etkileyen önemli metriklerin listesine eklenmesi ve onu etkilemeyen gereksiz olanların atılması nedeniyle başarısızlığa yol açan anormalliklerin olduğu durumların daha ayrıntılı bir analizidir. Ayrıca bu yönde hareket edersek, algoritmaları arızalara yol açan anormalliklerin olduğu durumlarımıza özel olarak özelleştirmek için girişimlerde bulunabiliriz. Başka bir yol daha var. Bu, sinir ağı mimarilerinde bir gelişmedir ve dolayısıyla eğitim süresinde bir azalma ile algılama doğruluğunu arttırır.
Bu makaleyi yazmamda ve güncelliğini korumamda bana yardımcı olan meslektaşlarıma şükranlarımı sunuyorum:
Kaynak: habr.com