David O'Brien yakın zamanda Microsoft Azure Stack bulut ürünlerine odaklanan kendi şirketi Xirus'u (https://xirus.com.au) kurdu. Veri merkezlerinde, uç konumlarda, uzak ofislerde ve bulutta tutarlı bir şekilde hibrit uygulamalar oluşturup çalıştırmak için tasarlandılar.
David, bireylere ve şirketlere Microsoft Azure ve Azure DevOps (eski adıyla VSTS) ile ilgili her konuda eğitim veriyor ve halen uygulamalı danışmanlık ve alt kodlama yapıyor. 5 yıldır Microsoft MVP (Microsoft En Değerli Profesyonel) Ödülünü kazanmış ve yakın zamanda Azure MVP Ödülünü almıştır. Melbourne Microsoft Bulut ve Veri Merkezi Buluşması'nın ortak organizatörü olan O'Brien, düzenli olarak uluslararası konferanslarda konuşuyor ve dünyayı gezmeye olan ilgisini BT hikayelerini toplulukla paylaşma tutkusuyla birleştiriyor. David'in blogu şu adreste bulunmaktadır: Ayrıca online eğitimlerini Pluralsight üzerinden yayınlıyor.
Konuşmada, ortamınızda neler olup bittiğini ve uygulamanızın nasıl performans gösterdiğini anlamada metriklerin öneminden bahsediliyor. Microsoft Azure, her türlü iş yüküne ilişkin ölçümleri görüntülemenin güçlü ve kolay bir yolunu sunuyor ve derste bunların hepsini nasıl kullanabileceğinizi açıklıyoruz.
Pazar günü sabah saat 3'te uyurken aniden bir kısa mesajla uyanırsınız: "süper kritik uygulama yine yanıt vermiyor." Neler oluyor? “Frenlerin” nedeni nerede ve nedir? Bu konuşmada, Microsoft Azure'un müşterilere bulut iş yüklerinizden günlükleri ve özellikle ölçümleri toplamaları için sunduğu hizmetler hakkında bilgi edineceksiniz. David size bir bulut platformunda çalışırken hangi metriklerle ilgilenmeniz gerektiğini ve bunlara nasıl ulaşacağınızı anlatacak. Açık kaynak araçları ve kontrol paneli oluşturma hakkında bilgi edinecek ve kendi kontrol panellerinizi oluşturmak için yeterli bilgiye sahip olacaksınız.
Ve sabah saat 3'te kritik bir uygulamanın çöktüğünü bildiren bir mesajla tekrar uyanırsanız, bunun nedenini hızlı bir şekilde anlayabilirsiniz.
İyi günler, bugün metrikler hakkında konuşacağız. Adım David O'Brien, küçük bir Avustralya danışmanlık şirketi olan Xirus'un kurucu ortağı ve sahibiyim. Benimle vakit geçirmek için buraya geldiğiniz için tekrar teşekkür ederim. Peki neden buradayız? Metriklerden bahsetmek için, daha doğrusu onlardan bahsedeceğim ve herhangi bir şey yapmadan önce teoriyle başlayalım.
Metriklerin neler olduğunu, bunlarla neler yapabileceğinizi, nelere dikkat etmeniz gerektiğini, Azure’da metrik toplamanın nasıl toplanıp etkinleştirileceğini ve metrik görselleştirmenin ne olduğunu size anlatacağım. Size bu şeylerin Microsoft bulutunda neye benzediğini ve bu bulutla nasıl çalışılacağını göstereceğim.
Başlamadan önce Microsoft Azure kullananlardan el kaldırmalarını isteyeceğim. AWS ile kim çalışır? Çok az görüyorum. Peki ya Google? ALİ Bulut mu? Bir adam! Harika. Peki metrikler nelerdir? ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün resmi tanımı şu şekildedir: "Metrik, bir özelliğin ölçülmesine ilişkin koşulları ve kuralları açıklayan ve ölçüm sonuçlarının anlaşılmasına hizmet eden bir ölçüm standardıdır." Bu ne anlama geliyor?
Bir sanal makinenin boş disk alanını değiştirmeye yönelik bir ölçüm örneğini ele alalım. Örneğin bize 90 sayısı veriliyor ve bu sayı yüzde anlamına geliyor yani boş disk alanı miktarı %90 oluyor. Metrik tanımının pdf formatında 40 sayfa süren açıklamasını okumanın pek ilgi çekici olmadığını belirtmek isterim.
Ancak metrik ölçüm sonucunun nasıl elde edildiğini söylemez, sadece bu sonucu gösterir. Metriklerle ne yapacağız?
Önce bir şeyin değerini ölçeriz, sonra da ölçüm sonucunu kullanırız.
Örneğin, boş disk alanı miktarını öğrendik ve şimdi onu kullanabiliriz, bu belleği kullanabiliriz vb. Metrik sonucunu aldıktan sonra onu yorumlamamız gerekir. Örneğin, ölçüm 90 sonucunu döndürdü. Bu sayının ne anlama geldiğini bilmemiz gerekiyor: yüzde veya gigabayt cinsinden boş alan miktarı veya kullanılan disk alanı miktarı, ağ gecikmesi 90 ms'ye eşit vb. metrik değerinin anlamını yorumlamamız gerekiyor. Metriklerin anlamlı olabilmesi için tek bir metrik değerini yorumladıktan sonra birden fazla değerin toplanmasını sağlamamız gerekiyor. Bu çok önemlidir çünkü birçok kişi metrik toplamanın gerekliliğinin farkında değildir. Microsoft, ölçümlerin toplanmasını çok kolaylaştırmıştır ancak bunların toplandığından emin olmak size kalmıştır. Bu ölçümler yalnızca 41 gün boyunca saklanır ve 42. günde kaybolur. Bu nedenle, harici veya dahili ekipmanınızın özelliklerine bağlı olarak, metrikleri 41 günden daha uzun süre - günlükler, günlükler vb. şeklinde - nasıl kaydedeceğinize dikkat etmelisiniz. Bu nedenle, topladıktan sonra bunları, gerekirse metrik sonuçlarındaki değişikliklerin tüm istatistiklerini çıkarmanıza olanak tanıyan bir yere yerleştirmelisiniz. Onları oraya yerleştirerek onlarla etkili bir şekilde çalışmaya başlayabilirsiniz.
Ancak metrikleri aldıktan, yorumladıktan ve topladıktan sonra bir SLA - hizmet düzeyi sözleşmesi oluşturabilirsiniz. Bu SLA müşterileriniz için çok önemli olmayabilir; meslektaşlarınız, yöneticileriniz, sistemin bakımını yapan ve işlevselliğiyle ilgilenen kişiler için daha önemlidir. Metrik, bilet sayısını ölçebilir; örneğin, günde 5 bilet alıyorsunuz ve bu durumda kullanıcı isteklerine yanıt verme hızını ve sorun giderme hızını gösterir. Bir metrik yalnızca sitenizin 20 ms'de yüklendiğini veya yanıt hızınızın 20 ms olduğunu söylememelidir; bir metrik, tek bir teknik göstergeden daha fazlasıdır.
Bu nedenle konuşmamızın görevi size metriklerin özünün ayrıntılı bir resmini sunmaktır. Metrik, ona bakarak sürecin tam bir resmini elde edebilmenizi sağlar.
Metriği elde ettiğimizde, sistemin çalıştığını %99 oranında garanti edebiliriz, çünkü bu sadece sistemin çalıştığını söyleyen bir günlük dosyasına bakmak değildir. %99 kesintisiz çalışma garantisi, örneğin API'nin %99 oranında normal 30 ms hızında yanıt verdiği anlamına gelir. Kullanıcılarınızın, meslektaşlarınızın ve yöneticilerinizin ilgisini çeken şey tam olarak budur. Müşterilerimizin birçoğu web sunucusu loglarını izliyor ancak bunlarda herhangi bir hata fark etmiyor ve her şeyin yolunda olduğunu düşünüyor. Örneğin 200 Mb/s ağ hızını görüyorlar ve şöyle düşünüyorlar: “Tamam, her şey harika!” Ancak bu 200'e ulaşmak için kullanıcıların 30 milisaniyelik bir yanıt hızına ihtiyacı var ve bu tam olarak ölçülmeyen ve günlük dosyalarında toplanmayan göstergedir. Aynı zamanda kullanıcılar sitenin çok yavaş yüklenmesine şaşırıyorlar çünkü gerekli metriklere sahip olmadıkları için bu davranışın nedenlerini bilmiyorlar.
Ancak %100 kesintisiz çalışma SLA'sına sahip olduğumuzdan, müşteriler sitenin kullanımının aslında çok zor olmasından şikayet etmeye başlıyor. Bu nedenle objektif bir SLA oluşturmak için toplanan metriklerin oluşturduğu sürecin tam resmini görmek gerekir. Bu, SLA'ları oluştururken "çalışma süresi" teriminin ne anlama geldiği hakkında hiçbir fikri olmayan ve çoğu durumda müşterilerine API'lerinin nasıl çalıştığını açıklamayan bazı sağlayıcılarla yaşadığım devam eden bir sorundur.
Örneğin üçüncü bir kişi için bir API gibi bir hizmet oluşturduysanız, ortaya çıkan 39,5 ölçüsünün ne anlama geldiğini anlamalısınız - yanıt, başarılı yanıt, 20 ms hızında yanıt veya 5 ms hızında yanıt. Onların SLA'sını kendi SLA'nıza, kendi ölçümlerinize uyarlamak size kalmıştır.
Tüm bunları anladıktan sonra çarpıcı bir kontrol paneli oluşturmaya başlayabilirsiniz. Söyleyin bana, Grafana etkileşimli görselleştirme uygulamasını kullanan var mı? Harika! Bu açık kaynağın büyük bir hayranıyım çünkü bu şey ücretsiz ve kullanımı kolay.
Henüz Grafana'yı kullanmadıysanız size onunla nasıl çalışacağınızı anlatacağım. 80'li ve 90'lı yıllarda doğan herkes muhtemelen CareBears'ı hatırlıyordur? Bu ayıların Rusya'da ne kadar popüler olduğunu bilmiyorum ama konu ölçümlere gelince, biz de aynı "bakıcı ayılar" olmalıyız. Söylediğim gibi, tüm sistemin nasıl çalıştığına dair büyük bir resme ihtiyacınız var ve bu sadece API'niz, web siteniz veya sanal makinede çalışan hizmetle ilgili olmamalı.
Tüm sistemin işleyişini en iyi şekilde yansıtan metriklerin koleksiyonunu organize etmelisiniz. Çoğunuz yazılım geliştiricisisiniz, dolayısıyla hayatınız sürekli değişiyor, yeni ürün gereksinimlerine uyum sağlıyor ve tıpkı kodlama süreçleriyle ilgilendiğiniz gibi metriklerle de ilgilenmeniz gerekiyor. Metriğin yazdığınız her kod satırıyla nasıl ilişkili olduğunu bilmeniz gerekir. Örneğin, gelecek hafta yeni bir pazarlama kampanyası başlatıyorsunuz ve çok sayıda kullanıcının sitenizi ziyaret etmesini bekliyorsunuz. Bu olayı analiz etmek için ölçümlere ihtiyacınız olacak ve bu kişilerin etkinliklerini takip etmek için tam bir gösterge panosuna ihtiyacınız olabilir. Pazarlama kampanyanızın ne kadar başarılı olduğunu ve gerçekte nasıl performans gösterdiğini anlamak için ölçümlere ihtiyacınız olacak. Örneğin etkili bir CRM - müşteri ilişkileri yönetimi sistemi geliştirmenize yardımcı olacaklar.
Öyleyse Azure bulut hizmetimizi kullanmaya başlayalım. Azure Monitor'e sahip olduğundan metrik koleksiyonunu bulmak ve düzenlemek çok kolaydır. Bu monitör sistem yapılandırma yönetiminizi merkezileştirir. Sisteminize uygulamak istediğiniz Azure öğelerinin her birinde varsayılan olarak etkinleştirilmiş birçok ölçüm bulunur. Bu, kutudan çıktığı gibi çalışan ve herhangi bir ön ayar gerektirmeyen ücretsiz bir uygulamadır; sisteminize herhangi bir şey yazmanıza veya "vidalamanıza" gerek yoktur. Bunu aşağıdaki demoya bakarak doğrulayacağız.
Ayrıca bu metriklerin Splunk log depolama ve analiz sistemi, bulut tabanlı log yönetimi uygulaması SumoLogic, ELK log işleme aracı ve IBM Radar gibi üçüncü taraf uygulamalara gönderilmesi de mümkün. Doğru, kullandığınız kaynaklara (sanal makine, ağ hizmetleri, Azure SQL veritabanları) bağlı olarak küçük farklılıklar vardır; yani ölçümlerin kullanımı, çalışma ortamınızın işlevlerine bağlı olarak farklılık gösterir. Bu farklılıkların ciddi olduğunu söylemeyeceğim ama maalesef hala mevcut ve bunun dikkate alınması gerekiyor. Metrikleri etkinleştirmek ve göndermek birkaç yolla mümkündür: Portal, CLI/Power Shell aracılığıyla veya ARM şablonları kullanılarak.
İlk demoma başlamadan önce sorularınızı yanıtlayacağım. Soru yoksa başlayalım. Ekran, Azure İzleyici sayfasının nasıl göründüğünü gösterir. Herhangi biriniz bu monitörün çalışmadığını söyleyebilir mi?
Artık her şey yolunda, monitör hizmetlerinin nasıl göründüğünü görebilirsiniz. Bunun günlük işler için mükemmel ve çok basit bir araç olduğunu söyleyebilirim. Uygulamaları, ağları ve altyapıyı izlemek için kullanılabilir. Son zamanlarda izleme arayüzü iyileştirildi ve daha önce hizmetler farklı yerlerde bulunuyorduysa artık hizmetlere ilişkin tüm bilgiler monitörün ana sayfasında birleştirildi.
Metrik tablosu, HomeMonitorMetrics yolu üzerinde yer alan ve mevcut tüm metrikleri görmek ve ihtiyacınız olanları seçmek için gidebileceğiniz bir sekmedir. Ancak ölçüm toplamayı etkinleştirmeniz gerekiyorsa HomeMonitorDiagnostic ayarlar dizini yolunu kullanmanız ve Etkin/Devre Dışı ölçümler onay kutularını işaretlemeniz gerekir. Varsayılan olarak hemen hemen tüm ölçümler etkindir ancak ek bir şeyi etkinleştirmeniz gerekirse tanılama durumunu Devre Dışı'dan Etkin'e değiştirmeniz gerekecektir.
Bunu yapmak için seçilen metriğin satırına tıklayın ve açılan sekmede teşhis modunu etkinleştirin. Seçilen metriği analiz edecekseniz Tanılamayı aç bağlantısına tıkladıktan sonra açılan pencerede Send to Log Analytics onay kutusunu işaretlemeniz gerekmektedir.
Log Analytics, Splunk'a biraz benzer ancak maliyeti daha düşüktür. Bu hizmet, tüm ölçümlerinizi, günlüklerinizi ve ihtiyacınız olan diğer her şeyi toplamanıza ve bunları Log Analytics çalışma alanına yerleştirmenize olanak tanır. Hizmet özel bir KQL sorgu işleme dili kullanıyor - Kusto Quarry Language, bir sonraki demoda çalışmalarına bakacağız. Şimdilik, onun yardımıyla metrikler, günlükler, terimler, trendler, kalıplar vb. ile ilgili sorgular oluşturabileceğinizi not edeceğim. ve kontrol panelleri oluşturun.
Bu nedenle, Log Analytics'e Gönder onay kutusunu ve LOG paneli onay kutularını işaretliyoruz: DataPlaneRequests, MongoRequests ve QueryRuntimeStatistics ve METRIC panelinin altındaki İstekler onay kutusu. Daha sonra bir isim verip ayarları kaydediyoruz. Komut satırında bu, iki kod satırını temsil eder. Bu arada Azure Cloud kabuğu bu anlamda Google'a benziyor ve bu aynı zamanda web tarayıcınızdaki komut satırını kullanmanıza da olanak tanıyor. AWS'de böyle bir şey yok dolayısıyla Azure bu anlamda çok daha kullanışlı.
Örneğin, dizüstü bilgisayarımda hiçbir kod yazmadan web arayüzü üzerinden bir demo çalıştırabilirim. Bunu yapmak için Azure hesabımla kimlik doğrulaması yapmam gerekiyor. Ardından, zaten Terrafone kullanıyorsanız, onu kullanabilir, hizmete bağlanmasını bekleyebilir ve çalışan bir ortam elde edebilirsiniz. LinuxMicrosoft'un varsayılan olarak kullandığı yöntem.
Daha sonra Azure Cloud Shell'de yerleşik olan Bash'i kullanıyorum. Çok kullanışlı bir şey, VS Code'un hafif bir versiyonu olan tarayıcıya yerleşik IDE'dir. Daha sonra hata ölçümleri şablonuma girebilir, onu düzenleyebilir ve ihtiyaçlarıma uyacak şekilde özelleştirebilirim.
Bu şablonda metrik koleksiyonunu ayarladıktan sonra, bunu tüm altyapınız için metrikler oluşturmak amacıyla kullanabilirsiniz. Metrikleri uyguladıktan, topladıktan ve sakladıktan sonra bunları görselleştirmemiz gerekecek.
Azure İzleyici yalnızca ölçümlerle ilgilenir ve sisteminizin sağlığına ilişkin genel bir resim sunmaz. Azure ortamının dışında çalışan çok sayıda başka uygulamanız olabilir. Dolayısıyla tüm süreçleri izlemeniz, toplanan tüm ölçümleri tek bir yerde görselleştirmeniz gerekiyorsa Azure Monitor bunun için uygun değildir.
Bu sorunu çözmek için Microsoft, çok çeşitli verilerin görselleştirilmesini içeren kapsamlı bir iş analizi yazılımı olan Power BI aracını sunar. Bu, maliyeti ihtiyacınız olan işlevler kümesine bağlı olan oldukça pahalı bir üründür. Varsayılan olarak size işlenecek 48 tür veri sunar ve Azure SQL Veri Ambarları, Azure Data Lake Storage, Azure Machine Learning Services ve Azure Databricks'e bağlanır. Ölçeklenebilirliği kullanarak her 30 dakikada bir yeni veriler alabilirsiniz. Gerçek zamanlı izleme görselleştirmesine ihtiyacınız varsa bu ihtiyaçlarınız için yeterli olabilir veya olmayabilir. Bu durumda bahsettiğim Grafana gibi uygulamaların kullanılması tavsiye edilir. Ayrıca Microsoft belgeleri, SIEM araçlarını kullanarak Splunk, SumoLogic, ELK ve IBM radar görselleştirme sistemlerine metrikler, günlükler ve olay tabloları gönderme yeteneğini açıklamaktadır.
23:40 dk.
Devamı çok yakında...
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com
