Zabbix мониторинг системасы болуп саналат. Башка системалар сыяктуу эле, ал бардык мониторинг системаларынын үч негизги көйгөйүнө дуушар болот: маалыматтарды чогултуу жана иштетүү, тарыхты сактоо жана аны тазалоо.
Маалыматтарды кабыл алуу, иштетүү жана жазуу этаптары убакытты талап кылат. Көп эмес, бирок чоң система үчүн бул чоң кечигүүлөргө алып келиши мүмкүн. Сактоо көйгөйү - бул маалыматтарга кирүү маселеси. Алар отчеттор, текшерүүлөр жана триггерлер үчүн колдонулат. Берилиштерге жетүүнүн кечигүүлөрү да майнаптуулукка таасирин тийгизет. Маалымат базалары чоңойгондо, тиешеси жок маалыматтар жок кылынышы керек. Алып салуу - бул татаал операция, ал дагы кээ бир ресурстарды жейт.
Заббиксте чогултуу жана сактоодо кечигүү көйгөйлөрү кэштөө жолу менен чечилет: кэштердин бир нече түрлөрү, маалымат базасындагы кэш. Үчүнчү маселени чечүү үчүн, кэштөө ылайыктуу эмес, ошондуктан Zabbix TimescaleDB колдонду. Ал сага бул тууралуу айтып берет Андрей Гущин - техникалык колдоо инженери . Андрей 6 жылдан ашык убакыттан бери Zabbixти колдоп келет жана аткаруу боюнча түздөн-түз тажрыйбасы бар.
TimescaleDB кантип иштейт, ал кадимки PostgreSQLге салыштырмалуу кандай көрсөткүчтөрдү бере алат? Zabbix TimescaleDB маалымат базасы үчүн кандай роль ойнойт? Кантип нөлдөн баштоо керек жана PostgreSQLден кантип өтүү керек жана кайсы конфигурациянын иштеши жакшыраак? Булардын бардыгы жөнүндө кесип астында.
Өндүрүмдүүлүктүн көйгөйлөрү
Ар бир мониторинг системасы конкреттүү аткаруу кыйынчылыктарга туш болот. Мен алардын үчөө жөнүндө сөз кылам: маалыматтарды чогултуу жана иштетүү, сактоо жана тарыхты тазалоо.
Маалыматтарды тез чогултуу жана иштетүү. Мониторингдин жакшы системасы бардык маалыматтарды тез кабыл алып, аны триггердик туюнтмаларга ылайык - анын критерийлерине ылайык иштетиши керек. Иштеп чыккандан кийин, система бул маалыматтарды кийинчерээк колдонуу үчүн маалымат базасына тез сактоосу керек.
Таржымал сактагыч. Мониторингдин жакшы системасы маалымат базасында тарыхты сактап, метрикага оңой жетүүнү камсыз кылышы керек. Тарых отчеттордо, графиктерде, триггерлерде, босоголордо жана эсептелген эскертүү берилиштеринде колдонулушу үчүн керек.
Таржымал тазалоо. Кээде көрсөткүчтөрдү сактоонун кереги жок болгон күн келет. Эмне үчүн сизге 5 жыл мурун, бир же эки ай мурун чогултулган маалыматтар керек: кээ бир түйүндөр жок кылынган, кээ бир хосттор же көрсөткүчтөр керек эмес, анткени алар эскирген жана чогултулбай калган. Жакшы мониторинг системасы тарыхый маалыматтарды сактоого жана маалымат базасы өсүп кетпеши үчүн, аны мезгил-мезгили менен жок кылышы керек.
Эскирген маалыматтарды тазалоо маалымат базасынын иштешине чоң таасирин тийгизген маанилүү маселе.
Zabbix'те кэштөө
Zabbixте биринчи жана экинчи чалуулар кэштин жардамы менен чечилет. RAM маалыматтарды чогултуу жана иштетүү үчүн колдонулат. Сактоо үчүн - триггерлердеги тарых, графиктер жана эсептелген маалымат элементтери. Берилиштер базасы тарабында негизги тандоолор үчүн кэш бар, мисалы, графиктер.
Zabbix серверинин капталындагы кэштөө:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Аларды кененирээк карап көрөлү.
ConfigurationCache
Бул биз метрикаларды, хостторду, маалымат элементтерин, триггерлерди - PreProcessing жана маалыматтарды чогултуу үчүн керектүү нерселердин бардыгын сактаган негизги кэш.
Мунун баары маалымат базасында керексиз суроону жаратпоо үчүн ConfigurationCache ичинде сакталат. Сервер ишке киргенден кийин, биз бул кэшти жаңыртабыз, конфигурацияларды түзөбүз жана мезгил-мезгили менен жаңыртабыз.
Маалымат чогултуу
Диаграмма абдан чоң, бирок андагы негизги нерсе теримчилер. Булар ар кандай "суроочулар" - чогултуу процесстери. Алар чогулуштун ар кандай түрлөрү үчүн жооптуу: алар SNMP, IPMI аркылуу маалыматтарды чогултуп, баарын PreProcessingге өткөрүп беришет.
Коллекторлор кызгылт сары түстө белгиленген.
Zabbix текшерүүлөрдү бириктирүү үчүн зарыл болгон топтоо элементтерин эсептеп чыкты. Эгер алар бизде болсо, биз алар үчүн маалыматтарды түздөн-түз ValueCacheтен алабыз.
Preprocessing HistoryCache
Бардык коллекторлор жумуш алуу үчүн ConfigurationCache колдонушат. Андан кийин аларды PreProcessingге өткөрүп беришет.
PreProcessing PreProcessing кадамдарын алуу үчүн ConfigurationCache колдонот. Бул маалыматтарды ар кандай жолдор менен иштетет.
PreProcessing аркылуу берилиштерди иштеткенден кийин, биз аны иштетүү үчүн HistoryCache сактайбыз. Бул маалыматтарды чогултууну аяктайт жана биз Zabbix'теги негизги процесске өтөбүз - тарых синсер, ал монолиттүү архитектура болгондуктан.
Эскертүү: PreProcessing өтө татаал операция. v 4.2 менен ал проксиге көчүрүлдү. Эгер сизде көп сандагы маалымат элементтери жана жыйноо жыштыгы менен абдан чоң Zabbix болсо, анда бул ишти бир топ жеңилдетет.
ValueCache, тарых жана тренддер кэши
Тарых синсери - бул ар бир маалымат элементин, башкача айтканда, ар бир маанини атомдук түрдө иштеткен негизги процесс.
Тарых синхрончу HistoryCache'ден маанилерди алып, Конфигурацияны эсептөөлөр үчүн триггерлердин бар-жоктугун текшерет. Алар бар болсо, анда ал эсептейт.
Тарых синхрончу окуяны, конфигурация талап кылса, эскертүүлөрдү түзүү үчүн эскалацияны жана жазууларды түзөт. Эгер кийинки иштетүү үчүн триггерлер бар болсо, анда ал тарых таблицасына кирбөө үчүн бул маанини ValueCache ичинде сактайт. ValueCache триггерлерди жана эсептелген элементтерди эсептөө үчүн зарыл болгон маалыматтар менен ушундайча толтурулат.
History syncer бардык маалыматтарды маалымат базасына жазат жана ал дискке жазат. Бул жерде иштетүү процесси аяктайт.
Маалымат базасында кэштөө
Окуялар боюнча графиктерди же отчетторду көргүңүз келгенде, маалымат базасынын тарабында ар кандай кэштер бар:
Innodb_buffer_poolMySQL тарабында;shared_buffersPostgreSQL тарабында;effective_cache_sizeOracle тарапта;shared_poolDB2 тарабында.
Башка көптөгөн кэштер бар, бирок булар бардык маалымат базалары үчүн негизгиси. Алар көбүнчө сурамдар үчүн зарыл болгон оперативдүү эстутумда маалыматтарды сактоого мүмкүндүк берет. Бул үчүн алардын өз технологиялары бар.
Берилиштер базасынын иштеши маанилүү
Zabbix сервери дайыма маалыматтарды чогултат жана аны жазат. Кайра иштетилгенде, ал ValueCache толтуруу үчүн тарыхтан да окуйт. Скрипттерди жана отчетторду колдонот Zabbix API, ал веб-интерфейсте курулган. Zabbix API маалымат базасына кирип, графиктер, отчеттор, окуялар тизмеси жана акыркы маселелер үчүн керектүү маалыматтарды алат.
Визуализация үчүн - Графана. Бул биздин колдонуучулар арасында популярдуу чечим болуп саналат. Ал түздөн-түз Zabbix API аркылуу жана маалымат базасына суроо-талаптарды жөнөтө алат жана маалыматтарды алуу үчүн белгилүү бир атаандаштыкты жаратат. Ошондуктан, натыйжаларды жана тестирлөөнү тез жеткирүү үчүн маалымат базасын жакшыраак жана жакшыраак жөндөө керек.
Оксана
Zabbix'теги үчүнчү тапшырма - бул Housekeeper аркылуу тарыхты тазалоо. Ал бардык орнотууларды ээрчийт - маалымат элементтери күн ичинде өзгөрүүлөрдүн (тенденциялардын) динамикасын канча убакытка чейин сактоону көрсөтөт.
Биз TrendsCache'ди учуп эсептейбиз. Маалыматтар келгенде, биз аны бир саатка топтоп, тенденциянын өзгөрүү динамикасы үчүн таблицаларга жазабыз.
Үй кызматчысы кадимки "тандоолорду" колдонуп, маалымат базасынан маалыматты баштайт жана жок кылат. Бул дайыма эле эффективдүү боло бербейт, муну ички процесстердин эффективдүү графиктеринен көрүүгө болот.
Кызыл график Тарых синсери дайыма бош эмес экенин көрсөтүп турат. Жогору жактагы кызгылт сары түстөгү график тынымсыз иштеп турган Housekeeper болуп саналат. Ал маалымат базасы өзү көрсөткөн бардык саптарды жок кылышын күтөт.
Үй кызматкерин качан өчүрүү керек? Мисалы, "Item ID" бар жана белгилүү бир убакыттын ичинде акыркы 5 миң сапты жок кылышыңыз керек. Албетте, бул индекс боюнча болот. Бирок, адатта, маалымат топтому абдан чоң жана маалымат базасы дагы эле дисктен окуп, кэшке салат. Бул ар дайым маалымат базасы үчүн өтө кымбат операция жана маалымат базасынын көлөмүнө жараша, аткаруу көйгөйлөрүнө алып келиши мүмкүн.
Үй кызматчысын өчүрүү оңой. Веб-интерфейсте үй кызматчысы үчүн "Жалпы администрация" параметри бар. Ички тренд таржымалы үчүн ички чарбалык иштерди өчүрөбүз жана ал мындан ары аны башкара албайт.
Үй кызматчысы өчүрүлдү, графиктер түздөлдү - бул учурда кандай көйгөйлөр болушу мүмкүн жана үчүнчү аткаруу көйгөйүн чечүүгө эмне жардам берет?
Бөлүү - бөлүү же бөлүү
Адатта, бөлүү мен санаган ар бир реляциялык маалымат базасында башка жол менен конфигурацияланат. Ар биринин өзүнүн технологиясы бар, бирок алар жалпысынан окшош. Жаңы бөлүмдү түзүү көбүнчө белгилүү бир көйгөйлөргө алып келет.
Адатта, бөлүмдөр "орнотууга" жараша конфигурацияланат - бир күндө түзүлгөн маалыматтардын көлөмү. Эреже катары, бөлүү бир күндүн ичинде чыгарылат, бул минималдуу. Жаңы партиянын тенденциялары үчүн - 1 ай.
"Орнотуу" өтө чоң болсо, баалуулуктар өзгөрүшү мүмкүн. Эгерде кичинекей "орнотуу" 5 nvps (секундасына жаңы маанилер) болсо, орточосу 000ден 5ге чейин болсо, чоңу 000 nvps жогору. Бул базанын кылдат конфигурациясын талап кылган чоң жана өтө чоң орнотуулар.
Өтө чоң орнотууларда бир күндүк мөөнөт оптималдуу болбой калышы мүмкүн. Мен күнүнө 40 ГБ же андан көп MySQL бөлүктөрүн көрдүм. Бул көйгөйлөрдү жаратышы мүмкүн болгон маалыматтардын өтө чоң көлөмү жана азайтылышы керек.
Бөлүү эмне берет?
Бөлүү үстөлдөрү. Көбүнчө булар дисктеги өзүнчө файлдар. Сурам планы бир бөлүмдү оптималдуураак тандайт. Адатта бөлүү диапазон боюнча колдонулат - бул Zabbix үчүн да туура. Биз ал жерде "убакыт белгисин" колдонобуз - доордун башынан бери. Бул биз үчүн жөнөкөй сандар. Сиз күндүн башталышын жана аягын койдуңуз - бул бөлүү.
Тез алып салуу - DELETE. Жок кылуу үчүн саптардын тандоосу эмес, бир файл/субтаблица тандалды.
Маалыматтарды издөөнү кыйла тездетет SELECT - бүт таблицаны эмес, бир же бир нече бөлүмдөрдү колдонот. Эгерде сиз эки күндүк маалыматтарга кирип жатсаңыз, ал маалымат базасынан тезирээк чыгарылат, анткени сиз кэшке бир гана файлды жүктөшүңүз керек жана чоң таблица эмес, аны кайтарышыңыз керек.
Көп учурда көптөгөн маалымат базалары да тездетилген INSERT — балдар үстөлүнө киргизүү.
TimescaleDB
V 4.2 үчүн биз TimescaleDBге көңүл бурдук. Бул жергиликтүү интерфейс менен PostgreSQL үчүн кеңейтүү. Кеңейтүү реляциялык маалымат базаларынын артыкчылыктарын жоготпостон, убакыт серияларынын маалыматтары менен эффективдүү иштейт. TimescaleDB да автоматтык түрдө бөлүнөт.
TimescaleDB концепциясы бар гипертаблица (гипертивдүү) сиз жараткан. Камтыйт бөлүктөр - бөлүктөр. Бөлүктөр башка фрагменттерге таасирин тийгизбеген автоматтык түрдө башкарылуучу гипертаблица фрагменттери. Ар бир бөлүктүн өзүнүн убакыт диапазону бар.
TimescaleDB vs PostgreSQL
TimescaleDB чынында эле натыйжалуу иштейт. Кеңейтүүнү өндүрүүчүлөр талапты иштетүү алгоритмин, атап айтканда, inserts колдонушат деп ырасташат. Берилиштер топтому кыстаруу көлөмү чоңойгон сайын, алгоритм туруктуу иштешин сактайт.
200 миллион саптан кийин PostgreSQL демейде бир топ ылдыйлай баштайт жана 0гө чейин иштешин жоготот. TimescaleDB сизге каалаган көлөмдөгү маалыматтарды эффективдүү киргизүүгө мүмкүндүк берет.
жөндөө
TimescaleDB орнотуу ар кандай пакет үчүн абдан жеңил. IN баары майда-чүйдөсүнө чейин сүрөттөлгөн - бул расмий PostgreSQL пакеттерине көз каранды. TimescaleDB да кол менен курулуп, түзүлүшү мүмкүн.
Zabbix маалымат базасы үчүн биз жөн гана кеңейтүүнү иштетебиз:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Сиз активдештиресиз extension жана Zabbix маалымат базасы үчүн түзүңүз. Акыркы кадам гипертаблица түзүү болуп саналат.
Таржымал таблицаларын TimescaleDBге көчүрүү
Бул үчүн атайын функция бар 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
Функциянын үч параметри бар. Алгачкы - маалымат базасындагы таблица, ал үчүн сиз гипертаблица түзүшүңүз керек. Экинчи - талаа, ага ылайык сиз түзүү керек chunk_time_interval — колдонула турган бөлүү бөлүктөрүнүн аралыгы. Менин учурда, интервал бир күн - 86 400.
Үчүнчү параметр - migrate_data. Эгер орнотсоңуз true, анда бардык учурдагы маалыматтар алдын ала түзүлгөн бөлүктөргө өткөрүлүп берилет. Мен аны өзүм колдондум migrate_data. Менде болжол менен 1 ТБ бар болчу, ал бир сааттан ашык убакытты алды. Ал тургай, кээ бир учурларда, тестирлөө учурунда, мен аларды өткөрүп жибербөө үчүн, сактоо үчүн талап кылынбаган тамга түрлөрүнүн тарыхый маалыматтарын жок кылдым.
Акыркы кадам - UPDATE:-жылы db_extension коюу timescaledbмаалымат базасы бул кеңейтүү бар экенин түшүнүшү үчүн. Zabbix аны иштетет жана синтаксисин жана маалымат базасына суроо-талаптарды туура колдонот - TimescaleDB үчүн зарыл болгон функциялар.
Аппараттык конфигурация
Мен эки серверди колдондум. Алгачкы - VMware машинасы. Бул абдан кичинекей: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 ГГц процессорлору, 16 ГБ оперативдик эс жана 200 ГБ SSD.
Мен ага PostgreSQL 10.8ди Debian 10.8-1.pgdg90+1 OS жана xfs файл системасы менен орноттум. Мен бул белгилүү маалымат базасын колдонуу үчүн бардыгын минималдуу түрдө конфигурацияладым, минус Zabbix өзү колдоно турган нерсе.
Ошол эле машинада Zabbix сервери, PostgreSQL жана бар болчу жүк агенттери. Менде 50 активдүү агенттер бар болчу LoadableModuleабдан тез ар кандай натыйжаларды түзүү үчүн: сандар, саптар. Мен базаны көп маалыматтар менен толтурдум.
Башында конфигурация камтылган 5 000 элемент ар бир хост үчүн маалымат. Дээрлик ар бир элемент аны чыныгы орнотууларга окшош кылуу үчүн триггерди камтыган. Кээ бир учурларда бирден ашык триггер болгон. Бир тармак түйүнү үчүн бар болчу 3-000 триггер.
Берилиштер пунктун жаңыртуу аралыгы − 4-7 секунд. Мен 50 агентти гана эмес, дагы кошуу менен жүктүн өзүн жөнгө салдым. Ошондой эле, маалымат элементтерин колдонуу менен, мен жүктөмдү динамикалык түрдө тууралап, жаңыртуу аралыгын 4 секундага чейин кыскарттым.
PostgreSQL. 35 nvps
Бул жабдыкта менин биринчи жолум таза PostgreSQLде болгон - секундасына 35 миң маани. Көрүнүп тургандай, маалыматтарды киргизүү секунданын бөлчөктөрүн талап кылат - баары жакшы жана тез. Бир гана нерсе, 200 ГБ SSD диск тез толот.
Бул Zabbix серверинин стандарттык башкаруу панели.
Биринчи көк график секундасына маанилердин саны болуп саналат. Оң жактагы экинчи график - куруу процесстеринин жүктөлүшү. Үчүнчүсү ички куруу процесстерин жүктөйт: тарых синхрондору жана бул жерде бир топ убакыттан бери иштеп жаткан Housekeeper.
Төртүнчү график HistoryCache колдонулушун көрсөтөт. Бул маалымат базасына киргизүүдөн мурун буфердин бир түрү. Жашыл бешинчи график ValueCache колдонулушун көрсөтөт, башкача айтканда, триггерлер үчүн канча ValueCache соккулары - бул секундасына бир нече миң маани.
PostgreSQL. 50 nvps
Андан кийин мен ошол эле жабдыкта жүктү секундасына 50 миң мааниге чейин жогорулаттым.
Housekeeper'ден жүктөөдө 10 миң маанини киргизүү 2-3 секундду талап кылды.
Үй кызматчысы эмитен эле ишке кийлигише баштады.
Үчүнчү график, жалпысынан, трапперлерге жана тарых синхерлерине жүктөлгөн жүк дагы эле 60% экенин көрсөтүп турат. Төртүнчү графикте HistoryCache Housekeeper операциясы учурунда активдүү түрдө толтура баштады. Ал 20% толду, бул болжол менен 0,5 ГБ.
PostgreSQL. 80 nvps
Андан кийин мен жүктөмдү секундасына 80 миң мааниге чейин жогорулаттым. Бул болжол менен 400 миң маалымат элементтери жана 280 миң триггерлер.
Отуз тарых синхерлеринин жүктөө баасы буга чейин эле жогору.
Мен ошондой эле ар кандай параметрлерди жогорулатты: тарых синхерлер, кэштер.
Менин аппараттык камсыздоомдо тарых синхрондорунун жүктөлүшү максималдуу көбөйдү. HistoryCache тез маалыматтар менен толтурулат - иштетүү үчүн маалыматтар буферде топтолгон.
Ушул убакыттын ичинде мен процессордун, оперативдүү эс тутумдун жана башка системанын параметрлеринин кандайча колдонулганын байкадым жана дискти колдонуу максималдуу экенин байкадым.
колдонууга жетиштим максималдуу диск мүмкүнчүлүктөрү бул жабдыкта жана бул виртуалдык машинада. Ушундай интенсивдүүлүк менен PostgreSQL маалыматтарды жигердүү жууп баштады, ал эми дисктин жазууга жана окууга убактысы болбой калды.
Экинчи сервер
Мен башка серверди алдым, анда 48 процессор жана 128 ГБ оперативдик эс тутум бар. Мен аны жөндөп койдум - аны 60 тарых синсерине койдум жана алгылыктуу аткарууга жетиштим.
Чынында, бул бир нерсе кылуу керек болгон өндүрүмдүүлүктүн чеги.
TimescaleDB. 80 nvps
Менин негизги милдетим - Zabbix жүктөмүнө каршы TimescaleDB мүмкүнчүлүктөрүн сыноо. Секундасына 80 миң маани - бул көп, метрикаларды чогултуу жыштыгы (албетте, Яндекстен тышкары) жана бир кыйла чоң "орнотуу".
Ар бир графикте төмөндөө бар - бул так маалымат миграциясы. Zabbix сервериндеги мүчүлүштүктөрдөн кийин, тарых синхераторунун жүктөө профили бир топ өзгөрдү - ал үч жолу төмөндөдү.
TimescaleDB сизге маалыматтарды дээрлик 3 эсе тезирээк киргизүүгө жана HistoryCache азыраак колдонууга мүмкүндүк берет.
Демек, сиз маалыматтарды өз убагында аласыз.
TimescaleDB. 120 nvps
Андан кийин мен маалымат элементтеринин санын 500 миңге чейин көбөйткөм.Негизги милдет TimescaleDB мүмкүнчүлүктөрүн текшерүү болду - мен секундасына 125 миң мааниге ээ болдум.
Бул узак убакыт бою иштей турган жумушчу "орнотуу" болуп саналат. Бирок менин диским болгону 1,5 ТБ болгондуктан, аны бир-эки күндө толтурдум.
Эң негизгиси, ошол эле учурда жаңы TimescaleDB бөлүмдөрү түзүлдү.
Бул аткаруу үчүн таптакыр байкалбайт. Бөлүмдөр MySQLде түзүлгөндө, мисалы, баары башкача болот. Бул, адатта, түн ичинде болот, анткени ал жалпы киргизүүнү, таблицалар менен иштөөнү жана кызматтын начарлашын жаратышы мүмкүн. Бул TimescaleDB менен болгон эмес.
Мисал катары, мен коомчулуктагы көптөгөн адамдардын бир диаграммасын көрсөтөм. Сүрөттө TimescaleDB иштетилген, анын аркасында процессорго io.weight колдонуу жүктөмү төмөндөдү. Ички процесстин элементтерин пайдалануу да кыскарды. Анын үстүнө, бул SSD эмес, кадимки куймак дисктериндеги кадимки виртуалдык машина.
табылгалары
TimescaleDB кичинекей "орнотуу" үчүн жакшы чечим болуп саналат, бул дисктин иштешине таасир этет. Бул маалымат базасы мүмкүн болушунча тезирээк жабдыкка көчүрүлгөнгө чейин жакшы иштөөгө мүмкүндүк берет.
TimescaleDB конфигурациялоо оңой, өндүрүмдүүлүктү жогорулатат, Zabbix жана менен жакшы иштейт PostgreSQLге караганда артыкчылыктарга ээ.
Эгер сиз PostgreSQL колдонсоңуз жана аны өзгөртүүнү пландабасаңыз, мен сунуштайм Zabbix менен бирге TimescaleDB кеңейтүүсү менен PostgreSQL колдонуңуз. Бул чечим орточо "орнотууга" чейин натыйжалуу иштейт.
Биз "жогорку көрсөткүчтөр" дегенди билдирет . Миллиондогон колдонуучуларды тейлөөгө мүмкүнчүлүк берген технологиялар жана тажрыйбалар жөнүндө билүү үчүн көп күтө албайсыз. Тизме 7 жана 8-ноябрь үчүн биз буга чейин түзгөнбүз, бирок бул жерде дагы сунуш кылууга болот.
Биздин каналга жазылыңыз и , анда биз алдыда боло турган конференциянын өзгөчөлүктөрүн ачып, андан максималдуу пайда алуунун жолдорун билебиз.
Source: www.habr.com