Sistem yöneticileri tarafından yaygın olarak kullanılan 5 alarm ve görselleştirme aracı
Bu açık kaynaklı araçlar, kullanıcıların sistem davranışını ve çıktılarını anlamalarına yardımcı olur ve olası sorunlar için uyarılar sağlar.
Uyarıları ve görselleştirme araçlarını kullanabilirsiniz, özellikle bazı sistemler bir özellik olarak görselleştirmeyi kullandığında, bunları neden gözlemlenebilirlik araçları olarak tartışmalıyım?
Gözlemlenebilirlik, kontrol teorisinden gelir ve sistemi girdi ve çıktılarına göre anlama yeteneğimizi tanımlar. Bu makale, gözlemlenebilirliğin çıktı bileşenlerine odaklanmaktadır.
Alarmlar ve görselleştirme araçları, sistemin çıktısını analiz eder ve bu çıktıların yapılandırılmış bir sunumunu sağlar. Alarmlar, temelde, olumsuz sistem çıktısının kapsamlı bir anlayışıdır ve görselleştirme, kullanıcının anlayışını ortadan kaldıran, belirsizliği gidermenin yapılandırılmış bir temsilidir.
1. Yaygın alarmlar ve görselleştirme türleri
alarm
Önce neyin alarm olmadığını tanıtalım. İnsan müdahaleci sorunla ilgili herhangi bir işlem yapamazsa, uyarı gönderilmemelidir. Bu, birden fazla kişiye gönderilen alarmları içerir, yalnızca birkaç kişi yanıt verebilir veya sistemdeki her anormallik bir alarmı tetikler. Bu, alarm yorgunluğuna neden olur ve alıcı, sistem henüz doymamış bir ortama yükseltilene kadar belirli bir ortamdaki tüm alarmları yok sayar.
Örneğin, O&M alarm sisteminden her gün yüzlerce e-posta alırsa, O&M alarm sisteminden gelen tüm e-postaları hızla yok sayar. Yalnızca bir sorunla karşılaştığında, müşteri bir e-posta gönderir veya patron arar, operasyon ve bakım gerçek olaya cevap verir. Bu durumda alarm anlamını ve amacını yitirmiştir.
Alarmlar, sürekli bir bilgi akışı veya durum güncellemeleri değildir. Sistemin otomatik olarak düzeltemeyeceği sorunları iletmek için tasarlanmıştır ve yalnızca sistemi kurtarma olasılığı en yüksek olan kişilere gönderilir. Bu tanımın dışındaki her şey bir uyarı değildir ve yalnızca çalışanlara ve şirket kültürüne zarar verir.
Herkesin farklı uyarı türleri vardır, bu nedenle öncelikleri (P1-P5) veya "bilgi", "uyarı" ve "kritik" sözcüklerini kullanan modelleri tartışmayacağım. Bunun yerine, karmaşık sistemlerin olay yanıtında görünen genel kategorileri tanımlayacağım.
"Bilgilendirici" bir uyarı türünden bahsettiğimi fark etmiş olabilirsiniz. Uyarılar bilgi amaçlı olmamalıdır. Eh, herkes aynı fikirde değil, ama kimseye gönderilmezse, bunu bir uyarı olarak görmem. Birçok sistemin alarm çağırdığı bir veri noktasıdır. Bilinmesi gereken ancak yanıt verilmeyen olayları temsil eder. Gerçek bildirimi tetikleyen olaydan ziyade genellikle uyarı aracının görselleştirme sisteminin bir parçasıdır. Mike Julian bunu ve uyarmanın diğer yönlerini "Pratik İzleme" kitabında ele alıyor. Bu, bu alanda çalışmak için okunması gereken bir kitaptır.
Bilgi içermeyen alarmlar, yanıt verebilecek veya eylemler gerektirebilecek türlerden oluşur. Bunları iki kategoriye ayırıyorum: dahili kesintiler ve harici kesintiler. (Çoğu şirketin yanıt çalışmalarının önceliğini belirlemek için ikiden fazla düzeyi vardır.) Her kullanıcı üzerindeki etki genellikle bilinmediğinden, sistem performansındaki düşüş bu modelin bir kesintisi olarak kabul edilir.
Dahili kesmenin önceliği, harici kesmeden daha düşüktür, ancak yine de hızlı bir tepkiye ihtiyaç duyar. Genellikle şirket çalışanları tarafından kullanılan dahili sistemleri veya yalnızca şirket çalışanlarının görebildiği uygulama bileşenlerini içerirler.
Dış kesintiler, müşterileri anında etkileyecek tüm sistem kesintilerini içerir. Bunlar, sistem güncellemelerinin yayınlanmasını engelleyen sistem kesintilerini içermez. Müşteriye dönük uygulama arızalarını, veritabanı kesintilerini ve ağ bölümlerini içerir. Bunların her ikisi de kullanıcıları etkileyebilirse, kullanılabilirlik veya tutarlılıktan ödün verebilirler. Ayrıca, uygulama çalışmaya devam ettiği için kullanıcılar üzerinde doğrudan etkisi olmayabilecek araç kesintilerini de içerir, ancak bu şeffaf bağımlılık performansı etkileyebilir. Bu, sistem tam işlevsellik için gerekli olmayan belirli harici hizmetleri veya veri kaynaklarını kullandığında yaygındır, ancak uygulama bu dış bağımlılıktan gelen hataları yeniden denediğinde veya işlediğinde gecikmelere neden olabilir.
Görselleştirme
Pek çok görselleştirme türü var ve hepsini burada ele almayacağım. Bu büyüleyici bir araştırma alanı. Kariyerimdeki veri analizi açısından, bu bilgiyi öğrenmek ve uygulamak devam eden bir zorluktur. Bilgiyi en geniş şekilde yaymak için karmaşık sistemlerin çıktılarının basit bir temsilini sağlamalıyız. Google Charts ve Tableau, çeşitli görselleştirme türleri sağlar. Sistemi hızlı bir şekilde anlamak için en yaygın görselleştirmeleri ve bazı yenilikçi çözümleri tanıtacağız.
çizgi grafik
Çizgi grafik muhtemelen görselleştirmenin en yaygın yoludur. Zamanla sistemi iyi anlayabilir. Ölçüm sistemindeki çizgi grafik, her benzersiz metrik veya belirli metriklerin toplamı için bir çizgi sağlayacaktır. Aynı panoda çok sayıda gösterge olduğunda bu kafa karıştırıcı olabilir (aşağıdaki resimde gösterildiği gibi), ancak çoğu sistem tüm göstergeleri görünür hale getirmek yerine görüntülemek için belirli göstergeleri seçebilir. Ek olarak, anormal davranış, normal çalışmanın gürültüsünden kaçmak için yeterliyse, anormal davranışı tespit etmek kolaydır. Aşağıda anormal davranışları gösterebilecek mor, sarı ve açık mavi çizgiler görebiliriz.
Çizgi grafiklerin bir başka özelliği de ilişkileri göstermek için sıklıkla yığılabilmeleridir. Örneğin, her bir sunucudaki istekleri ayrı ayrı görüntülemek isteyebilirsiniz, ancak bunları toplu olarak da görüntüleyebilirsiniz. Bu, tüm sistemi ve her örneği aynı diyagramda anlamanıza olanak tanır.
Sıcaklık haritası
Diğer bir yaygın görselleştirme, ısı haritasıdır. Histogramları görüntülerken kullanışlıdır. Bu tür bir görselleştirme, bir çubuk grafiğe benzer, ancak genel metriğin farklı yüzdelik dilimlerini temsil eden degradeleri görüntüleyebilir. Örneğin, istek gecikmesine baktığınızı ve tüm isteklerin genel eğilimini ve dağılımını hızlı bir şekilde anlamak istediğinizi varsayalım. Isı haritası bunun için çok kullanışlıdır, her bir parçanın numarasına hızlıca göz atmak için rengi kullanabilir.
Aşağıdaki ısı haritası, grafiğin merkez çizgisi etrafındaki daha yüksek konsantrasyonu gösterir ve her zaman periyodunun dikey dağılımı kolayca anlaşılabilir. Zaman içinde dağılımın genişlediği birkaç noktaya bakmak isteyebiliriz, zaman içindeki diğer noktalar ise 14: 00'da oldukça gergindir. Bu dağılım olumsuz bir performans göstergesi olabilir.
Basınç ölçer
Burada tanıtacağım son yaygın görselleştirme, kullanıcıların tek bir göstergeyi hızlı bir şekilde anlamalarına yardımcı olabilecek bir ölçüm cihazıdır. Sayaç, sürüş hızını temsil eden bir hız göstergesi veya arabadaki benzin miktarını temsil eden bir benzin göstergesi gibi tek bir göstergeyi temsil edebilir. Gaz sayaçlarına benzer şekilde, çoğu izleme cihazı neyin iyi neyin olmadığını açıkça gösterir. Genellikle (aşağıdaki şekilde gösterildiği gibi), yeşilin temsil edilmesi kolaydır, turuncu zayıf bir şekilde temsil edilir ve kırmızı "her şey bozuk" anlamına gelir. Alt orta sıra geleneksel sayacı gösterir.
Bu görüntü, geleneksel sayaçlardan daha fazlasını göstermektedir. Diğer sayaçlar, klasik sayaçların işlevlerine benzer şekilde tek bir istatistiksel gösterimdir. Hepsi aynı renk şemasını kullanır ve sistem sağlığını bir bakışta hızlı bir şekilde gösterebilir. Alt sıranın muhtemelen gösterge tablosuna göz atmanıza ve her şeyin sağlıklı (veya değil) olduğunu bilmenize izin veren en iyi örnek olduğu söylenebilir. Bu tür bir görselleştirme, genellikle en üst düzey kontrol paneline koyduğum şeydir. Birkaç saniye içinde kapsamlı ve üst düzey bir sistem çalışma durumu anlayışı elde edebilir.
Alev grafiği
Daha az yaygın bir görselleştirme, 2011'de Netflix'ten Brendan Gregg tarafından tanıtılan alev grafiğidir. Gösterge panoları için veya gelişmiş sistem sorunlarını hızla gözlemlemek için ideal değildir. Genellikle belirli bir uygulama problemini anlamaya çalışırken görülür. Bu görselleştirme, CPU ve bellek ile ilişkili çerçevelere odaklanır. X ekseni, kareleri alfabetik sırada listeler ve Y ekseni yığın derinliğini gösterir. Her dikdörtgen, çağrılan işlevi içeren bir yığın çerçevesidir. Dikdörtgen ne kadar genişse, yığında o kadar çok görünür. Bu yöntem, sistem performansını uygulama düzeyinde teşhis etmeye çalışırken çok kullanışlıdır ve denemenizi öneririm.
Araç seçimi
Alarm vermek için birkaç ticari seçenek var, ancak burası Açık Kaynak.com olduğundan, yalnızca gerçek şirketler tarafından ücretsiz olarak kullanılabilen büyük ölçekte kullanılan sistemleri ele alacağım. Bu sistemleri daha iyi hale getirmek için yeni ve yenilikçi özelliklere katkıda bulunabileceğinizi umuyoruz.
İki, uyarı aracı
1. Bosun
Daha önce bir bilgisayarla herhangi bir şey yaptıysanız ve takıldıysanız, aldığınız yardım Stack Exchange sistemine atfedilebilir. Stack Exchange, kitle kaynaklı Soru-Cevap modeli etrafında birçok farklı web sitesi çalıştırır. Stack Overflow, geliştiriciler arasında çok popülerdir ve süper kullanıcılar operasyonlarda çok popülerdir. Bununla birlikte, ebeveynlikten bilim kurguya, felsefeden bisiklete kadar değişen yüzlerce web sitesi var.
Stack Exchange açık kaynaklı uyarı yönetim sistemi Bosun ve Prometheus ve AlertManager sistemi de piyasaya sürüldü. Bu iki sistemin pek çok benzerliği var ve bu çok iyi bir şey. Prometheus gibi, Bosun da Golang ile yazılmıştır. Bosun, Prometheus'tan daha geniş bir kapsama sahiptir çünkü gösterge birleştirme dışındaki sistemlerle etkileşime girebilir. Ayrıca, günlük ve olay toplama sistemlerinden veri alabilir. Graphite, InfluxDB, OpenTSDB ve Elasticsearch'ü destekler.
Bosun'un mimarisi, bir sunucu ikili dosyası, OpenTSDB, Redis ve scollector aracıları gibi bir arka uçtan oluşur. Gözetleyici aracı, ana bilgisayardaki hizmetleri otomatik olarak algılar ve bu süreçler ve diğer sistem kaynakları için ölçümleri rapor eder. Bu veriler, gösterge arka ucuna gönderilecektir. Bosun sunucusu ikili daha sonra herhangi bir alarmın tetiklenmesi gerekip gerekmediğini belirlemek için arka ucu sorgular. Bosun, Grafana gibi araçlar tarafından ortak bir arayüz aracılığıyla temeldeki arka ucu sorgulamak için de kullanılabilir. Redis, Bosun'un durumunu ve meta verilerini depolamak için kullanılır.
Bosun'un çok akıllıca bir özelliği, alarmları geçmiş verilere dayalı olarak test edebilmesidir. Bu, birkaç yıl önce Prometheus'ta sorunlu bir veriye sahip olduğumda ve bir uyarı istediğimde gözden kaçırdığım bir şeydi, ancak bunu test etmenin kolay bir yolu yoktu. Alarmlarımın normal olmasını sağlamak için sahte veriler oluşturmalı ve eklemeliyim. Bu sistem, çok zaman alan bir süreci hafifletir.
Bosun ayrıca basit grafikler görüntüleme ve alarm oluşturma gibi olağan işlevlere de sahiptir. Güçlü bir ifade diline sahiptir ve uyarı kuralları yazmak için kullanılabilir. Ancak, yalnızca e-posta ve HTTP bildirim yapılandırmasına sahiptir, bu da Slack'e ve diğer araçlara bağlanmanın daha fazla özelleştirme gerektirdiği anlamına gelir (belgelerinde kapsanmaktadır). Prometheus'a benzer şekilde, Bosun bu bildirimler için şablonlar kullanabilir, bu da istediğiniz gibi harika görünebilecekleri anlamına gelir. Birinin gördüğü en kötü e-posta hatırlatıcısını oluşturmak için tüm HTML ve CSS becerilerinizi kullanabilirsiniz.
2. kabot
Cabot, Arachnys adlı bir şirket tarafından yaratıldı. Arachnys'in kim olduğunu veya ne yaptığını bilmiyor olabilirsiniz, ancak etkisini şimdiden hissedebilirsiniz: finansal suçlara karşı bulut tabanlı lider bir çözüm oluşturur. Kulağa hoş geliyor, değil mi? Önceki şirketimde, "Müşterini Tanı" yasasının benzer bir işlevine katıldım. Çoğu şirket, terör örgütleriyle iletişim kurmanın, örneğin sistemleri aracılığıyla fonları birleştirmenin çok kötü bir şey olduğunu düşünüyor. Bu çözümler aynı zamanda dolandırıcılara karşı daha az acımasız olan suçluların önlenmesine yardımcı olur ve ayrıca kurum için risk oluşturabilir.
Arachnys neden abot yarattı? Bu herkes için bir Noel hediyesi, çünkü bu bir Noel projesi, çünkü geliştiricileri Nagios'u çevreleyemez. Gerçekten, onları kim suçlayabilir? Cabot, Django ve Bootstrap ile yazılmıştır, bu nedenle çoğu insanın projeye katkıda bulunması kolay olmalıdır. (Bir başka ilginç gerçek: isim, yaratıcının köpeğinden geliyor.)
Cabot mimarisi, veri toplamaması açısından Bosun'a benzer. Bunun yerine, verilere, uyarı aracının API'si aracılığıyla erişir. Bu nedenle Cabot, uyarı için bir çekme (itme yerine) modeli kullanır. Her sistemin API'sine erişebilir ve belirli kontrollere göre gerekli bilgileri alabilir. Cabot, uyarı verilerini bir Postgres veritabanında depolar ve ayrıca Redis kullanan bir önbelleğe sahiptir.
Cabot doğal olarak Graphite'i destekler, ancak aynı zamanda bu alanda nadir görülen Jenkins'i de destekler. Arachnys, Jenkins'i merkezi bir cron gibi kullanıyor, ancak kesinti gibi derleme hatalarını ele alma fikrini seviyorum. Açıkçası, derleme hatası, üretim kesintisi kadar önemli değildir, ancak hata çözülmezse, yine de ekibi uyarabilir ve yükseltebilir. Başarısız bir derlemeyle ilgili her e-posta aldığımda gerçekte Jenkins'i kim kontrol ediyor? ben de!
Bir başka ilginç özellik de Cabot'un çağrı üzerine rotasyon için Google Takvim ile entegre edilebilmesidir. Cabot, bu özelliği bir İngiliz listesi veya rotasyon terimi olan Rota olarak adlandırıyor. Bu çok mantıklı ve umarım diğer sistemler bu fikri daha iyi anlayabilir. Cabot, birincil ve yedek personelden daha karmaşık hiçbir şeyi desteklemez, ancak ek özellikler için kesinlikle yer vardır. Belgeler, daha gelişmiş bir şey istiyorsanız, ticari bir seçeneğe bakmanız gerektiğini söylüyor.
3. İstatistikler
StatsAgg? bunu nasıl yaptın? Her gün bir uyarı platformu oluşturan bir yayıncılık şirketiyle karşılaşmıyorsunuz. Bence tanınmayı hak ediyor. Elbette, Pearson artık sadece bir yayıncılık şirketi değil; O'Reilly Media ile çeşitli web siteleri ve ortak girişimleri var. Ancak yine de ders kitaplarımı ve sınavlarımı yayınlayan şirketin olduğunu düşünüyorum.
StatsAgg sadece bir uyarı platformu değil, aynı zamanda bir gösterge toplama platformudur. Diğer sistemler için bir proxy gibidir. Giriş olarak Graphite, StatsD, InfluxDB ve OpenTSDB'yi destekler, ancak bu ölçümleri kendi platformlarına da iletebilir. Bu ilginç bir kavram ama merkez servisin yükü arttıkça riskler de olabilir. Ancak, StatsAgg altyapısı yeterince güçlüyse, arka uç depolama platformu bozulsa bile yine de uyarılar oluşturabilir.
StatsAgg, Java ile yazılmıştır ve yalnızca karmaşıklığı en aza indirebilecek ana sunucuyu ve kullanıcı arayüzünü içerir. Normal ifade eşleşmesine göre uyarılar gönderebilir ve ana bilgisayarlar veya örneklerle ilgili uyarılar yerine hizmetlere odaklanabilir. Amacı, açık kaynak gözlemlenebilirlik yığınındaki boşlukları doldurmak ve bence iyi bir iş çıkarıyor.
Üç, görselleştirme araçları
1. grefana
Hemen hemen herkes Grafana'yı tanır ve birçok kişi onu kullanır. Ne zaman basit bir kontrol paneline ihtiyacım olsa, onu yıllardır kullanıyorum. Daha önce kullandığım araçlar kullanımdan kaldırıldı ve Grafana hazır olana kadar bu konuda çok üzülüyorum. Grafana, Torkel Ödegaard tarafından oluşturuldu. Cabot gibi, Grafana da Noel'de yaratıldı ve Ocak 2014'te piyasaya sürüldü. Sadece birkaç yıl içinde uzun bir yol kat etti. Torkel'in Grafana olarak sınıflandırdığı Kibana gösterge paneli sisteminden kaynaklandı.
Grafana'nın tek odak noktası izleme verilerini daha pratik ve eğlenceli bir şekilde sunmaktır. Graphite, Elasticsearch, OpenTSDB, Prometheus ve InfluxDB'den yerel olarak veri toplayabilir. Daha fazla veri kaynağı elde etmek için eklentileri kullanan bir kurumsal sürüm var, ancak bu diğer veri kaynağı eklentilerini açık kaynak olarak oluşturmak için hiçbir neden yok, çünkü Grafana eklenti ekosistemi zaten birçok başka veri kaynağı sağlıyor.
Grafana benim için ne yaptı? Sistemimi anlamak için merkezi bir konum sağlar. Web tabanlıdır, bu nedenle bu bilgilere herkes erişebilir, ancak farklı kimlik doğrulama yöntemleri kullanılarak kısıtlanabilir. Grafana, net bilgi sağlamak için birçok farklı görselleştirme türü kullanabilir. Ancak, alarmları ve diğer işlevleri geleneksel olarak görselleştirme ile birleştirmeye başlamıştır.
Artık alarmları sezgisel olarak ayarlayabilirsiniz. Bu, grafikleri görüntüleyebileceğiniz ve hatta sistem bozulması nedeniyle alarmın nerede tetiklenmesi gerektiğini görebileceğiniz, alarmı tetiklemek için grafiğe tıklayabileceğiniz ve ardından Grafana'ya alarmı nereye göndereceğini söyleyebileceğiniz anlamına gelir. Bu çok güçlü bir eklentidir ve mutlaka uyarı platformunun yerini almayacaktır, ancak uyarı standartlarına farklı bir bakış açısı sağlayarak onu geliştirmeye kesinlikle yardımcı olabilir.
Grafana ayrıca daha fazla işbirliği özelliği sunar. Kullanıcılar uzun süredir gösterge tablolarını paylaşabiliyordu, bu da Kubernetes kümeleri için kendi gösterge tablolarını oluşturmaya gerek olmadığı anlamına geliyor, çünkü bazıları Kubernetes geliştiricileri tarafından sürdürülüyor ve diğerleri Grafana geliştiricileri tarafından sürdürülüyor.
İşbirliğine en önemli katkı ek açıklamalardır. Ek açıklama, kullanıcının grafiğin bir bölümüne bağlam eklemesine olanak tanır. Ardından, diğer kullanıcılar sistemi daha iyi anlamak için bu bağlamı kullanabilir. Ekip bir olayın ortasında olduğunda ve iletişim ve karşılıklı anlayış çok önemli olduğunda bu paha biçilmez bir araçtır. Bilginin takım arasında daha hızlı paylaşılabilmesi için tüm bilgileri görüntülediğiniz yere koyun. Bu aynı zamanda, takımın başarısızlığın nedenini anlamaya ve sonradan suçsuz olarak kullanılabilecek sistemlerini anlamaya çalışırken harika bir özelliktir.
2. Vizceral
Netflix, trafik yük devretme gerçekleştirirken trafik modellerini daha iyi anlamak için Vizceral'ı yarattı. Grafana'nın aksine Grafana daha genel bir araçtır ve Vizceral çok özel kullanım durumları sağlar. Netflix artık bu aracı dahili olarak kullanmıyor ve artık aktif olarak kullanmadığını, ancak yine de düzenli olarak güncelleneceğini söyledi. Burada ilginç bir görselleştirme mekanizmasına ve problemlerin çözülmesine nasıl yardımcı olabileceğine dikkat çekmeyi vurguluyorum. Bu sistemlerin konseptlerini daha iyi anlamak ve olanaklarına tanık olmak için bir demo ortamında çalıştırmaya değer.
Orijinal bağlantı:
https://opensource.com/article/18/10/alerting-and-visualization-tools-sysadmins
