Zabbix bir izleme sistemidir. Diğer tüm sistemler gibi, tüm izleme sistemlerinin üç ana sorunuyla karşı karşıyadır: veri toplama ve işleme, geçmişi saklama ve temizleme.
Verilerin alınması, işlenmesi ve kaydedilmesi aşamaları zaman alır. Çok fazla değil, ancak büyük bir sistem için bu, büyük gecikmelere neden olabilir. Depolama sorunu bir veri erişim sorunudur. Raporlar, kontroller ve tetikleyiciler için kullanılırlar. Veri erişimindeki gecikmeler de performansı etkiler. Veritabanları büyüdüğünde alakasız verilerin silinmesi gerekir. Kaldırma, bazı kaynakları da tüketen zor bir işlemdir.
Zabbix'te toplama ve depolama sırasındaki gecikme sorunları önbelleğe alma yoluyla çözülür: çeşitli önbellek türleri, veritabanında önbelleğe alma. Üçüncü sorunu çözmek için önbelleğe alma uygun olmadığından Zabbix TimescaleDB'yi kullandı. O sana bunu anlatacak Andrey Gushchin - teknik Destek Mühendisi . Andrey, 6 yılı aşkın süredir Zabbix'i destekliyor ve performans konusunda doğrudan deneyime sahip.
TimescaleDB nasıl çalışır, normal PostgreSQL'e kıyasla nasıl bir performans verebilir? Zabbix, TimescaleDB veritabanı için nasıl bir rol oynuyor? Sıfırdan nasıl başlanır ve PostgreSQL'den nasıl geçiş yapılır ve hangi konfigürasyon daha iyi performansa sahiptir? Bütün bunlar hakkında kesim altında.
Verimlilik Zorlukları
Her izleme sistemi belirli performans zorluklarıyla karşı karşıyadır. Bunlardan üçünden bahsedeceğim: veri toplama ve işleme, depolama ve geçmişi temizleme.
Hızlı veri toplama ve işleme. İyi bir izleme sistemi, tüm verileri hızlı bir şekilde almalı ve tetikleyici ifadelere göre, kendi kriterlerine göre işlemelidir. İşlemden sonra sistemin bu verileri daha sonra kullanmak üzere hızlı bir şekilde veritabanına kaydetmesi gerekir.
Geçmiş depolama. İyi bir izleme sistemi geçmişi bir veritabanında saklamalı ve metriklere kolay erişim sağlamalıdır. Raporlarda, grafiklerde, tetikleyicilerde, eşiklerde ve hesaplanan uyarı verisi öğelerinde geçmişin kullanılması gerekir.
Geçmişi temizleme. Bazen metrikleri saklamanıza gerek kalmadığı bir gün gelir. Neden 5 yıl önce, bir veya iki ay önce toplanan verilere ihtiyacınız var: bazı düğümler silindi, bazı ana bilgisayarlara veya metriklere artık gerek yok çünkü bunlar güncel değil ve artık toplanmıyor. İyi bir izleme sistemi, veritabanının büyümemesi için geçmiş verileri saklamalı ve zaman zaman silmeli.
Eski verilerin temizlenmesi, veritabanı performansını büyük ölçüde etkileyen kritik bir konudur.
Zabbix'te önbelleğe alma
Zabbix'te birinci ve ikinci çağrılar önbellekleme kullanılarak çözülür. RAM veri toplamak ve işlemek için kullanılır. Depolama için - tetikleyicilerdeki, grafiklerdeki ve hesaplanan veri öğelerindeki geçmiş. Veritabanı tarafında, grafikler gibi temel seçimler için bazı önbellekleme vardır.
Zabbix sunucusunun kendi tarafında önbelleğe alma:
- Yapılandırma Önbelleği;
- ValueCache;
- Geçmiş Önbelleği;
- TrendsCache.
Onları daha ayrıntılı olarak düşünün.
Yapılandırma Önbelleği
Bu, metrikleri, ana bilgisayarları, veri öğelerini, tetikleyicileri, yani Ön İşleme ve veri toplama için ihtiyacımız olan her şeyi sakladığımız ana önbellektir.
Veritabanında gereksiz sorgular oluşturulmaması için tüm bunlar ConfigurationCache'de saklanır. Sunucu başladıktan sonra bu önbelleği güncelliyoruz, yapılandırmaları oluşturuyoruz ve periyodik olarak güncelliyoruz.
Veri toplama
Diyagram oldukça büyük, ancak içindeki asıl şey koleksiyoncular. Bunlar çeşitli "anketçiler" - montaj süreçleridir. Farklı montaj türlerinden sorumludurlar: SNMP, IPMI aracılığıyla veri toplarlar ve hepsini Ön İşleme'ye aktarırlar.
Koleksiyonerler turuncu renkle özetlenmiştir.
Zabbix, çekleri birleştirmek için gereken toplama öğelerini hesapladı. Bunlara sahipsek, onlara ait verileri doğrudan ValueCache'den alırız.
Geçmiş Önbelleğini Ön İşleme
Tüm toplayıcılar işleri almak için ConfigurationCache'i kullanır. Daha sonra bunları Ön İşleme'ye aktarırlar.
PreProcessing, PreProcessing adımlarını almak için ConfigurationCache'i kullanır. Bu verileri çeşitli şekillerde işler.
Verileri PreProcessing kullanarak işledikten sonra, işlenmek üzere HistoryCache'e kaydederiz. Bu veri toplamayı sonlandırıyor ve Zabbix'teki ana sürece geçiyoruz - geçmiş senkronize ediciÇünkü yekpare bir mimaridir.
Not: Ön İşleme oldukça zor bir işlemdir. V4.2 ile proxy'ye taşındı. Çok sayıda veri öğesi ve toplama sıklığına sahip çok büyük bir Zabbix'iniz varsa bu, işi çok daha kolay hale getirir.
ValueCache, geçmiş ve trendler önbelleği
Geçmiş eşitleyici, her veri öğesini, yani her değeri atomik olarak işleyen ana işlemdir.
Geçmiş eşitleyici, HistoryCache'ten değerleri alır ve hesaplamalar için tetikleyicilerin varlığı açısından Yapılandırmayı kontrol eder. Varsa hesaplar.
Geçmiş eşitleyici bir olay oluşturur, yapılandırmanın gerektirdiği durumlarda uyarılar oluşturmak için üst kademeye iletir ve kaydeder. Sonraki işlemler için tetikleyiciler varsa, geçmiş tablosuna erişmemek için bu değeri ValueCache'de saklar. ValueCache, tetikleyicileri ve hesaplanan öğeleri hesaplamak için gerekli verilerle bu şekilde doldurulur.
Geçmiş eşitleyici tüm verileri veritabanına yazar ve diske yazar. İşleme süreci burada sona ermektedir.
Veritabanında önbelleğe alma
Olaylara ilişkin grafikleri veya raporları görüntülemek istediğinizde veritabanı tarafında çeşitli önbellekler bulunur:
Innodb_buffer_poolMySQL tarafında;shared_buffersPostgreSQL tarafında;effective_cache_sizeOracle tarafında;shared_poolDB2 tarafında.
Başka birçok önbellek var, ancak bunlar tüm veritabanları için ana önbelleklerdir. Sorgular için sıklıkla ihtiyaç duyulan verileri RAM'de saklamanıza olanak tanır. Bunun için kendi teknolojileri var.
Veritabanı performansı kritik öneme sahiptir
Zabbix sunucusu sürekli olarak veri toplar ve yazar. Yeniden başlatıldığında ValueCache'i doldurmak için geçmişten de okur. Komut dosyalarını ve raporları kullanır Zabbix API'sibir Web arayüzü üzerine inşa edilmiştir. Zabbix API veritabanına erişir ve grafikler, raporlar, olay listeleri ve en son sorunlar için gerekli verileri alır.
Görselleştirme için - grafana. Bu, kullanıcılarımız arasında popüler bir çözümdür. Doğrudan Zabbix API üzerinden ve veritabanına istek gönderebilir ve veri alma konusunda belirli bir rekabet yaratır. Bu nedenle, sonuçların ve testlerin hızlı bir şekilde sunulmasını sağlamak için veritabanının daha hassas ve daha iyi ayarlanması gerekir.
Idareci
Zabbix'teki üçüncü performans mücadelesi Housekeeper'ı kullanarak geçmişi temizlemektir. Tüm ayarları takip eder - veri öğeleri, değişiklik dinamiklerinin (trendlerin) gün cinsinden ne kadar süre saklanacağını gösterir.
TrendsCache'i anında hesaplıyoruz. Veriler geldiğinde bir saat boyunca toplayıp trend değişikliklerinin dinamiklerini tablolara kaydediyoruz.
Temizlik görevlisi olağan "seçimleri" kullanarak veritabanındaki bilgileri başlatır ve siler. Bu, iç süreçlerin performans grafiklerinden de görülebileceği gibi her zaman etkili değildir.
Kırmızı grafik, Geçmiş eşitleyicinin sürekli meşgul olduğunu gösterir. Üstteki turuncu grafik, sürekli çalışan Housekeeper'ı göstermektedir. Veritabanının belirttiği tüm satırları silmesini bekler.
Housekeeper'ı ne zaman devre dışı bırakmalısınız? Mesela “Item ID” var ve belli bir süre içerisinde son 5 bin satırı silmeniz gerekiyor. Elbette bu indeksleme yoluyla gerçekleşir. Ancak genellikle veri kümesi çok büyüktür ve veritabanı yine de diskten okur ve onu önbelleğe koyar. Bu, veritabanı için her zaman çok pahalı bir işlemdir ve veritabanının boyutuna bağlı olarak performans sorunlarına yol açabilir.
Temizlik görevlisinin devre dışı bırakılması kolaydır. Web arayüzünde Housekeeper için “Genel Yönetim” ayarı bulunmaktadır. Dahili trend geçmişi için dahili Temizlik hizmetini devre dışı bırakırız ve artık bunu yönetmez.
Hizmetçi kapatıldı, grafikler dengelendi - bu durumda ne gibi sorunlar olabilir ve üçüncü performans sorununu çözmeye ne yardımcı olabilir?
Bölümleme - bölümleme veya bölümleme
Tipik olarak bölümleme, listelediğim her ilişkisel veritabanında farklı şekilde yapılandırılır. Her birinin kendi teknolojisi vardır ancak genel olarak benzerdirler. Yeni bir bölüm oluşturmak çoğu zaman belirli sorunlara yol açar.
Tipik olarak bölümler, bir günde oluşturulan veri miktarı olan "kuruluma" bağlı olarak yapılandırılır. Kural olarak, Bölümlendirme bir günde yapılır, bu minimumdur. Yeni bir partinin trendleri için - 1 ay.
“Kurulum” çok büyükse değerler değişebilir. Küçük bir "kurulum" 5 nvps'ye (saniyede yeni değerler) kadarsa, orta "kurulum" 000 ila 5 arasındaysa, büyük bir "kurulum" 000 nvps'nin üzerindedir. Bunlar, veritabanının dikkatli bir şekilde yapılandırılmasını gerektiren büyük ve çok büyük kurulumlardır.
Çok büyük kurulumlarda bir günlük süre ideal olmayabilir. Günde 40 GB veya daha fazla MySQL bölümleri gördüm. Bu, sorunlara neden olabilecek ve azaltılması gereken çok büyük miktarda veridir.
Bölümlendirme ne sağlar?
Bölümleme tabloları. Genellikle bunlar diskteki ayrı dosyalardır. Sorgu planı bir bölümü daha uygun şekilde seçer. Bölümleme genellikle aralığa göre kullanılır; bu aynı zamanda Zabbix için de geçerlidir. Orada "zaman damgası"nı kullanıyoruz - çağın başlangıcından bu yana geçen süre. Bunlar bizim için sıradan rakamlar. Günün başlangıcını ve bitişini siz belirlersiniz - bu bir bölümdür.
Hızlı kaldırma - DELETE. Silinecek satırların seçimi yerine bir dosya/alt tablo seçilir.
Veri alımını önemli ölçüde hızlandırır SELECT - tablonun tamamı yerine bir veya daha fazla bölüm kullanır. İki günlük verilere erişiyorsanız, veri tabanından daha hızlı alınır çünkü büyük bir tablo yerine, önbelleğe yalnızca bir dosya yükleyip geri döndürmeniz gerekir.
Çoğu zaman birçok veritabanı da hızlandırılır INSERT — alt tabloya eklemeler.
Zaman çizelgesiDB
V 4.2 için dikkatimizi TimescaleDB'ye çevirdik. Bu, yerel arayüze sahip bir PostgreSQL uzantısıdır. Uzantı, ilişkisel veritabanlarının avantajlarını kaybetmeden zaman serisi verileriyle etkili bir şekilde çalışır. TimescaleDB ayrıca otomatik olarak bölümlenir.
TimescaleDB'nin bir konsepti var hipertable (hipertable) sizin yarattığınız. Bu içerir parçalar - bölümler. Parçalar, diğer parçaları etkilemeyen, otomatik olarak yönetilen hipertabl parçalardır. Her parçanın kendi zaman aralığı vardır.
TimescaleDB ve PostgreSQL karşılaştırması
TimescaleDB gerçekten verimli çalışıyor. Uzantının üreticileri, özellikle inserts üzere daha doğru bir sorgu işleme algoritması kullandıklarını iddia ediyor. Veri kümesi ekleme boyutu büyüdükçe algoritma sabit performansı korur.
200 milyon satırdan sonra PostgreSQL genellikle önemli ölçüde düşmeye başlar ve performansı 0'a düşer. TimescaleDB, herhangi bir miktarda veri için verimli bir şekilde "ekler" eklemenize olanak tanır.
Montaj
TimescaleDB'nin kurulumu herhangi bir paket için oldukça kolaydır. İÇİNDE her şey ayrıntılı olarak açıklanmıştır - resmi PostgreSQL paketlerine bağlıdır. TimescaleDB manuel olarak da oluşturulabilir ve derlenebilir.
Zabbix veritabanı için uzantıyı etkinleştirmemiz yeterli:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Sen etkinleştir extension ve bunu Zabbix veritabanı için oluşturun. Son adım bir hipertablo oluşturmaktır.
Geçmiş tablolarını TimescaleDB'ye taşıma
Bunun için özel bir fonksiyon var create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Fonksiyonun üç parametresi vardır. Birinci - veritabanındaki tablobunun için bir hiper tablo oluşturmanız gerekir. Saniye - alanbuna göre oluşturmanız gereken chunk_time_interval — kullanılacak bölüm parçalarının aralığı. Benim durumumda aralık bir gün - 86.
Üçüncü parametre - migrate_data. Eğer ayarlarsan trueardından mevcut tüm veriler önceden oluşturulmuş parçalara aktarılır. kendim kullandım migrate_data. Yaklaşık 1 TB'ım vardı ve bu bir saatten fazla sürdü. Hatta bazı durumlarda test sırasında, depolama için gerekli olmayan karakter türlerinin geçmiş verilerini aktarmamak için sildim.
Son adım - UPDATE: içinde db_extension koymak timescaledbböylece veritabanı bu uzantının var olduğunu anlar. Zabbix bunu etkinleştirir ve veritabanındaki sözdizimini ve sorguları - TimescaleDB için gerekli olan özellikleri - doğru şekilde kullanır.
Donanım yapılandırması
İki sunucu kullandım. Birinci - VMware makinesi. Oldukça küçüktür: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz işlemci, 16 GB RAM ve 200 GB SSD.
Üzerine PostgreSQL 10.8'i Debian 10.8-1.pgdg90+1 OS ve xfs dosya sistemiyle kurdum. Zabbix'in kullanacağı hariç, her şeyi bu özel veritabanını kullanacak şekilde minimum düzeyde yapılandırdım.
Aynı makinede bir Zabbix sunucusu, PostgreSQL ve yük acenteleri. Kullandığım 50 aktif ajanım vardı LoadableModuleçok hızlı bir şekilde farklı sonuçlar üretmek için: sayılar, dizeler. Veritabanını birçok veriyle doldurdum.
Başlangıçta içerdiği yapılandırma 5 element Ana bilgisayar başına veri. Hemen hemen her öğe, gerçek kurulumlara benzemesini sağlayacak bir tetikleyici içeriyordu. Bazı durumlarda birden fazla tetikleyici vardı. Bir ağ düğümü için şunlar vardı: 3-000 tetikleyici.
Veri Öğesi Güncelleme Aralığı − 4-7 saniye. Sadece 50 ajan kullanmakla kalmayıp daha fazlasını ekleyerek yükün kendisini düzenledim. Ayrıca veri öğelerini kullanarak yükü dinamik olarak ayarladım ve güncelleme aralığını 4 saniyeye düşürdüm.
PostgreSQL. 35 nvps
Bu donanımı ilk kez saf PostgreSQL üzerinde çalıştırdım - saniyede 35 bin değer. Gördüğünüz gibi, veri eklemek bir saniyenin kesirleri kadar zaman alır - her şey yolunda ve hızlıdır. Tek şey 200 GB'lık bir SSD diskin hızla dolması.
Bu standart bir Zabbix sunucu performansı kontrol panelidir.
İlk mavi grafik saniyedeki değer sayısıdır. Sağdaki ikinci grafik ise build işlemlerinin yüklenmesini gösteriyor. Üçüncüsü, dahili derleme süreçlerini yüklemek: tarih senkronizasyonu ve burada uzun süredir çalışan Housekeeper.
Dördüncü grafik HistoryCache kullanımını göstermektedir. Bu, veritabanına eklenmeden önce bir tür tampondur. Yeşil beşinci grafik, ValueCache kullanımını, yani tetikleyiciler için kaç ValueCache isabetinin olduğunu gösterir - bu, saniyede birkaç bin değerdir.
PostgreSQL. 50 nvps
Daha sonra aynı donanım üzerinde yükü saniyede 50 bin değere çıkardım.
Housekeeper'dan yükleme yaparken 10 bin değerin girilmesi 2-3 saniye sürdü.
Temizlikçi zaten işe karışmaya başlıyor.
Üçüncü grafik, genel olarak trapper'lar ve geçmiş senkronize ediciler üzerindeki yükün hala %60'ta olduğunu gösteriyor. Dördüncü grafikte HistoryCache, Housekeeper işlemi sırasında oldukça aktif bir şekilde dolmaya başlıyor. %20'si dolu, yani yaklaşık 0,5 GB.
PostgreSQL. 80 nvps
Daha sonra yükü saniyede 80 bin değere çıkardım. Bu yaklaşık 400 bin veri elemanı ve 280 bin tetikleyicidir.
Otuz geçmiş senkronize edicinin yükleme maliyeti zaten oldukça yüksek.
Ayrıca çeşitli parametreleri de artırdım: geçmiş senkronize ediciler, önbellekler.
Donanımımda geçmiş senkronize edicilerin yükü maksimuma çıktı. HistoryCache hızla verilerle doldu; işlenecek veriler arabellekte birikmişti.
Bunca zaman işlemci, RAM ve diğer sistem parametrelerinin nasıl kullanıldığını gözlemledim ve disk kullanımının maksimumda olduğunu gördüm.
Kullanıma ulaştım maksimum disk kapasitesi bu donanımda ve bu sanal makinede. Böyle bir yoğunlukla PostgreSQL verileri oldukça aktif bir şekilde temizlemeye başladı ve diskin artık yazmaya ve okumaya zamanı kalmadı.
İkinci Server
Zaten 48 işlemciye ve 128 GB RAM'e sahip başka bir sunucuyu aldım. Ayarladım - 60 geçmiş senkronizasyonuna ayarladım ve kabul edilebilir bir performans elde ettim.
Aslında bu zaten bir şeyler yapılması gereken üretkenliğin sınırıdır.
Zaman ÖlçeğiDB. 80 nvps
Asıl görevim TimescaleDB'nin yeteneklerini Zabbix yüküne karşı test etmektir. Saniyede 80 bin değer çok fazla, metrik toplama sıklığı (elbette Yandex hariç) ve oldukça büyük bir "kurulum".
Her grafikte bir düşüş vardır; bu tam olarak veri geçişidir. Zabbix sunucusundaki arızalardan sonra geçmiş senkronize edicinin yükleme profili çok değişti; üç kez düştü.
TimescaleDB, verileri neredeyse 3 kat daha hızlı eklemenize ve daha az HistoryCache kullanmanıza olanak tanır.
Buna göre, verileri zamanında alacaksınız.
Zaman ÖlçeğiDB. 120 nvps
Daha sonra veri öğelerinin sayısını 500 bine çıkardım.Asıl görev TimescaleDB'nin yeteneklerini test etmekti - saniyede 125 bin değer hesaplanan bir değer aldım.
Bu, uzun süre çalışabilecek, çalışan bir "kurulumdur". Ancak diskim sadece 1,5 TB olduğundan birkaç günde doldurdum.
En önemli şey aynı zamanda yeni TimescaleDB bölümlerinin de oluşturulmuş olmasıdır.
Bu performans açısından tamamen farkedilemez. Örneğin MySQL'de bölümler oluşturulduğunda her şey farklıdır. Bu genellikle geceleri meydana gelir çünkü genel eklemeyi engeller, tablolarla çalışır ve hizmetin bozulmasına neden olabilir. TimescaleDB'de durum böyle değil.
Örnek olarak topluluktaki birçok grafiğin bir grafiğini göstereceğim. Resimde TimescaleDB etkinleştirilmiştir ve bu sayede işlemci üzerindeki io.weight kullanımının yükü azalmıştır. Dahili süreç öğelerinin kullanımı da azaldı. Üstelik bu bir SSD değil, sıradan gözleme disklerindeki sıradan bir sanal makinedir.
Bulgular
TimescaleDB küçük "kurulum" için iyi bir çözümdürdisk performansını etkileyen. Veritabanı donanıma mümkün olan en kısa sürede taşınana kadar iyi bir şekilde çalışmaya devam etmenizi sağlayacaktır.
TimescaleDB'nin yapılandırılması kolaydır, performans artışı sağlar, Zabbix ile iyi çalışır ve PostgreSQL'e göre avantajları var.
PostgreSQL kullanıyorsanız ve değiştirmeyi düşünmüyorsanız tavsiye ederim Zabbix ile birlikte PostgreSQL'i TimescaleDB uzantısıyla kullanın. Bu çözüm orta "kuruluma" kadar etkili bir şekilde çalışır.
“Yüksek performans” derken şunu kastediyoruz: . Hizmetlerin milyonlarca kullanıcıya hizmet vermesini sağlayan teknolojiler ve uygulamalar hakkında bilgi edinmek için fazla beklemeniz gerekmeyecek. Liste 7 ve 8 Kasım için zaten derledik ama burada daha fazlası önerilebilir.
abone ol и Yaklaşan konferansın özelliklerini açıkladığımız ve bundan en iyi şekilde nasıl yararlanabileceğimizi öğrendiğimiz.
Kaynak: habr.com