Наступна конференція HighLoad++ пройде 6 та 7 квітня 2020 року в Санкт-Петербурзі Подробиці та квитки . HighLoad++ Moscow 2018. Зал "Москва". 9 листопада, 15. Тези та .
* Моніторинг - онлайн та аналітика.
* Основні обмеження платформи ZABBIX.
* Рішення для масштабування сховища аналітики.
* Оптимізація сервера ZABBIX.
* Оптимізація UI.
* Досвід експлуатації системи при навантаженні понад 40k NVPS.
* Коротко висновки.
Михайло Макуров (далі – ММ): - Всім привіт!
Максим Чернецов (далі – МЧ): - Добридень!
ММ: - Дозвольте мені уявити Максима. Макс – талановитий інженер, найкращий сітовик, якого я знаю. Максим займається мережами та сервісами, їх розвитком та експлуатацією.
МЧ: – А я хотів би розповісти про Михайла. Михайло – розробник на Сі. Він написав кілька високонавантажених рішень щодо обробки трафіку для нашої компанії. Ми живемо та працюємо на Уралі, у місті суворих мужиків Челябінську, у компанії «Інтерзв'язок». Наша компанія – це постачальник послуг інтернету та кабельного телебачення для одного мільйона людей у 16 містах.
ММ: - І варто сказати, що "Інтерзв'язок" - набагато більше, ніж просто провайдер, це IT-компанія. Більшість наших рішень зроблено силами нашого ІТ-відділу.
А: від серверів, що обробляють трафік, до колл-центру та мобільного додатка. В IT-відділі зараз близько 80 осіб з дуже різноманітними компетенціями.
Про Zabbix та його архітектуру
МЧ: - А тепер я спробую поставити особистий рекорд і за одну хвилину сказати, що ж таке Zabbix (далі - Заббікс).
Заббікс позиціонує себе як систему моніторингу «з коробки» рівня підприємства. У ньому є багато функцій, що спрощують життя: розвинені правила ескалації, API для інтеграції, угруповання і автовиявлення хостів і метрик. У Заббікс є так звані засоби масштабування - проксі. "Заббікс" - це система з відкритим вихідним кодом.
Коротко про архітектуру. Можна сказати, вона складається із трьох компонентів:
- Сервер Написаний на Сі. З досить складною обробкою та передачею інформації між потоками. Вся обробка відбувається в ньому: від отримання до збереження до бази.
- Усі дані зберігаються у базі. Заббікс підтримує MySQL, PostreSQL і Oracle.
- Веб-інтерфейс написано на PHP. У більшості систем поставляється з сервером Apache, але ефективніше працює у зв'язці nginx + php.
Сьогодні ми хотіли б розповісти з життя нашої компанії одну історію, пов'язану із «Заббікс»…
Історія з життя компанії "Інтерзв'язок". Що маємо та що потрібно?
5 або 6 місяців тому. Якось після роботи…
МЧ: - Мишко, привіт! Радий, що встиг тебе впіймати – є розмова. У нас знову були проблеми із моніторингом. Під час великої аварії все гальмувало і не було жодної інформації про стан мережі. На жаль, це повторюється не вперше. Мені потрібна твоя допомога. Давай зробимо так, щоб наш моніторинг працював за будь-яких обставин!
ММ: – Але давай спочатку синхронізуємось. Я не дивився туди вже кілька років. Наскільки я пам'ятаю, ми відмовилися Nagios і перейшли на Заббікс років 8 тому. І зараз у нас, здається, 6 потужних серверів та близько десятка проксі. Я нічого не плутаю?
МЧ: – Майже. 15 серверів, частина з яких – віртуальні машини. Найголовніше, що це не рятує нас у той момент, коли потрібно найбільше. Як аварія - сервера гальмують і нічого не видно. Ми намагалися оптимізувати конфігурацію, але оптимального приросту продуктивності це дає.
ММ: – Зрозуміло. Щось дивилися, щось уже накопали з діагностики?
МЧ: – Перше, з чим доводиться мати справу – це саме БД. MySQL таким чином постійно навантажений, зберігаючи нові метрики, а коли «Заббікс» починає генерувати купу подій – база йде буквально на кілька годин. Про оптимізацію конфігурації я тобі вже розповів, а ось буквально цього року оновлювали залізо: на серверах стоїть більше сотні гігів пам'яті та дискові масиви на SSD RAID-ах – лінійно вирощувати його далеко нема рації. Що будемо робити?
ММ: – Зрозуміло. Взагалі MySQL – це LTP-база. Очевидно, вона більше не підходить для зберігання архіву метрик нашого розміру. Давай розбиратись.
МЧ: – Давай!
Інтеграція Zabbix і Clickhouse як результат хакатону
Через деякий час ми отримали цікаві дані:
Більшість місця в нашій базі була зайнята архівом метрик і менше 1% використовувалося під конфігурацію, шаблони та налаштування. На той момент ми вже більше року експлуатували рішення Big data на базі Clickhouse. Напрямок руху для нас був очевидним. На нашому весняному "Хакатоні" написав інтеграцію "Заббікса" з "Клікхаусом" для сервера та фронтенда. На той момент у Заббіксі вже була підтримка ElasticSearch, і ми вирішили порівняти їх.
Порівняння Clickhouse та Elasticsearch
ММ: – Для порівняння ми генерували навантаження таке саме, яке забезпечує «Заббікс»-сервер і дивилися, як поводитимуться системи. Ми писали дані пачками по 1000 рядків, використовували CURL. Ми заздалегідь припускали, що «Клікхаус» буде більш ефективним для профілю навантаження, яке робить «Заббікс». Результати навіть перевершили наші очікування:
В однакових умовах на тестах «Клікхаус» писав утричі більше даних. У цьому обидві системи дуже ефективно споживали (малу кількість ресурсів), читаючи дані. Але «Еластікс» при записі була потрібна велика кількість процесора:
Сумарно «Клікхаус» значно перевершував «Еластікс» щодо споживання процесора та швидкості. При цьому за рахунок стиснення даних «Клікхаус» використовує в 11 разів менше на жорсткому диску і робить приблизно в 30 разів менше дискових операцій:
МЧ: – Так, роботу з дисковою підсистемою у «Клікхауса» реалізовано дуже ефективно. Під бази можна використовувати великі SATA-диски і отримувати швидкість запису в сотні тисяч рядків в секунду. Система "з коробки" підтримує шардинг, реплікацію, дуже проста в налаштуванні. Ми задоволені її експлуатацією протягом року.
Для оптимізації ресурсів можна встановити «Клікхаус» поряд з існуючою основною базою і тим самим зберегти безліч процесорного часу та дискових операцій. Ми винесли архів метрик на вже наявні «Клікхаус»-кластери:
Ми настільки розвантажили основну MySQL-базу, що могли об'єднати її на одній машині з сервером «Заббікс» і відмовитися від виділеного сервера під MySQL.
Як улаштований polling в Zabbix?
4 місяці тому
ММ: – Ну що, про проблеми із базою можна забути?
МЧ: - Це точно! Інше завдання, яке нам потрібно вирішити, – це повільний збір даних. Тепер усі наші 15 проксі-серверів перевантажені процесами SNMP та поллінгу. І немає жодних, окрім як ставити нові та нові сервери.
ММ: - Чудово. Але розкажи спершу, як влаштований полінг у «Заббікс»?
МЧ: – Якщо коротко, то існує 20 типів метрик та десяток способів їх отримання. Заббікс може збирати дані або в режимі запит - відповідь, або чекати нові дані через Інтерфейс Трапера.
Варто зауважити, що в оригінальному Заббікс цей спосіб (Trapper) - найшвидший.
Існують проксі-сервери для розподілу навантаження:
Проксі можуть виконувати ті ж функції збору, що і «Заббікс»-сервер, отримуючи з нього завдання та надсилаючи зібрані метрики саме через Трапер-інтерфейс. Це офіційно рекомендований спосіб розподілу навантаження. Також проксі корисні для моніторингу дистанційної інфраструктури, що працює через NAT або повільний канал:
ММ: – З архітектурою все зрозуміло. Потрібно дивитися вихідні джерела.
Через кілька днів
Оповідь про те, як nmap fping переміг
ММ: – Здається, я щось накопав.
МЧ: – Розповідай!
ММ: – Я виявив, що під час перевірки доступності «Заббікс» робить перевірку максимум до 128 хостів одночасно. Я спробував збільшити цю цифру до 500 і прибрав міжпакетний інтервал у їхньому пінгу (ping) – це збільшило продуктивність вдвічі. Але хотілося б більших цифр.
МЧ: - У своїй практиці мені іноді доводиться перевіряти доступність тисяч хостів, і нічого швидше за nmap я для цього не зустрічав. Я впевнений, що це найшвидший спосіб. Давай спробуємо! Потрібно значно збільшити кількість хостів за одну ітерацію.
ММ: – Перевіряти понад п'ятсот? 600?
МЧ: - Як мінімум пару тисяч.
ММ: - Окей. Найголовніше, що хотів сказати: я знайшов, що більшість поллінга в Заббікс зроблено синхронно. Ми обов'язково маємо його переробити на асинхронний режим. Тоді ми зможемо кардинально збільшити кількість метрик, які збирають полери, особливо якщо ми збільшимо кількість метрик за одну ітерацію.
МЧ: – Здорово! І коли?
ММ: - Як завжди, вчора.
МЧ: – Ми порівняли обидві версії fping та nmap:
На великій кількості хостів nmap очікувано було до п'яти разів ефективніше. Так як nmap перевіряє лише факт доступності та час відгуку, підрахунок втрат ми перенесли до тригерів і значно скоротили інтервали перевірки доступності. Оптимальною кількістю хостів для nmap ми знайшли близько 4 тисяч за одну ітерацію. Nmap дозволив нам утричі знизити витрати ЦПУ на перевірки доступності та скоротити інтервал зі 120 секунд до 10.
Оптимізація поллінгу
ММ: – Потім ми зайнялися полерами. В основному нас цікавив знімання SNMP та агенти. У «Заббіксі» полінг зроблено синхронно і вжито спеціальних заходів для того, щоб збільшувати ефективність системи. У синхронному режимі відсутність хостів викликає значну деградацію поллінга. Існує ціла система станів, існують спеціальні процеси - так звані unreachable-полери, які працюють тільки з недоступними хостами:
Це коментар, який демонструє матрицю станів, всю складність системи переходів, які потрібні для того, щоб залишатися ефективною системі. Крім того, сам синхронний полінг досить повільний:
Саме тому тисячі потоків поллерів на десятку проксі не могли зібрати для нас потрібної кількості даних. Асинхронна реалізація вирішила не тільки проблеми з кількістю потоків, але й значно спростила систему станів недоступних хостів, тому що за будь-якої кількості, що перевіряються в одній ітерації поллінга, максимальний час очікування складав 1 тайм-аут:
Додатково ми модифікували, доопрацювали систему полілінгу для запитів SNMP. Справа в тому, що більшість не можуть відповідати на кілька запитів SNMP одночасно. Тому ми зробили гібридний режим, коли SNMP-поллінг того самого хоста робить асинхронно:
Це робиться для всієї пачки хостів. Такий режим в результаті не повільніше, ніж повністю асинхронний, тому що опитування півтори сотні SNMP-значень все одно набагато швидше, ніж 1 тайм-аут.
Наші експерименти показали, що оптимальна кількість запитів в одній ітерації приблизно 8 тисяч при SNMP-поллінгу. Сумарно перехід на асинхронний режим дозволив прискорити продуктивність поллінга в 200 разів, кілька сотень разів.
МЧ: – Отримані оптимізації поллінга показали, що ми не тільки можемо позбутися всіх проксі, а й скоротити інтервали з багатьох перевірок, а проксі стануть не потрібними як спосіб поділу навантаження.
Близько трьох місяців тому
Зміни архітектуру – збільши навантаження!
ММ: - Ну що, Максе, час у продуктив? Мені потрібний потужний сервер та хороший інженер.
МЧ: – Добре, заплануємо. Давно настав час зрушити з мертвої точки в 5 тисяч метрик в секунду.
Ранок після апгрейду
МЧ: - Мишко, ми оновилися, але до ранку відкотилися назад ... Відгадай, якої швидкості вдалося досягти?
ММ: – Тисяч 20 максимум.
МЧ: - Ага, 25! На жаль, ми там же, із чого почали.
ММ: - А що так? Діагностику зняли якусь?
МЧ: - Так звичайно! Ось, наприклад, цікавий top:
ММ: - Давай подивимося. Я бачу, що ми пробували безліч потоків поллінга:
Але при цьому не змогли утилізувати систему навіть наполовину:
А загальна продуктивність досить маленька, близько 4 тисяч метриків на секунду:
Є ще щось?
МЧ: - Так, strace одного з полерів:
ММ: – Тут чітко видно, що процес поллінгу чекає на «семафори». Це блокування:
МЧ: - Не зрозуміло.
ММ: - Дивись, це схоже на ситуацію, коли купа потоків намагається працювати з ресурсів, з яким одночасно можна працювати лише одному. Тоді все, що вони можуть робити – розділяти цей ресурс за часом:
І сумарна продуктивність роботи з таким ресурсом обмежується швидкістю одного ядра:
Вирішити таку проблему можна двома способами.
Апгредити залізо машини, переходити на більш швидкі ядра:
Або змінювати архітектуру та паралельно – навантаження:
МЧ: – До речі, на тестовій машині пустимо меншу кількість ядер, ніж на бойовий, зате вони в 1,5 рази швидше за частотою на ядро!
ММ: – Ясно? Потрібно дивитися код сервера.
Шлях даних на сервері Zabbix
МЧ: – Щоб розібратися, ми почали аналізувати, як дані передаються всередині «Заббікс»-сервера:
Класна картинка, правда? Давайте пройдемося по ній крок за кроком, щоб більш-менш прояснити. Є потоки та послуги, відповідальні за збір даних:
Зібрані метрики вони передають через сокет у Preprocessor manager, де зберігаються у чергу:
Препроцесор-менеджер» передає дані своїм воркерам, які виконують інструкції передобробки та повертають їх назад через той самий сокет:
Після цього препроцесор-менеджер зберігає їх у кеші історії:
Звідти їх забирають хістори-синкери, що виконують багато функцій: наприклад, обчислення тригерів, заповнення кешу значень і, найголовніше, збереження метрик у сховище історії. Загалом процес складний і дуже заплутаний.
ММ: – Перше, що ми побачили – це те, що більшість потоків конкурує за так званий конфігураційний кеш (область пам'яті, де зберігаються всі конфігурації сервера). Особливо багато блокувань роблять потоки, відповідальні за знімання даних:
…оскільки у конфігурації зберігаються як метрики зі своїми параметрами, а й черги, у тому числі польери беруть інформацію у тому, що робити далі. Коли полерів багато, і один блокує конфігурацію, решта чекає на запити:
Полери не повинні конфліктувати
Тому перше, що ми зробили – розділили чергу на 4 частини та дозволили полерам у безпечних умовах блокувати ці черги, ці частини одночасно:
Це прибрало конкуренцію за конфігураційний кеш і швидкість роботи поллерів значно зросла. Але потім ми зіткнулися з тим, що препроцесор-менеджер почав накопичувати чергу завдань:
Preprocessor manager має вміти розставити пріоритети
Це відбувалося у випадках, коли йому не вистачало продуктивності. Тоді все, що він міг робити - збирати запити від процесів збору даних і складати їх буфер доти, доки він не з'їдав усю пам'ять і падав:
Щоб вирішити цю проблему, ми додали другий сокет, виділений спеціально для воркерів:
Таким чином, препроцесор-менеджер отримав можливість пріоритизувати свою роботу і у разі розростання буфера завдання гальмувати знімання, даючи воркерам можливість цей буфер забрати:
Потім ми виявили, що однією з причин гальмування були самі воркери, оскільки вони конкурували за абсолютно не важливий для роботи ресурс. Цю проблему ми оформили bug-fix'ом, і в нових версіях Заббікса вона вже вирішена:
Збільшуємо кількість сокетів – отримуємо результат
Далі сам препроцесор-менеджер став вузькою ланкою, оскільки це один потік. Він упирався у швидкість ядра, даючи максимальну швидкість приблизно 70 тисяч метрик на секунду:
Тому ми зробили чотири, із чотирма наборами сокетів, воркерів:
І це дозволило збільшити швидкість приблизно до 130 тисяч метриків:
Нелінійність зростання пояснюється тим, що виникла конкуренція за кеш історії. За нього конкурували 4 препроцесор-менеджери та хістори-синкери. На цей момент ми отримували на тестовій машині приблизно 130 тисяч метрик в секунду, утилізуючи її приблизно на 95% по процесору:
Близько 2,5 місяців тому
Відмова від snmp-community збільшила NVPs у півтора рази
ММ: - Максе, мені потрібна нова тестова машина! У поточну ми більше не влазимо.
МЧ: – А що є зараз?
ММ: – Зараз – 130k NVPs та процесор «у полицю».
МЧ: - Ух ти! Круто! Стривай, у мене два питання. За моїми підрахунками, наша потреба – близько 15-20 тисяч метрик на секунду. Навіщо нам більше?
ММ: - Хочеться доробити справу до кінця. Хочеться подивитися, скільки ми зможемо вичавити із цієї системи.
МЧ: – Але…
ММ: – Але для бізнесу марно.
МЧ: – Зрозуміло. І друге питання: те, що є зараз, ми зможемо підтримувати самостійно без допомоги розробника?
ММ: - Я не думаю. Зміна роботи з конфігураційним кешем – проблема. Вона стосується змін у більшості потоків і досить складна у підтримці. Найімовірніше, підтримувати її буде дуже важко.
МЧ: – Тоді потрібна якась альтернатива.
ММ: – Є такий варіант. Ми можемо перейти на швидкі ядра, відмовившись від нової системи блокування. Ми все одно отримаємо продуктивність 60-80 тисяч метриків. При цьому ми зможемо залишити весь решту коду. "Клікхаус", асинхронний полінг працюватимуть. І це легко підтримуватиме.
МЧ: - Чудово! Пропоную на цьому зупинитись.
Після оптимізації серверної частини ми нарешті змогли запустити новий код продуктив. Ми відмовилися від частини змін на користь переходу на машину зі швидкими ядрами та мінімізації кількості змін у коді. Ми також спростили конфігурацію і, по можливості, відмовилися від макросів в елементах даних, оскільки вони є джерелом додаткових блокувань.
Наприклад, відмова від часто зустрічається в документації та прикладах макросу snmp-community у нашому випадку дозволила додатково прискорити NVPs приблизно в 1,5 рази.
Після двох днів у продуктивності
Прибираємо спливаючі вікна історії інцидентів
МЧ: - Мишко, ми два дні користуємося системою, і все працює. Але лише тоді, коли все працює! Ми мали планові роботи з перенесенням досить великого сегменту мережі, і ми знову руками перевіряли, що піднялося, що – ні.
ММ: - Не може бути! Ми 10 разів все перевірили. Сервер обробляє навіть повну недоступність мережі миттєво.
МЧ: – Та я все розумію: сервер, база, top, austat, логи – все швидко… Але ми дивимося веб-інтерфейс, а там – процесор «в полку» на сервері і ось це:
ММ: – Зрозуміло. Давай дивитися веб. Ми виявили, що в ситуації, коли було багато активних інцидентів, більшість оперативних віджетів починала працювати дуже повільно:
Причиною цього була генерація вікон, що спливають, з історією інцидентів, які генеруються для кожного елемента в списку. Тому ми відмовилися від генерації цих вікон (закоментували 5 рядків у коді), і це вирішило наші проблеми.
Час завантаження віджетів навіть при повній недоступності скоротився з декількох хвилин до допустимих для нас 10-15 секунд, а історію, як і раніше, можна дивитися клацанням по часу:
Після роботи. 2 місяці назад
МЧ: - Мишко, йдеш? Є розмова.
ММ: – Не збирався. Знову щось із «Заббіксом»?
МЧ: – Та ні, розслабся! Я просто хотів сказати: все працює, дякую! З мене пиво.
Zabbix ефективний
«Заббікс» – досить універсальна та багата система та функція. Його цілком можна використовувати для невеликих інсталяцій "з коробки", але зі зростанням потреб його доводиться оптимізувати. Для зберігання великого архіву метрик використовуйте відповідне сховище:
- можна скористатися вбудованими засобами у вигляді інтеграції з «Еластіксерч» або вивантаженням історії в текстові файли (доступно з четвертої версії);
- можна скористатися нашим досвідом та інтеграцією з «Клікхаус».
Для кардинального збільшення швидкості збору метрик, збирайте їх асинхронними методами та передавайте через траппер-інтерфейс у «Заббікс»-сервер; або можна користуватися патчем для асинхронності поллерів самого «Заббікса».
"Заббікс" написаний на Сі і досить ефективний. Рішення ж кілька вузьких архітектурних місць дозволяє додатково збільшити його продуктивність і, на наш досвід, отримувати понад 100 тисяч метрик на однопроцесорній машині.
Той самий патч Zabbix
ММ: - Я хочу додати кілька моментів. Вся поточна доповідь, всі тести, цифри наведені для конфігурації, яка використовується у нас. З неї ми зараз знімаємо приблизно 20 тисяч метриків на секунду. Якщо ви намагаєтеся зрозуміти, чи це працюватиме у вас – можете порівняти. Те, про що сьогодні розповіли, викладено на GitHub у вигляді патчу:
Патч включає:
- повну інтеграцію з "Клікхаусом" (як "Заббікс"-сервера, так і фронтенда);
- вирішення проблем із препроцесор-менеджером;
- асинхронний полінг.
Патч сумісний з усією версією 4, у тому числі з lts. Швидше за все, з мінімальними змінами він працюватиме на версії 3.4.
Дякую за увагу.
Питання
Питання з аудиторії (далі – А): – Доброго дня! Скажіть, будь ласка, чи є у вас плани інтенсивної взаємодії з командою Zabbix чи у них із вами, щоб це був не патч, а нормальною поведінкою «Заббікса»?
ММ: – Так, частину змін ми обов'язково закоммітуємо. Щось буде, щось залишиться в патчі.
А: – Дуже дякую за чудову доповідь! Підкажіть, будь ласка, після застосування патчу підтримка з боку «Заббікса» залишиться і як далі оновлюватиметься на вищі версії? Чи буде можливість оновити Заббікс після вашого патчу до 4.2, 5.0?
ММ: – Про підтримку я не можу сказати. Якби я був техпідтримкою «Заббікса», то, мабуть, сказав би ні, бо це чужий код. Що стосується кодової бази 4.2, то наша позиція така: «Ми йтимемо з часом, і самі оновлюватимемося на наступній версії». Тому якийсь час ми викладатимемо патч на оновлені версії. Я вже сказав у доповіді: кількість змін із версіями поки що досить невелика. Думаю, перехід з 3.4 на 4 у нас зайняло, здається, хвилин 15. Там щось змінилося, але не дуже важливе.
А: – Тобто, ви плануєте підтримувати свій патч і можна сміливо його ставити на продакшн, надалі отримуючи оновлення якимось чином?
ММ: – Ми категорично рекомендуємо. Нам це вирішує дуже багато проблем.
МЧ: – Ще раз хотілося б загострити увагу, що зміни, які не стосуються архітектури та не стосуються блокувань, черг – вони є модульними, вони в окремих модулях. Навіть самостійно за незначних змін їх можна підтримувати досить легко.
ММ: – Якщо цікаві деталі, то Клікхаус використовує так звану бібліотеку історії. Вона відв'язана – це копія підтримки «Еластікса», тобто конфігураційно змінюється. Поллінг змінює лише польери. Ми вважаємо, що це працюватиме довго.
А: - Велике спасибі. А підкажіть, чи є якась документація змін?
ММ: – Документація – це патч. Зрозуміло, із запровадженням «Клікхауса», із запровадженням нових типів поллерів з'являються нові конфігураційні опції. За посиланням з останнього слайда є короткий опис, як користуватися.
Про заміну fping на nmap
А: – Як ви у результаті це реалізували? Можете на конкретних прикладах: це у вас страппери та зовнішній скрипт? Що в результаті перевіряє так швидко така величезна кількість хостів? Як ви здобуваєте ці хости? Треба nmap'у їх якось згодувати, отримати звідкись, покласти, щось запустити?
ММ: - Круто. Дуже правильне питання! Суть така. Ми модифікували бібліотеку (ICMP-пінг, складова «Заббікса») для ICMP-перевірок, у яких зазначено кількість пакетів – одиниця (1), а код намагається використовувати nmap. Тобто це внутрішня робота «Заббікса» стала внутрішньою роботою пінгера. Відповідно, жодної синхронізації чи використання траппера не потрібно. Це було зроблено свідомо, щоб залишити систему цілісної та не займатися синхронізацією двох систем баз: що перевіряти, заливати через поллер, а чи не зламалася у нас заливка?.. Це набагато простіше.
А: – Для проксі також працює?
ММ: – Так, але ми не перевіряли. Код поллінга і в Заббікс, і в сервері єдиний. Має працювати. Ще раз наголошую: продуктивність системи така, що нам проксі не потрібний.
МЧ: – Правильна відповідь на запитання така: «А навіщо вам за такої системи проксі?» Тільки через NAT'а чи моніторити через повільний канал якийсь…
А: – А ви використовуєте «Заббікс» як алергера, якщо я правильно зрозумів. Або графіки (де архівний шар) ви поїхали в іншу систему, типу Grafana? Чи ви не використовуєте цей функціонал?
ММ: – Я ще раз наголошу: ми зробили повну інтеграцію. Ми виливаємо історію в «Клікхаус», але при цьому змінили php-фронтенд. Php-фронтенд ходить до «Клікхаусу» і всі графіки робить звідти. При цьому, якщо чесно, у нас є частина, яка будує з того ж Клікхауса, з тих же даних Заббікса дані в інших системах графічного відображення.
МЧ: – У «Графані» у тому числі.
Як приймалося рішення про виділення ресурсів?
А: - Поділіться трохи внутрішньою кухнею. Як приймалося рішення у тому, що треба виділити ресурси на серйозну переробку товару? Це, загалом, певні ризики. І скажіть, будь ласка, у контексті того, що ви маєте намір підтримувати нові версії: як виправдовується це рішення з погляду управління?
ММ: - Мабуть, драму історії ми не дуже добре розповіли. Ми опинилися в ситуації, коли щось треба було робити і пішли по суті двома паралельними командами:
- Одна займалася запуском системи моніторингу на нових методах: моніторинг як сервіс, стандартний набір опенсорсних рішень, які ми комбінуємо і намагаємося змінити бізнес-процес для того, щоб працювати з новою системою моніторингу.
- Паралельно ми мали ентузіаст-програміст, який цим займався (про себе). Так сталося, що він переміг.
А: – І який розмір команди?
МЧ: - Вона перед вами.
А: - Тобто як завжди потрібний пасіонарій?
ММ: – Я не знаю, що таке пасіонарій.
А: - У цьому випадку, мабуть, ви. Дякую, ви - круті.
ММ: - Дякую.
Про патчі для Zabbix
А: – Для системи, яка використовує проксі (наприклад, у якихось розподілених системах), чи можливо ваше рішення адаптувати та пропатчити, скажімо, польери, проксі та частково препроцесор самого «Заббікса»; та їх взаємодія? Чи можливо оптимізувати існуючі напрацювання під систему з кількома проксі?
ММ: – Я знаю, що «Заббікс»-сервер збирається за допомогою проксі (компілюється та виходить код). Ми не перевіряли це у продуктивності. Я не впевнений у цьому, але, на мою думку, препроцесор-менеджер не використовується в проксі. Завдання проксі – це взяти набір метрик із «Заббіксу», спалити їх (він ще записує конфігурацію, локальну базу) і віддати назад «Заббікс»-серверу. Робити препроцесинг буде потім сам сервер, коли отримає.
Інтерес до проксі зрозумілий. Ми перевіримо це. Це цікава тема.
А: – Ідея така була: якщо можна патчити польери, їх можна патчити на проксі та патчити взаємодію із сервером, а препроцесор під ці цілі адаптувати лише на сервері.
ММ: - Думаю, все навіть простіше. Ви берете код, накладаєте патч, потім конфігуруєте так, як вам треба – збираєте проксі-сервери (наприклад, з ODBC) і патчений код розносите системами. Де треба – збираєте проксі, де треба – сервер.
А: – Додатково патчити передачу проксі до сервера не доведеться швидше за все?
МЧ: - Ні, вона стандартна.
ММ: - Насправді не звучала одна з ідей. Ми завжди дотримувалися балансу між вибухом ідей і кількістю змін, легкістю підтримки.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com