Kılavuzdaki Veritabanlarını Denetleme Bölüm 2: Dağıtım Sonrası Gözlemler

Bu serinin önceki gönderisinde, bu proje için gereksinimleri nasıl topladığımızdan, hangi aracı kullanacağımıza nasıl karar verdiğimizden ve hizmet kesintilerini önlemek için dağıtımı nasıl planladığımızdan bahsetmiştim. Söz verildiği gibi, bu takip yazısı, konuşlandırma sonrası gözlemlere ve bunu bizim için başarılı bir hikaye yapan faktörlerin neler olduğuna odaklanıyor.

Hazırlanan ifadeler ve komut sınıfı filtreleme

Bu proje için ilk tasarımımız, kapsamı gerçekten denetlememiz gereken şeyle sınırlamanın bir yolu olarak ya dahil edilen komutların bir listesini veya hariç tutulan komutları kullanmak için yayılan olayları filtrelemenize izin veren percona eklentisindeki bir özellikten yararlanmayı amaçladı.

Bu özellik, eklentinin algılanan her sql komutunu mysql'e özgü bir listeye dayalı bir sınıfla işaretlemesine ve oradan çıktı katmanında algılanan komut sınıfının bastırılması veya yayılması gerekip gerekmediğine karar vermesine dayanır.

Bu nedenle , satır verilerinde yazmalara veya değişikliklere neden olmayan tüm sql komutlarını hariç tutmak için audit_log_exclude_commands özelliğinden yararlanmak için ilk planı yazdık. Bir dahil etme listesinin kapsam komut sınıflarından herhangi birini kaçırma riskini taşıdığını ve denetim günlüklerimizde boşluk olması için bir neden olabileceğini düşündüğümüz için bir hariç tutma listesine gittik.

Ancak test ettiğimiz ilk kümede, bu ifadelerin başarılı bir şekilde çalıştığı açık olmasına rağmen, denetlenen tüm komutların hata olarak sınıflandırıldığını ve verilerin değiştirilmesi durumunda bunu da başarıyla yaptığını gördük. Ayrıca, bu hata sınıflandırmasıyla ilişkili görünen dışlama listesinden bağımsız olarak tüm sorguların merkezi sistem günlüğü sunucusuna gönderildiğini gördük.

Bu, elastiksearch'te gerçekte ihtiyacımız olandan çok daha fazla olay depoladığımız anlamına geliyordu ve bu da hatalı davranışı zamanında analiz etme ve tespit etme yeteneğimizi kesinlikle etkileyecektir. Güvenlik ekibiyle işbirliği yaparak, hata izleyicileri aracılığıyla sorunu Percona'ya bildirmeye ancak komuta dayalı filtrelemeyi merkezi sistem günlüğü katmanına taşımaya karar verdik.

Mühendislikteki her şey gibi, buradaki ödünleşim, DB ağ katmanı aracılığıyla daha fazla veri göndermek ve merkezileştirilmiş sistem günlüğü katmanındaki filtrelemeyi daha karmaşık hale getirmek ve bunun karşılığında esnek arama ölçeklendirme ihtiyaçlarımızı daha yönetilebilir ve veritabanı tarafındaki yapılandırmayı daha basit hale getirmekti.

Verim

Bu projede bizi çok fazla dertten kurtaran en önemli kararlardan biri, bu günlükleri yakalamak ve merkezi bir syslog sunucusuna göndermek için rsyslog özelliğini kullanmaya karar vermektir.

Ama artıları ve eksileri olmadan hiçbir şey olmaz.

Bu karar, ayrı bir sistemin çalışma süresinin ve aradaki ağ yığınının güvenilirliğinin, denetim ekibimize bu denetim çözümüne olan güveni vermek için ihtiyaç duyduğumuz SLA'yı sağlamak için çok önemli hale geldiği anlamına geliyordu.

Bu tavizi vermeye istekli olmayanlar ve DB yığını içinde denetim günlüklerinin kalıcılığının sorumluluğunu üstlenmeye ihtiyaç duyanlar için, denetim eklentisindeki FILE işleyicisini kullanmanızı ve ardından günlükleri almak ve bunları analiz sistemlerine iletmek için yerel logstash kullanmanızı öneririm. seçim.

Bu ikinci seçim, veritabanı sürecinden uzakta tüketilen ve denetim eklentisi ve logstash tarafından alınan çok daha fazla disk IOP'si anlamına gelir ve bu, örneklerinizdeki disk alanını veritabanı tablo dosyalarınız, işlem günlükleri ve denetim arasında dikkatli bir şekilde dengelemeniz gerektiği anlamına gelir. eklenti günlükleri. Seçeneklerinizi tartmak, yalnızca hangisinin işletme tarafından daha kolay işletilebileceğine/kabul edilebileceğine bağlıdır, ancak yine de seçenekleriniz vardır.

Bizim durumumuzda, rsyslog seçiminin daha yoğun veritabanlarımız için en az etkili olduğu kanıtlandı, yaklaşık 5400 işlem/sn'ye ulaştı, normal işlemler sırasında performans üzerinde hiçbir etki görmedik. Denetim eklentisi, olaylarını veritabanı performansını etkilemeden göndererek ilerliyordu. Bunun nedeni, veritabanı tarafında disk tabanlı işlemleri tüketmekten kaçınan bir mimari seçmemizdi.

Geçmiş kararlar karşılığını veriyor

Bu projeye başladığımızda ilk endişelerimizden biri, bunun performans üzerindeki etkisiydi. Kapsamdaki veritabanı kümelerinden biri çok yoğun zamanlar yaşadı ve uygulamaları gecikmeye karşı hassas olduğundan, eklentiyi dağıttıktan sonra sayıları karşılaştırmak için saniye başına işlem, Disk ve CPU kullanımı gibi performans ölçümlerini takip ettiğimizden emin olmamız gerekiyordu. bakalım bunun cezası ne

Normal operasyonlarda çok fazla ceza almadığımızı görmek bizi mutlu etti. Daha önce bahsedildiği gibi, SYSLOG işleyicisini kullanmaya karar verdiğimiz için bu, normalde bu denetim olaylarını izlemek için herhangi bir yerel disk kapasitesi kullanmamız gerekmediği anlamına geliyordu.

Ancak sadece 'normal çalışma' sürelerine göre planlama yapmak da istemedik.

Ayrıca rsyslog'un yerel biriktirme dosyalarına geri dönmesi gerektiğinde, bu olayların daha kritik DB kümeleri için hizmet kesintilerini etkileyen hizmetlerle birleşmediğini de bilmemiz gerekiyordu. Üretimde yakın izleme altında rsyslog biriktirme davranışını test ederek, veritabanlarımızı işlevsel olarak parçalamak için geçtiğimiz birkaç yılın bize, rsyslog'un diske biriktirilmesi ve ardından yeniden gönderilmesi gereken olayları emmek için çok sayıda disk IOP kapasitesinin planlanmamış faydasını kazandırdığını fark ettik. tüm bu olaylar.

Bu olaylar sırasında disk kullanımındaki artışı kesinlikle not ettik, ancak db örneklerini hiçbir zaman kritik bir duruma getirmedi veya müşteriye yönelik etkinliği etkilemedi.

takaslar

Yazılım mühendisliğindeki her şey gibi, her zaman ödünleşimler vardır. Bu projede, daha güvenilir ve kayıp günlükler için daha az potansiyele sahip bir günlük teslim yöntemini düşündük. Bu, günlükleri diske yazmayı, ardından bunları almak ve güvenlik ekibinin kullanması için analiz hedeflerine göndermek için logstash gibi bir şey kullanmayı içerir.

Ancak bu, bu veritabanlarına müşteriye yönelik çağrıların hizmet kalitesini potansiyel olarak etkileyebileceğini bildiğimiz veritabanı tarafında önemli miktarda disk IOP tüketimi anlamına gelirdi.

rsyslog'da esnek günlük kaydı kullanarak, makul boyutta bir makara kullanarak ve olayları günlük izleme yığınımıza göndermek için TCP kullanarak iş ihtiyaçlarımızın yeterince karşılanacağına karar verdik. Hayattaki her şey gibi, hiçbir şey sonsuz değildir. Ve bu kararın gelecekte yeniden gözden geçirilmesi gerekebileceğinin farkındayız.

En sonunda

Bu proje, yarım düzine kümeyi ve çok sayıda örneği kapsarken, tek bir çeyrekte tamamlandı, DB operasyon ekibi hala hızlı büyüyen bir işte ışıkları açık tutuyordu. Bu, DBE ve güvenlik ekibi arasında yakın işbirliği olmadan ve kapsamı sınırlı tutan ve hepimizin gözümüzün işimizi daha güvenli hale getirme nihai hedefinde olduğundan emin olmamızı sağlayan güçlü ürün yönetimi olmadan gerçekleşemezdi.