Zabbix bir monitorinq sistemidir. Hər hansı digər sistem kimi, bütün monitorinq sistemlərinin üç əsas problemi ilə üzləşir: məlumatların toplanması və işlənməsi, tarixin saxlanması və təmizlənməsi.
Məlumatların qəbulu, işlənməsi və qeydə alınması mərhələləri vaxt aparır. Çox deyil, lakin böyük bir sistem üçün bu, böyük gecikmələrlə nəticələnə bilər. Saxlama problemi məlumat əldə etmək məsələsidir. Onlar hesabatlar, yoxlamalar və tətiklər üçün istifadə olunur. Məlumata giriş gecikmələri də performansa təsir göstərir. Verilənlər bazası böyüdükdə, aidiyyəti olmayan məlumatlar silinməlidir. Silinmə həm də bəzi resursları yeyən ağır bir əməliyyatdır.
Zabbix-də yığım və saxlama gecikmə problemləri keşləmə yolu ilə həll olunur: bir neçə növ keş, verilənlər bazasında keş. Üçüncü problemi həll etmək üçün keşləmə uyğun deyil, buna görə TimescaleDB Zabbix-də istifadə edilmişdir. Bu haqda məlumat verəcək Andrey Quşçin - texniki dəstək mühəndisi . Andrey 6 ildən artıqdır ki, Zabbix-i dəstəkləyir və performansda birbaşa iştirak edir.
TimescaleDB necə işləyir, adi PostgreSQL ilə müqayisədə hansı performansı verə bilər? Zabbix TimescaleDB-də hansı rolu oynayır? Sıfırdan necə başlamaq və PostgreSQL-dən necə köçmək olar və hansı konfiqurasiya performansı daha yaxşıdır? Bütün bunlar kəsik altında.
Performans Problemləri
Hər bir monitorinq sistemi müəyyən performans problemləri ilə üzləşir. Mən onlardan üçü haqqında danışacağam: məlumatların toplanması və emalı, saxlanması, tarixin təmizlənməsi.
Sürətli məlumatların toplanması və işlənməsi. Yaxşı bir monitorinq sistemi bütün məlumatları tez bir zamanda qəbul etməli və onu tətik ifadələrinə uyğun olaraq - öz meyarlarına uyğun olaraq emal etməlidir. Emal edildikdən sonra sistem bu məlumatları daha sonra istifadə etmək üçün verilənlər bazasında da tez saxlamalıdır.
Tarixçə saxlama. Yaxşı monitorinq sistemi tarixi verilənlər bazasında saxlamalı və ölçülərə asan girişi təmin etməlidir. Tarixçədən hesabatlarda, qrafiklərdə, tetikleyicilerde, həddlərdə və hesablanmış xəbərdarlıq elementlərində istifadə etmək lazımdır.
Tarixin təmizlənməsi. Bəzən elə bir gün gəlir ki, ölçüləri saxlamağa ehtiyac yoxdur. 5 il, bir və ya iki ay əvvəl toplanmış məlumatlara niyə ehtiyacınız var: bəzi qovşaqlar silindi, bəzi hostlar və ya ölçülər artıq lazım deyil, çünki köhnəlmişdir və artıq yığılmır. Yaxşı bir monitorinq sistemi tarixi məlumatları saxlamalı və zaman-zaman silməlidir ki, verilənlər bazası böyüməsin.
Köhnə məlumatların təmizlənməsi verilənlər bazası işinə böyük təsir göstərən çətin məsələdir.
Zabbix-də keşləmə
Zabbix-də birinci və ikinci zənglər keşləmə ilə həll edilir. RAM məlumat toplamaq və emal etmək üçün istifadə olunur. Saxlama üçün - triggerlərdə, qrafiklərdə və hesablanmış maddələrdə tarix. DB tərəfində, qrafiklər kimi əsas seçimlər üçün bəzi keşləmə var.
Zabbix serverinin yan tərəfində keşləmə:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Daha ətraflı şəkildə düşünün.
ConfigurationCache
Bu, ölçüləri, hostları, elementləri, tetikleyiciləri - Preprocessing və məlumatların toplanması üçün lazım olan hər şeyi saxladığımız əsas keşdir.
Bütün bunlar verilənlər bazasında lazımsız sorğular yaratmamaq üçün ConfigurationCache-də saxlanılır. Server işə salındıqdan sonra biz bu keşi yeniləyirik, konfiqurasiyalar yaradırıq və vaxtaşırı yeniləyirik.
Məlumatların toplanması
Sxem olduqca böyükdür, amma əsas odur kolleksiyaçılar. Bunlar müxtəlif "pollerlər" - montaj prosesləri. Onlar müxtəlif montaj növlərinə cavabdehdirlər: SNMP, IPMI vasitəsilə məlumatları toplayır və hamısını PreProcessing-ə ötürürlər.
Seçicilər narıncı rənglə dövrələnmişdir.
Zabbix yoxlamaları toplamaq üçün lazım olan toplama elementlərini hesablayıb. Əgər bizdə varsa, biz onlar üçün məlumatları birbaşa ValueCache-dən götürürük.
Öncədən işlənmə tarixçəsi
Bütün kolleksiyaçılar işləri qəbul etmək üçün ConfigurationCache-dən istifadə edirlər. Sonra onları Preprocessing-ə ötürürlər.
PreProcessing, PreProcessing addımlarını əldə etmək üçün ConfigurationCache istifadə edir. Bu məlumatları müxtəlif yollarla emal edir.
Məlumatları PreProcessing ilə emal etdikdən sonra onu emal etmək üçün HistoryCache-də saxlayırıq. Bu, məlumatların toplanması prosesini tamamlayır və biz Zabbix-də əsas prosesə keçirik - tarix sinxronlaşdırıcısı, çünki monolit memarlıqdır.
Qeyd: Preprocessing kifayət qədər ağır əməliyyatdır. v 4.2-dən bəri o, proxy-yə köçürülüb. Çox sayda əşya və toplama tezliyi olan çox böyük Zabbixiniz varsa, bu, işləri çox asanlaşdırır.
ValueCache, tarix və meyllər önbelleği
Tarix sinxronizasiyası hər bir məlumat elementini, yəni hər bir dəyəri atomik şəkildə emal edən əsas prosesdir.
Tarix sinxronizasiyaçısı HistoryCache-dən dəyərlər götürür və hesablamalar üçün tetikleyiciler üçün Konfiqurasiyanı yoxlayır. Əgər onlar varsa - hesablayır.
Tarixçə sinxronlaşdırıcı hadisə yaradır, konfiqurasiya tələb etdiyi təqdirdə xəbərdarlıqlar yaratmaq üçün sürətlənir və qeydlər aparır. Sonrakı emal üçün tetikleyiciler varsa, tarix cədvəlinə istinad etməmək üçün bu dəyəri ValueCache-də xatırlayır. ValueCache tetikleyiciləri, hesablanmış maddələri hesablamaq üçün lazım olan məlumatlarla necə doldurulur.
Tarix sinxronlaşdırıcısı bütün məlumatları verilənlər bazasına yazır və diskə yazır. Emal prosesi burada başa çatır.
DB keşləmə
Qrafiklərə və ya hadisə hesabatlarına baxmaq istədiyiniz zaman DB tərəfində müxtəlif keşlər var:
Innodb_buffer_poolMySQL tərəfində;shared_buffersPostgreSQL tərəfində;effective_cache_sizeOracle tərəfində;shared_poolDB2 tərəfində.
Bir çox başqa keşlər var, lakin bunlar bütün verilənlər bazaları üçün əsas olanlardır. Onlar tez-tez sorğular üçün lazım olan məlumatları RAM-da saxlamağa imkan verir. Bunun üçün onların öz texnologiyaları var.
Verilənlər bazasının performansı vacibdir
Zabbix serveri daim məlumat toplayır və yazır. Yenidən işə salındıqda, ValueCache-ni doldurmaq üçün tarixdən də oxuyur. Skriptlər və hesabatlar istifadə edir Zabbix API, Web interfeysi əsasında qurulmuşdur. Zabbix API verilənlər bazasına daxil olur və qrafiklər, hesabatlar, hadisə siyahıları və son məsələlər üçün lazımi məlumatları əldə edir.
Vizuallaşdırma üçün - Qrafana. Bu, istifadəçilərimiz arasında məşhur bir həlldir. O, sorğuları birbaşa Zabbix API vasitəsilə və verilənlər bazasına göndərə bilər və məlumatların əldə edilməsi üçün müəyyən paralellik yaradır. Buna görə də, nəticələrin və testlərin sürətli çatdırılması üçün daha incə və daha yaxşı verilənlər bazası tənzimlənməsi lazımdır.
Təsərrüfat
Zabbix-də üçüncü performans problemi Housekeeper ilə tarixi təmizləməkdir. O, bütün parametrlərə hörmətlə yanaşır - məlumat elementləri dəyişikliklərin (trendlərin) dinamikasını günlərlə nə qədər saxlamağı göstərir.
TrendsCache biz tez hesablayırıq. Məlumat daxil olduqda, biz onları bir saat ərzində cəmləşdirir və trend dəyişikliklərinin dinamikası üçün cədvəllərə qoyuruq.
Ev işçisi adi "seçmələr" ilə məlumat bazasından məlumatları işə salır və silir. Bu, həmişə səmərəli deyil, bunu daxili proseslərin performans qrafiklərindən başa düşmək olar.
Qırmızı qrafik Tarix sinxronlaşdırıcısının daim məşğul olduğunu göstərir. Yuxarıdakı narıncı diaqram daim işləyən Housekeeper-dir. Verilənlər bazasının göstərdiyi bütün sətirləri silməsini gözləyir.
Housekeeper'ı nə vaxt söndürməlisiniz? Məsələn, "Eşya İD" var və müəyyən vaxt ərzində son 5 min sətri silmək lazımdır. Təbii ki, bu, indekslərlə baş verir. Ancaq adətən verilənlər bazası çox böyükdür və verilənlər bazası hələ də diskdən oxuyur və onu önbelleğe qoyur. Bu verilənlər bazası üçün həmişə çox bahalı əməliyyatdır və verilənlər bazasının ölçüsündən asılı olaraq performans problemlərinə səbəb ola bilər.
Ev işçisini söndürmək asandır. Veb interfeysində Housekeeper üçün "Ümumi İdarə" parametri var. Daxili trend tarixçəsi üçün daxili ev işlərini deaktiv edin və o, artıq buna nəzarət etmir.
Ev işçisi deaktiv edilib, qrafika düzəldilib - bu halda hansı problemlər ola bilər və üçüncü performans probleminin həllinə nə kömək edə bilər?
Bölmə - bölmə və ya bölmə
Bölmə adətən sadaladığım hər bir əlaqəli verilənlər bazasında fərqli şəkildə konfiqurasiya edilir. Hər birinin öz texnologiyası var, lakin ümumiyyətlə, oxşardırlar. Yeni bölmə yaratmaq çox vaxt müəyyən problemlərə gətirib çıxarır.
Tipik olaraq, bölmələr "quraşdırma" - bir gündə yaradılan məlumatların miqdarından asılı olaraq konfiqurasiya edilir. Bir qayda olaraq, bölmə bir gündə qurulur, bu minimumdur. Yeni bölmə meylləri üçün — 1 ay.
Çox böyük bir "quraşdırma" vəziyyətində dəyərlər dəyişə bilər. Kiçik bir "quraşdırma" 5 nvps-ə qədərdirsə (saniyədə yeni dəyərlər), orta hesabla 000-dən 5-ə qədərdirsə, böyük bir 000 nvps-dən yuxarıdır. Bunlar verilənlər bazasının özünün diqqətlə konfiqurasiyasını tələb edən böyük və çox böyük qurğulardır.
Çox böyük qurğularda bir gün optimal olmaya bilər. Gündə 40 GB və ya daha çox olan MySQL bölmələrini görmüşəm. Bu, problemlərə səbəb ola biləcək və azaldılmalı olan çox böyük miqdarda məlumatdır.
Bölməni nə verir?
Bölmə cədvəlləri. Çox vaxt bunlar diskdəki ayrı fayllardır. Sorğu planı bir bölməni daha optimal şəkildə seçir. Adətən bölmələr diapazona görə istifadə olunur - bu Zabbix üçün də keçərlidir. Biz orada "vaxt damğası"ndan istifadə edirik - dövrün əvvəlindən bəri. Normal nömrələrimiz var. Günün başlanğıcını və sonunu təyin edirsiniz - bu bir bölmədir.
Tez aradan qaldırılması - DELETE. Silinmək üçün sətir seçimi deyil, bir fayl/alt cədvəl seçilib.
Məlumatların seçilməsini əhəmiyyətli dərəcədə sürətləndirir SELECT - bütün cədvəldən deyil, bir və ya bir neçə bölmədən istifadə edir. Əgər siz iki günlük köhnə məlumatlara daxil olursunuzsa, o, onu verilənlər bazasından daha tez götürür, çünki siz onu yalnız önbelleğe yükləməlisiniz və böyük cədvəli deyil, yalnız bir faylı qaytarmalısınız.
Çox vaxt bir çox verilənlər bazası da sürətlənir INSERT - uşaq cədvəlinə daxil edir.
Zaman Ölçümü DB
v 4.2 üçün diqqətimizi TimescaleDB-yə çevirdik. Bu doğma interfeysi olan PostgreSQL uzantısıdır. Uzatma, əlaqəli verilənlər bazalarının üstünlüklərini itirmədən zaman seriyası məlumatları ilə səmərəli işləyir. TimescaleDB də avtomatik olaraq bölmələrə bölünür.
TimescaleDB-nin konsepsiyası var hipertable yaratdığınız (hipertable). İçində var parçalar - arakəsmələr. Parçalar digər fraqmentlərə təsir etməyən hiper cədvəlin avtomatik idarə olunan fraqmentləridir. Hər bir hissənin öz vaxt diapazonu var.
TimescaleDB vs PostgreSQL
TimescaleDB həqiqətən səmərəlidir. Genişlənmənin istehsalçıları daha düzgün sorğu emal alqoritmindən, xüsusən də inserts istifadə etdiklərini iddia edirlər. Verilənlər toplusunun ölçüsü artdıqca, alqoritm sabit performansı saxlayır.
200 milyon cərgədən sonra PostgreSQL adətən xeyli aşağı düşməyə başlayır və performansını 0-a qədər itirir. TimescaleDB sizə istənilən həcmdə məlumatla "daxiletmələri" səmərəli şəkildə daxil etməyə imkan verir.
Quraşdırma
TimescaleDB-nin quraşdırılması istənilən paket üçün kifayət qədər asandır. IN hər şey təfərrüatlıdır - bu, rəsmi PostgreSQL paketlərindən asılıdır. TimescaleDB də əl ilə tikilə və tərtib edilə bilər.
Zabbix verilənlər bazası üçün biz sadəcə olaraq genişləndirməni aktivləşdiririk:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
aktivləşdirin extension və onu Zabbix verilənlər bazası üçün yaradın. Son addım hipertable yaratmaqdır.
Tarix cədvəllərinin TimescaleDB-ə köçürülməsi
Bunun üçün xüsusi bir funksiya 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
Funksiya üç parametrə malikdir. Birinci - verilənlər bazasında cədvəlHipertable yaratmaq istədiyiniz. İkinci - sahə, buna uyğun olaraq yaratmaq lazımdır chunk_time_interval — istifadə olunacaq arakəsmə hissələrinin intervalı. Mənim vəziyyətimdə interval bir gündür - 86.
Üçüncü parametrdir migrate_data. Qurulsa true, sonra bütün cari məlumatlar əvvəlcədən yaradılmış parçalara ötürülür. Özüm istifadə etmişəm migrate_data. Bir saatdan çox vaxt aparan təxminən 1TB var idi. Hətta bəzi hallarda, sınaqdan keçirərkən saxlama üçün isteğe bağlı olan simvol növlərinin tarixi məlumatlarını köçürməmək üçün sildim.
Son addım - UPDATE: in db_extension qoy timescaledbbelə ki, verilənlər bazası bu uzantının olduğunu başa düşsün. Zabbix onu aktivləşdirir və artıq verilənlər bazasında olan sintaksis və sorğulardan düzgün istifadə edir - TimescaleDB üçün lazım olan xüsusiyyətlər.
Avadanlıq konfiqurasiyası
İki serverdən istifadə etdim. Birinci - VMware maşını. Kifayət qədər kiçikdir: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM və 200 GB SSD sürücüsü.
Debian OS 10.8-10.8.pgdg1+90 və xfs fayl sistemi ilə PostgreSQL 1 quraşdırdım. Mən Zabbix-in özünün istifadə edəcəyini çıxmaqla, bu verilənlər bazasından istifadə etmək üçün hər şeyi minimal şəkildə konfiqurasiya etdim.
Eyni maşında Zabbix server, PostgreSQL və var idi yük agentləri. Mənim istifadə edən 50 aktiv agentim var idi LoadableModuleçox tez müxtəlif nəticələr yaratmaq üçün: ədədlər, sətirlər. Mən verilənlər bazasını çoxlu məlumatlarla doldurdum.
Əvvəlcə konfiqurasiya ehtiva edirdi 5 element host başına məlumat. Demək olar ki, hər bir elementdə onun real quraşdırma kimi görünməsi üçün tetikleyici var idi. Bəzi hallarda birdən çox tətik var idi. Bir şəbəkə node var idi 3-000 tetikleyiciler.
Element yeniləmə intervalı − 4-7 saniyə. Mən yalnız 50 agentdən istifadə etməklə deyil, daha çox əlavə etməklə yükün özünü tənzimlədim. Həmçinin məlumat elementlərinin köməyi ilə yükü dinamik şəkildə tənzimlədim və yeniləmə intervalını 4 saniyəyə endirdim.
PostgreSQL. 35 nvps
Bu aparatdakı ilk işim təmiz PostgreSQL-də idi - saniyədə 35 min dəyər. Gördüyünüz kimi, məlumatların daxil edilməsi saniyənin bir hissəsini çəkir - hər şey yaxşı və sürətlidir. Yeganə odur ki, 200 GB SSD sürücüsü tez doldurulur.
Bu standart Zabbix server performans tablosudur.
Birinci mavi qrafik saniyədə dəyərlərin sayıdır. Sağdakı ikinci qrafik quraşdırma proseslərini yükləyir. Üçüncüsü, daxili quraşdırma proseslərinin yüklənməsidir: tarix sinxronlaşdırıcıları və burada uzun müddətdir işləyən Housekeeper.
Dördüncü qrafik HistoryCache istifadəsini göstərir. Bu verilənlər bazasına daxil edilməzdən əvvəl bir növ buferdir. Yaşıl beşinci qrafik ValueCache-in istifadəsini, yəni tetikleyiciler üçün neçə ValueCache hitinin saniyədə bir neçə min dəyər olduğunu göstərir.
PostgreSQL. 50 nvps
Sonra eyni aparatda yükü saniyədə 50 min dəyərə qədər artırdım.
Housekeeper-dən yükləyərkən 10 min dəyərin daxil edilməsi 2-3 saniyə çəkdi.
Ev işçisi artıq mane olmağa başlayır.
Üçüncü qrafik göstərir ki, ümumiyyətlə, trapperlərin və tarix sinxronlaşdırıcılarının yüklənməsi hələ də 60% səviyyəsindədir. Dördüncü qrafikdə Housekeeper-in işləməsi zamanı HistoryCache artıq aktiv şəkildə dolmağa başlayır. 20% doludur - təxminən 0,5 GB.
PostgreSQL. 80 nvps
Sonra yükü saniyədə 80 min dəyərə qədər artırdım. Bu, təxminən 400 min məlumat elementi və 280 min tetikleyicidir.
Otuz tarix sinxronlaşdırıcının yüklənməsi artıq kifayət qədər yüksəkdir.
Mən də müxtəlif parametrləri artırdım: tarix sinxronlaşdırıcıları, keşlər.
Aparatımda tarix sinxronlaşdırıcılarının yüklənməsi maksimuma yüksəldi. HistoryCache tez məlumatla dolduruldu - bufer emal üçün məlumat topladı.
Bütün bu müddət ərzində prosessor, RAM və digər sistem parametrlərinin necə istifadə edildiyini izlədim və diskdən istifadənin maksimum olduğunu gördüm.
istifadə etmişəm maksimum disk tutumu bu aparatda və bu virtual maşında. Belə bir intensivliklə PostgreSQL kifayət qədər aktiv şəkildə məlumatları boşaltmağa başladı və diskin artıq yazmağa və oxumağa vaxtı yox idi.
İkinci server
Artıq 48 prosessor və 128 GB RAM olan başqa bir server götürdüm. Mən onu köklədim - 60 tarix sinxronlaşdırıcısını təyin etdim və məqbul performansa nail oldum.
Əslində, bu, artıq bir şeyin edilməli olduğu bir performans həddidir.
vaxt miqyasıb. 80 nvps
Mənim əsas vəzifəm TimescaleDB-nin imkanlarını Zabbix yükü ilə sınaqdan keçirməkdir. Saniyədə 80 min dəyər çox şeydir, ölçüləri toplama tezliyi (əlbəttə ki, Yandex istisna olmaqla) və kifayət qədər böyük bir "quraşdırma".
Hər bir qrafikdə bir eniş var - bu, sadəcə məlumat köçürməsidir. Zabbix serverindəki uğursuzluqlardan sonra tarix sinxronlaşdırıcısının yükləmə profili çox dəyişdi - üç dəfə düşdü.
TimescaleDB sizə məlumatları demək olar ki, 3 dəfə daha sürətli daxil etməyə və daha az HistoryCache istifadə etməyə imkan verir.
Müvafiq olaraq, məlumatları vaxtında alacaqsınız.
vaxt miqyasıb. 120 nvps
Sonra məlumat elementlərinin sayını 500 minə çatdırdım.Əsas vəzifə TimescaleDB-nin imkanlarını yoxlamaq idi - saniyədə 125 min dəyər hesablanmış dəyər aldım.
Bu, işləmək üçün uzun müddət çəkə bilən işləyən "quraşdırma" dır. Amma diskim cəmi 1,5 TB olduğundan onu bir neçə günə doldurdum.
Ən əsası, eyni zamanda yeni TimescaleDB bölmələri yaradılırdı.
Performans üçün bu tamamilə nəzərə çarpmır. MySQL-də arakəsmələr yaradıldıqda, məsələn, hər şey fərqli olur. Bu, adətən gecə baş verir, çünki o, ümumi daxiletməni, cədvəllərlə işləməyi maneə törədir və xidmətin deqradasiyasına səbəb ola bilər. TimescaleDB ilə belə deyil.
Məsələn, mən icmada dəstdən bir qrafik göstərəcəyəm. Şəkildə TimescaleDB işə salınıb, bunun sayəsində prosessorda io.weight-dan istifadə yükü azalıb. Daxili proseslərin elementlərindən istifadə də azalıb. Üstəlik, bu SSD deyil, adi pancake disklərindəki adi virtual maşındır.
Tapıntılar
TimescaleDB kiçik "quraşdırmalar" üçün yaxşı bir həlldir, diskin performansına əsaslanan. Bu, verilənlər bazası daha sürətli aparatlara köçənə qədər yaxşı işləməyinizə imkan verəcək.
TimescaleDB qurmaq asandır, performansı artırır, Zabbix və ilə yaxşı işləyir PostgreSQL üzərində üstünlüklərə malikdir.
Əgər siz PostgreSQL-dən istifadə edirsinizsə və onu dəyişdirməyi planlaşdırmırsınızsa, o zaman tövsiyə edirəm Zabbix ilə birlikdə TimescaleDB genişləndirilməsi ilə PostgreSQL-dən istifadə edin. Bu həll orta "quraşdırma" qədər effektiv işləyir.
"Yüksək performans" deyirik - nəzərdə tuturuq . Xidmətlərin milyonlarla istifadəçiyə xidmət göstərməsinə imkan verən texnologiya və təcrübələrlə tanış olmanız çox çəkməyəcək. Siyahı 7 və 8 noyabr üçün biz artıq tərtib etmişik, lakin daha çox təklif edilə bilər.
Bizim kanalımıza abunə olun и , biz qarşıdan gələn konfransın xüsusiyyətlərini açıqlayırıq və ondan maksimum yararlanmağın yollarını öyrənirik.
Mənbə: www.habr.com