Дараагийн HighLoad++ бага хурал 6 оны 7-р сарын 2020, XNUMX-нд Санкт-Петербургт болно Дэлгэрэнгүй мэдээлэл, тасалбар . HighLoad++ Москва 2018. “Москва” танхим. 9 сарын 15 00:XNUMX. Дипломууд болон .
* Хяналт - онлайн болон аналитик.
* ZABBIX платформын үндсэн хязгаарлалтууд.
* Аналитик хадгалалтын хэмжээг нэмэгдүүлэх шийдэл.
* ZABBIX серверийг оновчтой болгох.
* UI оновчлол.
* 40к NVPS-ээс дээш ачаалалтай системийг ажиллуулж байсан туршлагатай.
* Товч дүгнэлт.
Михаил Макуров (цаашид - ММ): - Бүгдээрээ сайн уу!
Максим Чернецов (цаашид - MCH): - Өдрийн мэнд!
ММ: -Би Максимыг танилцуулъя. Макс бол авъяаслаг инженер, миний мэдэх хамгийн шилдэг сүлжээчин. Максим нь сүлжээ, үйлчилгээ, тэдгээрийн хөгжил, үйл ажиллагаанд оролцдог.
MCH: - Би та нарт Михаилын тухай хэлмээр байна. Михаил бол C программист. Тэрээр манай компанид зориулж ачаалал ихтэй замын хөдөлгөөний боловсруулалтын хэд хэдэн шийдлүүдийг бичсэн. Бид Уралд, Челябинск хотод, Интерсвязь компанид ажиллаж, амьдардаг. Манай компани нь 16 хотын нэг сая хүнд интернэт, кабелийн телевизийн үйлчилгээ үзүүлдэг.
ММ: Интерсвяз бол зүгээр л үйлчилгээ үзүүлэгч биш, мэдээллийн технологийн компани гэдгийг хэлэх нь зүйтэй болов уу. Манай ихэнх шийдлүүдийг манай мэдээллийн технологийн хэлтэс хийдэг.
БОЛОН: траффик боловсруулдаг серверүүдээс дуудлагын төв болон гар утасны програм хүртэл. Мэдээллийн технологийн хэлтэс нь одоо маш олон янзын чадвартай 80 орчим хүнтэй.
Zabbix болон түүний архитектурын тухай
MCH: - Одоо би хувийн дээд амжилт тогтоож, нэг минутын дотор Заббикс (цаашид "Заббикс" гэх) гэж юу болохыг хэлэхийг хичээх болно.
Zabbix нь өөрийгөө аж ахуйн нэгжийн түвшний хяналтын систем гэж үздэг. Энэ нь амьдралыг хөнгөвчлөх олон боломжуудтай: дэвшилтэт шатлалын дүрэм, нэгтгэх API, хост болон хэмжигдэхүүнийг бүлэглэх, автоматаар илрүүлэх. Zabbix-д масштабаар тооцох хэрэгсэл гэж нэрлэгддэг прокси байдаг. Zabbix бол нээлттэй эхийн систем юм.
Архитектурын талаар товчхон. Энэ нь гурван бүрэлдэхүүн хэсгээс бүрддэг гэж бид хэлж чадна.
- Сервер. C дээр бичсэн. Сэдвүүдийн хооронд мэдээлэл боловсруулах, дамжуулах нь нэлээд төвөгтэй байдаг. Бүх боловсруулалт үүн дотор явагддаг: хүлээн авахаас эхлээд мэдээллийн санд хадгалах хүртэл.
- Бүх өгөгдөл мэдээллийн санд хадгалагддаг. Zabbix MySQL, PostreSQL болон Oracle-г дэмждэг.
- Вэб интерфэйс нь PHP хэл дээр бичигдсэн. Ихэнх системүүд дээр энэ нь Apache сервертэй хамт ирдэг боловч nginx + php-тэй хослуулан илүү үр дүнтэй ажилладаг.
Өнөөдөр бид Zabbix-тэй холбоотой компанийнхаа амьдралаас нэг түүхийг ярихыг хүсч байна ...
Интерсвязь компанийн амьдралын түүх. Бидэнд юу байгаа, юу хэрэгтэй вэ?
5, 6 сарын өмнө. Ажлын дараа нэг өдөр...
MCH: - Миша, сайн уу! Чамайг барьж чадсандаа баяртай байна - яриа байна. Бидэнд дахин хяналт тавих асуудал гарлаа. Томоохон ослын үед бүх зүйл удаашралтай байсан бөгөөд сүлжээний төлөв байдлын талаар мэдээлэл алга. Харамсалтай нь энэ нь анхны тохиолдол биш юм. Надад өөрийн чинь тусламж хэрэгтэй байна. Ямар ч нөхцөлд хяналтаа ажиллуулцгаая!
ММ: - Гэхдээ эхлээд синхрончлол хийцгээе. Хэдэн жилийн турш би тийшээ харсангүй. Миний санаж байгаагаар бид Нагиосыг орхиж, 8 жилийн өмнө Заббикс руу шилжсэн. Одоо бид 6 хүчирхэг сервер, арав орчим прокситэй болсон бололтой. Би ямар нэг юм андуураад байна уу?
MCH: - Бараг л. 15 сервер, тэдгээрийн зарим нь виртуал машин юм. Хамгийн гол нь бидэнд хамгийн хэрэгтэй байгаа тэр мөчид энэ нь биднийг аврахгүй байх явдал юм. Осол шиг - серверүүд удааширч, та юу ч харахгүй. Бид тохиргоог оновчтой болгохыг оролдсон боловч энэ нь гүйцэтгэлийн оновчтой өсөлтийг хангаж чадаагүй юм.
ММ: - Энэ нь тодорхой байна. Та ямар нэг юм үзсэн үү, оношилгооноос ямар нэгэн зүйл ухаж авсан уу?
MCH: – Хамгийн түрүүнд хийх ёстой зүйл бол мэдээллийн сан. MySQL-г байнга ачаалж, шинэ хэмжүүрүүдийг хадгалдаг бөгөөд Zabbix олон үйл явдал үүсгэж эхлэхэд мэдээллийн сан хэдхэн цагийн турш хэт ачаалалтай ажилладаг. Тохиргоог оновчтой болгох талаар би аль хэдийн хэлсэн боловч энэ жил тэд техник хангамжийг шинэчилсэн: серверүүд SSD RAID дээр зуу гаруй гигабайт санах ой, дискний массивтай болсон - үүнийг урт хугацаанд шугаман байдлаар өсгөх нь утгагүй юм. Бид юу хийх вэ?
ММ: - Энэ нь тодорхой байна. Ерөнхийдөө MySQL бол LTP мэдээллийн сан юм. Энэ нь манай хэмжээтэй хэмжүүрийн архивыг хадгалахад тохиромжгүй болсон бололтой. Үүнийг олж мэдье.
MCH: - Явцгаая!
Hackathon-ийн үр дүнд Zabbix болон Clickhouse-ийг нэгтгэсэн
Хэсэг хугацааны дараа бид сонирхолтой мэдээлэл хүлээн авлаа:
Манай мэдээллийн сангийн ихэнх зайг хэмжүүрийн архив эзэлдэг байсан бөгөөд 1% хүрэхгүй хувийг тохиргоо, загвар, тохиргоонд ашигласан. Тэр үед бид Clickhouse дээр суурилсан Big Data шийдлийг жил гаруйн хугацаанд ажиллуулж байсан. Хөдөлгөөний чиглэл нь бидэнд тодорхой байсан. Манай хаврын Hackathon дээр би Zabbix-ийг Clickhouse-тай сервер болон урд хэсэгт нэгтгэхийг бичсэн. Тэр үед Zabbix аль хэдийн ElasticSearch-ийг дэмждэг байсан бөгөөд бид тэдгээрийг харьцуулахаар шийдсэн.
Clickhouse болон Elasticsearch-ийн харьцуулалт
ММ: – Харьцуулахын тулд бид Zabbix серверийн өгдөгтэй ижил ачааллыг үүсгэж, системүүд хэрхэн ажиллахыг харлаа. Бид өгөгдлийг CURL ашиглан 1000 мөрийн багцаар бичсэн. Clickhouse нь Zabbix-ийн ачааллын профайлд илүү үр дүнтэй байх болно гэж бид урьдчилан таамаглаж байсан. Үр дүн нь бидний хүлээлтээс ч давсан:
Туршилтын ижил нөхцөлд Clickhouse гурав дахин их мэдээлэл бичсэн. Үүний зэрэгцээ хоёр систем нь өгөгдлийг уншихдаа маш үр дүнтэй (бага хэмжээний нөөц) зарцуулдаг. Гэхдээ Elastics нь бичлэг хийхдээ их хэмжээний процессор шаарддаг:
Нийтдээ Clickhouse нь процессорын хэрэглээ болон хурдны хувьд Elastix-ээс хамаагүй илүү байсан. Үүний зэрэгцээ, өгөгдөл шахалтын улмаас Clickhouse нь хатуу диск дээр 11 дахин бага ашигладаг бөгөөд ойролцоогоор 30 дахин бага дискний үйлдлийг гүйцэтгэдэг.
MCH: - Тийм ээ, Clickhouse-ийн дискний дэд системтэй ажиллах нь маш үр дүнтэй хэрэгждэг. Та мэдээллийн санд зориулж асар том SATA диск ашиглаж, секундэд хэдэн зуун мянган мөр бичих хурдыг авах боломжтой. Бэлэн болсон систем нь хуваах, хуулбарлахыг дэмждэг бөгөөд тохируулахад маш хялбар байдаг. Жилийн турш ашиглахад бид илүү их сэтгэл хангалуун байдаг.
Нөөцийг оновчтой болгохын тулд та одоо байгаа үндсэн өгөгдлийн сангийнхаа хажууд Clickhouse-г суулгаж, CPU-ийн цаг болон дискний үйл ажиллагааг ихээхэн хэмнэж болно. Бид хэмжүүрүүдийн архивыг одоо байгаа Clickhouse кластерууд руу шилжүүлсэн:
Бид үндсэн MySQL мэдээллийн санг маш их хөнгөвчилсөн тул үүнийг нэг машин дээр Zabbix сервертэй нэгтгэж, MySQL-д зориулсан тусгай серверээс татгалзаж чадсан.
Zabbix-д санал хураалт хэрхэн явагддаг вэ?
4 сарын өмнө
ММ: – За, баазтай холбоотой асуудлыг мартаж болох уу?
MCH: - Энэ нь гарцаагүй! Бидний шийдвэрлэх өөр нэг асуудал бол мэдээлэл цуглуулах удаашрал юм. Одоо манай бүх 15 прокси серверүүд SNMP болон санал асуулгын процессоор хэт ачаалалтай байна. Мөн шинэ болон шинэ сервер суулгахаас өөр арга байхгүй.
ММ: - Агуу их. Гэхдээ эхлээд Zabbix-д санал хураалт хэрхэн явагддагийг бидэнд хэлээч?
MCH: – Товчхондоо 20 төрлийн хэмжүүр, тэдгээрийг олж авах арваад арга байдаг. Zabbix нь "хүсэлт-хариу" горимд өгөгдөл цуглуулах эсвэл "Trapper Interface"-ээр дамжуулан шинэ өгөгдөл хүлээж авах боломжтой.
Анхны Zabbix-д энэ арга (Trapper) хамгийн хурдан гэдгийг тэмдэглэх нь зүйтэй.
Ачааллыг хуваарилах прокси серверүүд байдаг:
Прокси нь Zabbix сервертэй ижил цуглуулах функцийг гүйцэтгэж, түүнээс даалгавруудыг хүлээн авч, цуглуулсан хэмжигдэхүүнийг Trapper интерфейсээр дамжуулан илгээх боломжтой. Энэ бол ачааллыг хуваарилах албан ёсоор санал болгож буй арга юм. Прокси нь NAT эсвэл удаан сувгаар ажиллаж байгаа алсын дэд бүтцийг хянахад хэрэгтэй:
ММ: – Архитектурын хувьд бүх зүйл ойлгомжтой. Бид эх сурвалжийг харах хэрэгтэй ...
Хэдэн өдрийн дараа
Nmap fping хэрхэн ялсан тухай түүх
ММ: "Би ямар нэг юм ухсан гэж бодож байна."
MCH: - Надад хэлээч!
ММ: – Боломжтой эсэхийг шалгахдаа Zabbix нэг удаад дээд тал нь 128 хостыг шалгадаг болохыг олж мэдсэн. Би энэ тоог 500 болгож, тэдгээрийн ping (ping) дэх пакет хоорондын интервалыг арилгахыг оролдсон - энэ нь гүйцэтгэлийг хоёр дахин нэмэгдүүлсэн. Гэхдээ би илүү их тоог хүсч байна.
MCH: – Миний практикт би заримдаа мянга мянган хостуудын бэлэн байдлыг шалгах шаардлагатай болдог бөгөөд үүний тулд nmap-аас илүү хурдан зүйлийг хэзээ ч харж байгаагүй. Энэ бол хамгийн хурдан арга гэдэгт би итгэлтэй байна. Оролдоод үзье! Бид давталт бүрт хостуудын тоог мэдэгдэхүйц нэмэгдүүлэх шаардлагатай байна.
ММ: – Таван зуу гаруй шалгах уу? 600?
MCH: - Дор хаяж хоёр мянга.
ММ: - БОЛЖ БАЙНА УУ. Миний хэлэхийг хүссэн хамгийн чухал зүйл бол Заббикс дахь ихэнх санал асуулга синхроноор явагддаг болохыг олж мэдсэн. Бид үүнийг асинхрон горимд шилжүүлэх нь гарцаагүй. Дараа нь бид санал асуулгад оролцогчдын цуглуулсан хэмжүүрүүдийн тоог эрс нэмэгдүүлэх боломжтой, ялангуяа бид давталт бүрт хэмжүүрийн тоог нэмэгдүүлбэл.
MCH: - Агуу их! Тэгээд хэзээ?
ММ: - Ердийнх шигээ өчигдөр.
MCH: – Бид fping болон nmap хоёр хувилбарыг харьцуулсан:
Олон тооны хостууд дээр nmap нь тав дахин илүү үр дүнтэй байх төлөвтэй байсан. Nmap нь зөвхөн бэлэн байдал болон хариу өгөх хугацааг шалгадаг тул бид алдагдлын тооцоог триггер рүү шилжүүлж, бэлэн байдлыг шалгах интервалыг мэдэгдэхүйц багасгасан. Бид nmap-д зориулсан хамгийн оновчтой хостуудын тоог нэг давталт тутамд 4 мянга орчим гэж олсон. Nmap нь CPU-ийн бэлэн байдлын шалгалтын зардлыг 120 дахин бууруулж, интервалыг 10 секундээс XNUMX болгон багасгах боломжийг бидэнд олгосон.
Санал асуулгын оновчлол
ММ: "Дараа нь бид санал асуулга явуулж эхэлсэн. Бид SNMP илрүүлэх болон агентуудыг голчлон сонирхож байсан. Zabbix-д санал хураалтыг синхроноор явуулдаг бөгөөд системийн үр ашгийг нэмэгдүүлэх тусгай арга хэмжээ авсан. Синхрон горимд хостын боломжгүй байдал нь санал хураалтыг ихээхэн доройтуулдаг. Бүхэл бүтэн муж улсын систем байдаг, тусгай процессууд байдаг - хүрч болохгүй санал асуулга гэж нэрлэгддэг, зөвхөн хүрч болохгүй хостуудтай ажилладаг.
Энэ бол тогтолцоог үр дүнтэй байлгахын тулд шаардлагатай шилжилтийн системийн бүх нарийн төвөгтэй байдлыг харуулсан төрийн матрицыг харуулсан тайлбар юм. Нэмж дурдахад синхрон санал асуулга өөрөө нэлээд удаан байдаг:
Тийм ч учраас олон арван прокси дээрх олон мянган санал асуулга нь бидэнд шаардлагатай хэмжээний өгөгдлийг цуглуулж чадаагүй юм. Асинхрон хэрэгжүүлэлт нь хэлхээний тоотой холбоотой асуудлуудыг шийдээд зогсохгүй, боломжгүй хостуудын төлөвийн системийг ихээхэн хялбаршуулсан, учир нь санал асуулгын нэг давталтаар шалгагдсан аль ч тооны хувьд хүлээх хамгийн дээд хугацаа нь 1 завсарлагатай байв.
Нэмж дурдахад бид SNMP хүсэлтийн санал авах системийг өөрчилж, сайжруулсан. Ихэнх хүмүүс олон SNMP хүсэлтэд нэгэн зэрэг хариу өгөх боломжгүй байдаг. Тиймээс, ижил хостын SNMP санал асинхроноор хийгдсэн үед бид эрлийз горимыг хийсэн.
Энэ нь бүх хостуудын багцад хийгддэг. Энэ горим нь эцсийн дүндээ бүрэн асинхрон горимоос удаан биш юм, учир нь нэг хагас зуун SNMP утгыг санал хураах нь 1 завсарлагаас хамаагүй хурдан хэвээр байна.
Бидний туршилтууд нэг давталт дахь хүсэлтийн оновчтой тоо нь SNMP санал асуулгаар ойролцоогоор 8 мянга болохыг харуулсан. Нийтдээ асинхрон горимд шилжсэнээр санал хураалтын гүйцэтгэлийг 200 дахин, хэдэн зуун дахин хурдасгах боломж олгосон.
MCH: – Санал хураалтын үр дүнгийн оновчлол нь бид бүх проксигоос ангижрахаас гадна олон шалгалтын интервалыг багасгаж, ачааллыг хуваалцах арга болгон прокси хэрэггүй болохыг харуулсан.
Гурван сар орчмын өмнө
Архитектурыг өөрчил - ачааллыг нэмэгдүүл!
ММ: - За, Макс, үр бүтээлтэй болох цаг нь болсон уу? Надад хүчирхэг сервер, сайн инженер хэрэгтэй байна.
MCH: -За, төлөвлөчихье. Секундэд 5 мянган хэмжигдэхүүнтэй үхэх цэгээс шилжих цаг нь болсон.
Шинэчлэлтийн дараах өглөө
MCH: - Миша, бид өөрсдийгөө шинэчилсэн боловч өглөө гэхэд бид буцаад эргэв ... Бид ямар хурдтай болж чадсаныг таагаарай?
ММ: - дээд тал нь 20 мянга.
MCH: - Тийм ээ, 25! Харамсалтай нь бид эхлүүлсэн газраа л байна.
ММ: -Яагаад? Та ямар нэгэн оношилгоо хийсэн үү?
MCH: - Тийм ээ, мэдээж! Жишээлбэл, энд сонирхолтой топ байна:
ММ: - Харцгаая. Бид маш олон тооны санал асуулгын хэлхээг туршиж үзсэнийг би харж байна:
Гэхдээ тэр үед тэд системийг хагас дахин боловсруулж чадаагүй:
Мөн ерөнхий гүйцэтгэл нь маш бага, секундэд 4 мянган хэмжигдэхүүн:
Өөр зүйл байна уу?
MCH: -Тийм ээ, санал асуулгад оролцогчдын нэг нь:
ММ: – Эндээс санал хураах үйл явц “семафор” хүлээж байгааг тод харж байна. Эдгээр нь цоожнууд юм:
MCH: - Тодорхойгүй.
ММ: – Хараач, энэ нь олон тооны утаснууд нэг удаад зөвхөн нэг л ажиллах боломжтой нөөцтэй ажиллахыг оролдож байгаа нөхцөл байдалтай төстэй юм. Дараа нь тэдний хийж чадах зүйл бол энэ нөөцийг цаг хугацааны явцад хуваалцах явдал юм:
Ийм нөөцтэй ажиллах нийт гүйцэтгэл нь нэг цөмийн хурдаар хязгаарлагддаг.
Энэ асуудлыг шийдэх хоёр арга бий.
Машины техник хангамжийг сайжруулж, илүү хурдан цөм рүү шилжинэ үү:
Эсвэл архитектурыг өөрчилж, нэгэн зэрэг ачааллыг өөрчил:
MCH: - Дашрамд хэлэхэд, туршилтын машин дээр бид байлдааныхаас цөөн цөм ашиглах болно, гэхдээ тэдгээр нь нэг цөмд давтамжаараа 1,5 дахин хурдан байдаг!
ММ: - Тодорхой байна уу? Та серверийн кодыг харах хэрэгтэй.
Zabbix сервер дэх өгөгдлийн зам
MCH: - Үүнийг олж мэдэхийн тулд бид Zabbix сервер дотор өгөгдөл хэрхэн дамждаг талаар дүн шинжилгээ хийж эхэлсэн.
Сайхан зураг, тийм үү? Үүнийг илүү тодорхой болгохын тулд алхам алхмаар явцгаая. Мэдээлэл цуглуулах үүрэгтэй хэлхээнүүд болон үйлчилгээнүүд байдаг:
Тэд цуглуулсан хэмжигдэхүүнийг залгуураар Препроцессорын менежер рүү дамжуулж, дараалалд хадгалдаг.
"Процессорын менежер" нь ажилчдадаа өгөгдлийг дамжуулдаг бөгөөд тэдгээр нь урьдчилсан боловсруулалтын зааврыг гүйцэтгэж, ижил залгуураар буцааж өгдөг.
Үүний дараа урьдчилсан процессорын менежер тэдгээрийг түүхийн кэшэд хадгалдаг:
Тэндээс тэдгээрийг түүхийг шингээгч нар авдаг бөгөөд тэд маш олон функцийг гүйцэтгэдэг: жишээлбэл, триггерийг тооцоолох, утгын кэшийг дүүргэх, хамгийн чухал нь түүхийн санах ойд хэмжигдэхүүнийг хадгалах. Ерөнхийдөө үйл явц нь нарийн төвөгтэй бөгөөд маш ойлгомжгүй байдаг.
ММ: – Бидний харсан хамгийн эхний зүйл бол ихэнх хэлхээнүүд “тохиргооны кэш” гэж нэрлэгддэг (бүх серверийн тохиргоог хадгалдаг санах ойн хэсэг) төлөө өрсөлддөг. Мэдээлэл цуглуулах үүрэгтэй утаснууд ялангуяа маш их блоклодог:
... учир нь тохиргоо нь зөвхөн хэмжигдэхүүнүүдийг параметрийн хамт хадгалаад зогсохгүй санал асуулгад оролцогчдын дараа юу хийх талаар мэдээлэл авах дарааллыг хадгалдаг. Олон санал асуулга байгаа бөгөөд нэг нь тохиргоог блоклодог бол бусад нь хүсэлтийг хүлээж байна:
Санал асуулгад оролцогчид зөрчилдөх ёсгүй
Тиймээс бидний хийсэн хамгийн эхний зүйл бол дарааллыг 4 хэсэгт хувааж, санал асуулгад оролцогчдод эдгээр дарааллыг, эдгээр хэсгүүдийг аюулгүй нөхцөлд нэгэн зэрэг хаахыг зөвшөөрсөн юм.
Энэ нь тохиргооны кэшийн өрсөлдөөнийг арилгаж, санал асуулгын хурд мэдэгдэхүйц нэмэгдсэн. Гэхдээ дараа нь бид урьдчилсан процессорын менежер ажлын дарааллыг хуримтлуулж эхэлсэнтэй тулгарсан.
Урьдчилан боловсруулагч менежер тэргүүлэх ач холбогдол өгөх чадвартай байх ёстой
Энэ нь түүний гүйцэтгэл хангалтгүй байсан тохиолдолд тохиолдсон. Дараа нь түүний хийж чадах цорын ганц зүйл бол өгөгдөл цуглуулах процессуудын хүсэлтийг цуглуулж, бүх санах ойг дуустал буферийг нэмэх явдал байв:
Энэ асуудлыг шийдэхийн тулд бид ажилчдад тусгайлан зориулсан хоёр дахь залгуурыг нэмсэн.
Тиймээс, урьдчилсан процессорын менежер өөрийн ажлыг эрэмбэлэх боломжтой байсан бөгөөд хэрэв буфер томорвол зайлуулах ажлыг удаашруулж, ажилчдад энэ буферийг авах боломжийг олгоно.
Дараа нь бид ажил удаашралын нэг шалтгаан нь ажилчид өөрсдөө, учир нь тэд өөрсдийн ажилд огт хамаагүй нөөцийн төлөө өрсөлдөж байгааг олж мэдсэн. Бид энэ асуудлыг алдааны засвар болгон баримтжуулсан бөгөөд энэ нь Zabbix-ийн шинэ хувилбаруудад аль хэдийн шийдэгдсэн:
Бид залгууруудын тоог нэмэгдүүлдэг - бид үр дүнг авдаг
Цаашилбал, препроцессорын менежер өөрөө нэг урсгалтай тул гацаа болж хувирав. Энэ нь үндсэн хурд дээр тулгуурласан бөгөөд секундэд 70 мянга орчим хэмжигдэхүүн хурдыг өгдөг.
Тиймээс бид дөрвөн залгууртай дөрвөн ажилчин хийсэн:
Энэ нь бидэнд хурдыг ойролцоогоор 130 мянган хэмжигдэхүүн болгон нэмэгдүүлэх боломжийг олгосон:
Өсөлтийн шугаман бус байдлыг түүхийн кэшийн төлөөх өрсөлдөөн бий болсонтой холбон тайлбарлаж байна. Үүний төлөө 4 урьдчилсан процессорын менежер, түүхийг шингээгч өрсөлдсөн. Энэ үед бид туршилтын машин дээр секундэд ойролцоогоор 130 мянган хэмжигдэхүүнийг хүлээн авч байсан бөгөөд үүнийг процессорын ойролцоогоор 95% ашиглаж байна.
2,5 сарын өмнө
Snmp-нийтлэлээс татгалзсан нь NVP-ийг нэг ба хагас дахин нэмэгдүүлсэн
ММ: – Макс, надад шинэ туршилтын машин хэрэгтэй байна! Бид одоогийнхтойгоо тохирохоо больсон.
MCH: -Танд одоо юу байгаа вэ?
ММ: – Одоо – 130k NVP болон тавиур дээр бэлэн процессор.
MCH: - Хөөх! Гайхалтай! Хүлээгээрэй, надад хоёр асуулт байна. Миний тооцоогоор бол бидний хэрэгцээ секундэд 15-20 мянган хэмжигдэхүүн байна. Яагаад бидэнд илүү их хэрэгтэй байна вэ?
ММ: "Би ажлаа дуусгамаар байна." Энэ тогтолцооноос хэр их шахагдаж чадахыг хармаар байна.
MCH: -Гэхдээ...
ММ: "Гэхдээ энэ нь бизнест ашиггүй юм."
MCH: - Энэ нь тодорхой байна. Хоёрдахь асуулт: Бид одоо байгаа зүйлээ хөгжүүлэгчийн тусламжгүйгээр бие даан дэмжиж чадах уу?
ММ: - Би бодохгүй байна. Тохиргооны кэш хэрхэн ажилладагийг өөрчлөх нь асуудал юм. Энэ нь ихэнх утаснуудын өөрчлөлтөд нөлөөлдөг бөгөөд засвар үйлчилгээ хийхэд нэлээд хэцүү байдаг. Хамгийн магадлалтай, үүнийг хадгалах нь маш хэцүү байх болно.
MCH: "Тэгвэл бидэнд өөр хувилбар хэрэгтэй."
ММ: -Тийм хувилбар бий. Бид цоожны шинэ системээс татгалзаж, хурдан цөм рүү шилжих боломжтой. Бид 60-80 мянган хэмжүүрийн гүйцэтгэлийг авах болно. Үүний зэрэгцээ бид үлдсэн бүх кодыг үлдээж болно. Clickhouse болон асинхрон санал асуулга ажиллах болно. Мөн засвар үйлчилгээ хийхэд хялбар байх болно.
MCH: - Гайхалтай! Би энд зогсохыг санал болгож байна.
Серверийн талыг оновчтой болгосны дараа бид эцэст нь шинэ кодыг үйлдвэрлэлд нэвтрүүлж чадсан. Бид хурдан цөмтэй машин руу шилжих, кодын өөрчлөлтийн тоог багасгахын тулд зарим өөрчлөлтийг орхисон. Мөн бид тохиргоог хялбарчилж, нэмэлт түгжээг нэвтрүүлж байгаа учир өгөгдлийн хэсгүүдийн макрог хассан.
Жишээлбэл, баримт бичиг, жишээн дээр ихэвчлэн олддог snmp-нийтийн макрог орхих нь манай тохиолдолд NVP-ийг 1,5 дахин хурдасгах боломжтой болсон.
Үйлдвэрлэлд хоёр хоногийн дараа
Ослын түүхийн попапуудыг устгаж байна
MCH: - Миша, бид системийг хоёр өдрийн турш ашиглаж байна, бүх зүйл ажиллаж байна. Гэхдээ бүх зүйл ажиллахад л! Бид сүлжээний нэлээд том хэсгийг шилжүүлэх ажлыг төлөвлөж байсан бөгөөд юу нь дээшилж, юу нь болоогүйг гараараа дахин шалгасан.
ММ: - Болохгүй! Бид бүгдийг 10 удаа шалгасан. Сүлжээний бүрэн боломжгүй байдлыг ч сервер шууд зохицуулдаг.
MCH: - Тийм ээ, би бүгдийг ойлгож байна: сервер, мэдээллийн сан, дээд, аустат, бүртгэлүүд - бүх зүйл хурдан ... Гэхдээ бид вэб интерфэйсийг харвал сервер дээр "тавиурт" процессор байгаа бөгөөд энэ нь:
ММ: - Энэ нь тодорхой байна. Вэбийг харцгаая. Олон тооны идэвхтэй үйл явдал гарсан нөхцөлд ихэнх шууд виджетүүд маш удаан ажиллаж эхэлснийг бид олж мэдсэн:
Үүний шалтгаан нь жагсаалтын зүйл бүрт үүссэн ослын түүхийн попап цонхыг бий болгосон явдал байв. Тиймээс бид эдгээр цонхыг үүсгэхээс татгалзсан (код дахь 5 мөрийг тайлбарласан) бөгөөд энэ нь бидний асуудлыг шийдсэн.
Виджетүүдийг ачаалах хугацааг бүрэн ашиглах боломжгүй байсан ч хэдэн минутаас бидний хувьд зөвшөөрөгдөх 10-15 секунд хүртэл бууруулсан бөгөөд цаг дээр дарснаар түүхийг харах боломжтой хэвээр байна:
Ажлын дараа. 2 сарын өмнө
MCH: - Миша, чи явах уу? Бид ярилцах ёстой.
ММ: -Би тэгэх бодолгүй байсан. Заббикстэй дахиад ямар нэг зүйл байна уу?
MCH: - Үгүй ээ, тайвшир! Би зүгээр л хэлэхийг хүссэн: бүх зүйл ажилладаг, баярлалаа! Би шар айраг авсан.
Zabbix үр дүнтэй
Zabbix бол нэлээд түгээмэл бөгөөд баялаг систем, функц юм. Үүнийг хайрцагнаас гадуур жижиг суулгацуудад ашиглаж болох боловч хэрэгцээ нэмэгдэхийн хэрээр үүнийг оновчтой болгох шаардлагатай болдог. Том хэмжүүрийн архивыг хадгалахын тулд тохиромжтой хадгалах санг ашиглана уу:
- та Elasticsearch-тэй нэгтгэх эсвэл текст файлд түүхийг байршуулах хэлбэрээр суулгасан хэрэгслүүдийг ашиглаж болно (XNUMX-р хувилбараас авах боломжтой);
- Та Clickhouse-тай манай туршлага, интеграцийн давуу талыг ашиглах боломжтой.
Хэмжилтийг цуглуулах хурдыг эрс нэмэгдүүлэхийн тулд тэдгээрийг асинхрон аргаар цуглуулж, трапперийн интерфейсээр дамжуулан Zabbix сервер рүү дамжуулах; эсвэл та Zabbix санал асуулгыг асинхрон болгохын тулд нөхөөсийг ашиглаж болно.
Zabbix нь C хэл дээр бичигдсэн бөгөөд нэлээд үр дүнтэй байдаг. Архитектурын хэд хэдэн саад бэрхшээлийг шийдвэрлэх нь түүний гүйцэтгэлийг цаашид нэмэгдүүлэх боломжийг олгодог бөгөөд бидний туршлагаас харахад нэг процессортой машин дээр 100 мянга гаруй хэмжигдэхүүнийг олж авах боломжтой.
Үүнтэй ижил Zabbix засвар
ММ: -Би хоёр зүйлийг нэмж хэлмээр байна. Одоогийн тайланг бүхэлд нь, бүх тест, тоонуудыг бидний ашигладаг тохиргоонд зориулж өгсөн болно. Одоо бид үүнээс секундэд ойролцоогоор 20 мянган хэмжүүр авч байна. Хэрэв та энэ нь танд тохирох эсэхийг ойлгохыг оролдож байгаа бол харьцуулж болно. Өнөөдөр хэлэлцсэн зүйлийг GitHub дээр нөхөөс хэлбэрээр нийтэлсэн болно.
Нүхэнд дараахь зүйлс орно.
- Clickhouse-тай бүрэн нэгтгэх (Zabbix сервер болон урд талын аль аль нь);
- урьдчилсан процессорын менежертэй холбоотой асуудлыг шийдвэрлэх;
- асинхрон санал асуулга.
Уг нөхөөс нь lts-г оруулаад бүх 4-р хувилбартай нийцдэг. Хамгийн бага өөрчлөлт хийснээр энэ нь 3.4 хувилбар дээр ажиллах болно.
Анхаарал тавьсан та бүхэнд баярлалаа.
Асуултууд
Үзэгчдийн асуулт (цаашид – А): – Өдрийн мэнд! Надад хэлээч, энэ нь засвар биш, харин Zabbix-ийн хэвийн зан байдал байхын тулд танд Zabbix багтай эсвэл тэдэнтэй эрчимтэй харилцах төлөвлөгөө байгаа юу?
ММ: - Тийм ээ, бид зарим өөрчлөлтийг хийх нь гарцаагүй. Ямар нэг зүйл тохиолдох болно, ямар нэг зүйл нөхөөсөнд үлдэх болно.
БОЛОН: - Маш сайн илтгэл тавьсанд маш их баярлалаа! Засварыг хэрэглэсний дараа Zabbix-ийн дэмжлэг хэвээр үлдэх бөгөөд илүү дээд хувилбар руу хэрхэн шинэчлэх вэ? Заббиксийг засвар хийсний дараа 4.2, 5.0 болгож шинэчлэх боломжтой юу?
ММ: -Би дэмжлэгийн талаар юу ч хэлж чадахгүй. Хэрэв би Zabbix-ийн техникийн дэмжлэг байсан бол би үгүй гэж хэлэх байсан, учир нь энэ бол хэн нэгний код юм. 4.2 кодын баазын хувьд бидний байр суурь: "Бид цаг хугацааны явцад шилжих болно, бид дараагийн хувилбар дээр өөрсдийгөө шинэчлэх болно." Тиймээс бид хэсэг хугацаанд шинэчлэгдсэн хувилбаруудын нөхөөсийг нийтлэх болно. Би тайланд аль хэдийн хэлсэн: хувилбаруудын өөрчлөлтийн тоо маш бага хэвээр байна. 3.4-ээс 4-т шилжихэд 15 минут зарцуулсан гэж бодож байна.Тэнд ямар нэг зүйл өөрчлөгдсөн, гэхдээ тийм ч чухал биш.
БОЛОН: – Тэгэхээр та засвараа дэмжихээр төлөвлөж байгаа бөгөөд үүнийг үйлдвэрлэлд аюулгүй суулгаж, ирээдүйд ямар нэгэн байдлаар шинэчлэлтүүдийг хүлээн авах боломжтой юу?
ММ: - Бид үүнийг маш их зөвлөж байна. Энэ нь бидний хувьд маш олон асуудлыг шийдэж байна.
MCH: – Архитектурт хамааралгүй, блоклох, дараалалд хамааралгүй өөрчлөлтүүд нь модульчлагдсан, тусдаа модулиудад байгаа гэдгийг дахин хэлмээр байна. Хэдийгээр бага зэргийн өөрчлөлтүүд ч гэсэн та тэдгээрийг маш амархан хадгалж чадна.
ММ: – Хэрэв та дэлгэрэнгүй мэдээллийг сонирхож байгаа бол "Clickhouse" нь түүхийн номын санг ашигладаг. Энэ нь тайлагдсан - энэ нь Elastics дэмжлэгийн хуулбар юм, өөрөөр хэлбэл үүнийг тохируулах боломжтой. Санал хураалт нь зөвхөн санал авагчдыг өөрчилдөг. Энэ нь удаан хугацаанд ажиллана гэдэгт бид итгэж байна.
БОЛОН: - Маш их баярлалаа. Надад хэлээч, оруулсан өөрчлөлтийн баримт бичиг байгаа юу?
ММ: – Баримт бичиг бол нөхөөс юм. Мэдээжийн хэрэг, Clickhouse-ийг нэвтрүүлж, шинэ төрлийн санал асуулга нэвтрүүлснээр шинэ тохиргооны сонголтууд гарч ирдэг. Сүүлийн слайд дээрх холбоос нь үүнийг хэрхэн ашиглах талаар товч тайлбартай байна.
fping-г nmap-ээр солих тухай
БОЛОН: -Та үүнийг эцэст нь хэрхэн хэрэгжүүлсэн бэ? Та тодорхой жишээ хэлж чадах уу: танд оосор, гадаад скрипт байгаа юу? Ийм асар олон тооны хостуудыг маш хурдан шалгаж байгаа нь юу вэ? Та эдгээр хостуудыг хэрхэн олборлодог вэ? Бид тэднийг ямар нэгэн байдлаар nmap-д тэжээх, хаа нэгтээгээс авах, оруулах, ажиллуулах шаардлагатай юу?..
ММ: - Сайхан байна. Маш зөв асуулт! Гол нь энэ. Бид номын санг (ICMP ping, Zabbix-ийн хэсэг) ICMP шалгахад зориулж өөрчилсөн бөгөөд энэ нь багцын тоог зааж өгдөг - нэг (1) бөгөөд код нь nmap ашиглахыг оролддог. Энэ нь пингерийн дотоод ажил болсон Zabbix-ийн дотоод ажил юм. Үүний дагуу синхрончлол эсвэл хавчуур ашиглах шаардлагагүй. Энэ нь системийг бүрэн бүтэн байлгахын тулд зориудаар хийгдсэн бөгөөд хоёр мэдээллийн сангийн системийг синхрончлох шаардлагагүй: юу шалгах, санал асуулгад оруулах, бидний байршуулалт эвдэрсэн үү?.. Энэ нь илүү хялбар юм.
БОЛОН: – Энэ нь прокси-д бас ажилладаг уу?
ММ: - Тийм ээ, гэхдээ бид шалгаагүй. Санал авах код нь Zabbix болон серверийн аль алинд нь ижил байна. Ажиллах ёстой. Дахин нэг удаа онцолж хэлье: системийн гүйцэтгэл нь бидэнд прокси хэрэггүй.
MCH: – Асуултын зөв хариулт нь: "Яагаад ийм системтэй прокси хэрэгтэй байна вэ?" Зөвхөн NAT эсвэл ямар нэг удаашралтай сувгаар хянадаг учраас л...
БОЛОН: - Хэрэв би зөв ойлговол та Zabbix-ийг харшил үүсгэгч болгон ашигладаг. Эсвэл таны графикийг (архивын давхарга байгаа газар) Grafana гэх мэт өөр систем рүү шилжүүлсэн үү? Эсвэл та энэ функцийг ашиглахгүй байна уу?
ММ: - Би дахин нэг удаа онцолж хэлье: бид бүрэн интеграцчилалд хүрсэн. Бид Clickhouse-д түүхийг оруулж байгаа ч үүнтэй зэрэгцэн php-ийн урд хэсгийг өөрчилсөн. Php frontend нь Clickhouse руу орж бүх графикийг тэндээс хийдэг. Үүний зэрэгцээ, үнэнийг хэлэхэд, бид ижил Clickhouse, ижил Zabbix өгөгдлөөс бусад график дэлгэцийн системд өгөгдөл үүсгэдэг хэсэгтэй.
MCH: -“Графан”-д ч гэсэн.
Нөөц хуваарилах талаар ямар шийдвэр гаргасан бэ?
БОЛОН: – Гал тогооныхоо дотоод заслыг бага зэрэг хуваалцаарай. Бүтээгдэхүүнийг нухацтай боловсруулахад нөөцийг хуваарилах шаардлагатай гэсэн шийдвэрийг хэрхэн гаргасан бэ? Эдгээр нь ерөнхийдөө тодорхой эрсдэлүүд юм. Та шинэ хувилбаруудыг дэмжих гэж байгаатай холбогдуулан надад хэлээч: менежментийн үүднээс энэ шийдвэр ямар үндэслэлтэй вэ?
ММ: -Түүхийн жүжгийг бид сайн хэлж чадаагүй бололтой. Бид ямар нэгэн зүйл хийх ёстой нөхцөл байдалд орж, үндсэндээ хоёр зэрэгцээ багтай явсан:
- Нэг нь шинэ аргуудыг ашиглан хяналтын системийг эхлүүлсэн: үйлчилгээ болгон мониторинг хийх, бидний нэгтгэсэн нээлттэй эхийн шийдлүүдийн стандарт багц, дараа нь шинэ хяналтын системтэй ажиллахын тулд бизнесийн үйл явцыг өөрчлөхийг оролддог.
- Үүний зэрэгцээ бид үүнийг хийж байсан урам зоригтой програмисттай байсан (өөрийнхөө тухай). Тэр ялсан нь ийм болсон.
БОЛОН: -Багийн бүрэлдэхүүн хэд вэ?
MCH: - Тэр чиний өмнө байна.
БОЛОН: -Тэгэхээр танд урьдын адил хүсэл тэмүүлэлтэй хүн хэрэгтэй байна уу?
ММ: -Би хүсэл тэмүүлэлтэй хүн гэж юу байдгийг мэдэхгүй.
БОЛОН: - Энэ тохиолдолд та бололтой. Маш их баярлалаа, чи гайхалтай юм.
ММ: - Баярлалаа.
Zabbix-д зориулсан засваруудын тухай
БОЛОН: – Прокси ашигладаг системийн хувьд (жишээ нь, зарим тархсан системд) санал асуулга, прокси болон Zabbix-ийн хэсэгчлэн урьдчилан боловсруулагчийг тохируулах, нөхөх боломжтой юу; болон тэдний харилцан үйлчлэл? Олон прокситэй системд одоо байгаа хөгжүүлэлтийг оновчтой болгох боломжтой юу?
ММ: – Zabbix серверийг прокси ашиглан угсардаг гэдгийг би мэднэ (кодыг эмхэтгэж, авсан). Бид үүнийг үйлдвэрлэлд туршиж үзээгүй. Би энэ талаар сайн мэдэхгүй байна, гэхдээ проксид урьдчилан процессорын менежерийг ашигладаггүй гэж би бодож байна. Проксины үүрэг бол Zabbix-ээс олон тооны хэмжигдэхүүнийг авч, нэгтгэх (энэ нь тохиргоо, локал мэдээллийн санг бүртгэдэг) болон Zabbix серверт буцааж өгөх явдал юм. Дараа нь сервер өөрөө хүлээн авахдаа урьдчилсан боловсруулалтыг хийх болно.
Төлөөлөгчийн сонирхол нь ойлгомжтой. Бид шалгах болно. Энэ бол сонирхолтой сэдэв юм.
БОЛОН: – Санаа нь ийм байсан: хэрвээ та санал асуулгыг нөхөж чадвал тэдгээрийг прокси дээр нөхөж, сервертэй харилцах харилцааг нөхөж, урьдчилан процессорыг эдгээр зорилгоор зөвхөн сервер дээр тохируулж болно.
ММ: - Би үүнийг бүр энгийн гэж бодож байна. Та кодыг авч, нөхөөсийг ашиглаад шаардлагатай байдлаар тохируулаарай - прокси серверүүдийг (жишээлбэл, ODBC-тэй) цуглуулж, засварласан кодыг системд тараана. Шаардлагатай бол - прокси, шаардлагатай бол сервер цуглуул.
БОЛОН: - Та сервер рүү прокси дамжуулалтыг нэмэлт засварлах шаардлагагүй болов уу?
MCH: -Үгүй ээ, энэ бол стандарт.
ММ: – Үнэндээ нэг санаа нь сонсогдоогүй. Бид санаа бодлын тэсрэлт, өөрчлөлтийн хэмжээ, дэмжлэгийн хялбар байдал хоёрын тэнцвэрийг үргэлж хадгалж ирсэн.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com