Це канонічне запитання щодо програмного забезпечення для моніторингу.
Також пов'язано: Який інструмент ви використовуєте для контролю своїх серверів?
Мені потрібно стежити за своїми серверами; що мені потрібно враховувати, приймаючи рішення щодо моніторингового рішення?
Відповіді:
Існує багато рішень для моніторингу. Кожен має свої переваги і у кожного бізнесу є свої потреби, тому правильної відповіді немає. Однак я можу допомогти вам зрозуміти, що ви можете шукати, вибираючи рішення для моніторингу.
Загалом системи моніторингу виконують дві основні цілі. Перший - збирати та зберігати дані з часом. Наприклад, ви можете зібрати використання процесора та графікувати його з часом. Друга мета - попередити, коли речі або не відповідають, або не знаходяться в межах певних порогових значень. Наприклад, ви можете отримати сповіщення, якщо певний сервер не можна отримати за допомогою pings або якщо використання процесора перевищує певний відсоток. Існують також системи моніторингу журналів, такі як Splunk, але я розглядаю їх як окремі для цього.
Ці дві основні ролі інколи походять в одному продукті, в інший час і більш поширеним є створення продукту, присвяченого кожній цілі.
Дослідники :
Усі системи моніторингу потребують певного опитувальника для збору даних. Не всі дані збираються однаково. Ви повинні переглянути своє оточення та вирішити, які дані вам потрібні та як вони можуть збиратися. Потім переконайтесь, що обрана вами система моніторингу підтримує те, що вам потрібно. Деякі поширені методи включають:
Якщо у вас в основному є одна ОС у вашому оточенні або основна ОС, деякі системи можуть мати більше варіантів, ніж інші.
Конфігурація :
в системах моніторингу, як правило, багато використовується об'єкт. Наприклад, ви хочете контролювати певну програму, наприклад Apache або IIS, на купі серверів. Або ви хочете, щоб певні пороги застосовувались до груп серверів. Також у вас можуть бути певні групи людей, які можуть бути "за викликом". Тому хороша система шаблонів є життєво важливою для моніторної системи.
Конфігурація, як правило, здійснюється через користувальницький інтерфейс або текстові файли. Параметр інтерфейсу користувача, як правило, буде простішим, але текстові файли, як правило, краще для повторного використання та змінних. Тож залежно від вашого ІТ-персоналу ви можете віддати перевагу простоті над потужністю.
Інтерфейс користувача :
Найпоширеніший інтерфейс для систем моніторингу в наші дні - це веб-інтерфейс. Що стосується веб-інтерфейсу:
Двигун оповіщення : Двигун тривожних сигналів
повинен бути гнучким та надійним. Є багато різних способів повідомлення, включаючи:
Інші функції, на які слід звернути увагу:
Важливо вірити, що коли щось піде не так, ви отримаєте попередження. Це зводиться до двох речей:
Зберігання даних :
Якщо система збирає та зберігає дані (тобто системи, що включають графіки), ніж система зберігає дані. Наприклад, дуже поширеною реалізацією для магазину та графіків є RRD.
Деякі функції, які потрібно шукати у сховищі даних, є:
Графічна бібліотека :
графіки можуть бути корисними для швидкого виявлення тенденцій та надання контексту поточному стану чогось на основі його історії. Деякі, включаючи тренди, які можуть бути корисними для прогнозування речей, перш ніж вони відбудуться (тобто не вистачає місця на диску). Переконайтесь, що графіки чітко дадуть вам інформацію, яку ви думаєте, що вам буде потрібно.
Контроль доступу :
Якщо у вас є велика організація, можливо, вам знадобиться контроль доступу, оскільки певні адміністратори мають змогу коригувати лише певні речі. Можливо, ви також хочете, щоб громадські панелі стикалися з громадськістю. Якщо це важливо, ви повинні переконатися, що система моніторингу має необхідні елементи керування.
Звітність :
Система, яка надає хороші звіти, може допомогти вам визначити, що потрібно вдосконалювати протягом тривалих періодів часу. Наприклад, він може дати хорошу відповідь на такі речі, як "які системи найбільше знижуються?". Це може бути важливо, коли ви намагаєтесь переконати керівництво витрачати гроші на певні речі - бізнес - як важкі докази.
Спеціалізовані функції :
Деякі системи моніторингу орієнтовані на конкретні продукти або мають більшу підтримку, ніж інші. Наприклад, якщо головне, що вам потрібно контролювати, це SQL-сервер або якщо ви широко використовуєте продукти VMWare, ви повинні побачити, наскільки вони підтримуються.
Заздалегідь визначені шаблони моніторингу :
Система, яка постачається з великою кількістю заздалегідь визначених шаблонів (або має базу користувачів, яка створила багато шаблонів), може бути величезною економією часу.
Відкриття :
Якщо у вас є велике або мінливе оточення. Деякі системи надають можливість додавати нові системи через API або запускати сканування для пошуку нових серверів або компонентів.
Розподілений моніторинг:
Якщо у вас є кілька локацій для моніторингу, може бути корисним, щоб моніторинг опитувачів у кожному місці замість багатьох незалежних систем здійснювали моніторинг через WAN.
Там багато систем моніторингу. У нас є список із підсумком цього старого питання . Для швидкого ознайомлення, про що я найбільше чую:
Я не можу сказати, чим користуватися, тому що кожна організація має свої потреби. Якщо ви хочете зробити правильний вибір, вам слід продумати всі перераховані вище компоненти та визначити, які особливості важливі для вашої організації. Потім знайдіть систему або системи, які заявляють, що надають те, що вам потрібно, і спробуйте їх випробувати. Деякі з них коштують мало, багато або є безкоштовними. Враховуючи все це, ви можете зробити свій вибір. З того, що я використав, вони всі далеко не ідеальні, але принаймні ви можете спробувати отримати щось, що підходить.
Корисно розрізняти моніторинг та оповіщення. Моніторинг означає збирати дані та робити графіки. Сповіщення означає надіслати мені SMS, коли сервер опускається посеред ночі.
Nagios призначений для оповіщення. Кактуси та Мунін призначені для моніторингу. Інші продукти поєднують дві функції. Зеносс і Заббікс - приклади.
Я б почав з відповіді на деякі запитання:
Чи потрібно стежити за серверами, мережевими пристроями, програмами чи всіма трьома?
Чи є обмеження щодо того, які методи ви можете використовувати для моніторингу? Чи можете ви встановити на сервери клієнтів моніторингу, таких як NRPE, або ви будете використовувати SNMP або, можливо, обидва?
Хто буде використовувати графіки, а хто буде використовувати сповіщення? Як би ви хотіли виглядати кінцевий результат? Чи має значення зовнішній вигляд інтерфейсу (чи будуть цим користуватися ділові люди чи лише технічний персонал?)
Які ваші ресурси, як за часом, навичками, так і за технікою обладнання? Чи маєте ви принаймні скромні можливості сценарію? Вам потрібне нестандартне рішення?
На мою думку, першим правилом як сповіщення, так і моніторингу повинно бути: Тримай просто! Організація може жити чи вмирати від того, як вона попереджає та збирає дані, і більшу частину часу все одно ускладнюватиметься самостійно. Почніть з основ і будуйте звідти.
Подумайте про послуги, які надає ваше програмне забезпечення , надсилайте сповіщення, коли ці служби виходять з ладу або коли збільшується ризик виходу з ладу цих служб.
Теорія, що стоїть за стратегіями моніторингу, полягає у прив'язці моніторингу та попередження до якоїсь угоди про рівень обслуговування . Зрештою, ви хочете попередити про те, що ви втрачаєте гроші, необов'язково, що кількість спайок TCP до nji0019.myserver.com має сплеск. Існують різні інструменти, які дозволять вам отримувати тони сповіщень, визначати залежності між сповіщеннями, але багато з цих перевірок не мають прямого відношення до послуги, яку ви надаєте комусь.
Визначте важливі послуги, які ви надаєте, наприклад, можливість обслуговувати веб-сайт та можливість змінювати цей веб-сайт (наприклад, якусь CMS). Це слід перевірити (наприклад, стежачи за тим, щоб Ви могли отримати веб-сторінку та що можете). Відмова цих двох Служб (тут використовуються з великої літери S) повинна викликати сповіщення про це.
Якщо важливо, щоб сайт відповідав протягом розумного періоду часу, це теж повинно викликати сповіщення. Вибір "порушення SLA", якщо хочете.
Зазвичай існує властивий ризик відмови Сервісу, і досить часто цей ризик пом'якшується тим, що ви вводите надмірність, наприклад, другий сервер, або підлеглий базу даних, або додаткові мережеві карти ...
Коли ця надмірність буде втрачена, Служба все ще нормальна, але ризик її відмови просто збільшився.
Це друга основна причина для запуску сповіщень; що надмірність відпала (наприклад, другий сервер загинув) або що існує неминуча небезпека збільшення ризику (наприклад, у диска залишилося лише 500 Мбіт, або дисковий тренд вказує на те, що диск буде заповнений приблизно за 5 годин).
Але check_mk дає мені 50-60 чеків на хоста, чи все це марно?
Ні. Все це не означає, що ви хочете скинути безліч автоматичних чеків, які ви отримуєте, наприклад, check_mk, але це означає, що ви повинні спробувати класифікувати кожен із перевірок на те, на що можуть вплинути Служби, якщо щось не виходить з ладу.
На яку службу може вплинути, якщо / var / розділ заповниться? На яку службу може вплинути, якщо інтерфейс eth0 не працює? ... якщо вихідні TCP-з'єднання блокуються деяким брандмауером? ... якщо кількість ниток перевищує 800? ... якщо база даних знизиться?
У вас є 2 веб-сервери та сервер баз даних, що обслуговує сайт за балансиром навантаження, яким ви не володієте (наприклад, Інтернет-провайдер). Служба, яку ви надаєте, - порт 80 на двох серверах, і вони мають величезні кеші, які можуть витримати, наприклад, час простою бази даних (база даних на третьому сервері).
У цьому випадку повний збій веб-сервера не призведе до того, що сайт не працює. Що сталося, це те, що надмірність зникла, щоб ризик невдачі просто збільшився. Це повинно викликати попередження.
Повний збій у базі даних може взагалі не вплинути на можливість обслуговування сайту через добре налаштовані кеші; Потім це не впливає на Службу обслуговування веб-сайту, але може вплинути на іншу Службу, а саме на оновлення веб-сайту або прийняття замовлень ...
Кожна служба має свій рівень обслуговування, який визначає, як важливо відновити сервіс або уникнути відключень
Кожного разу, коли ви отримуєте сповіщення, слід виконувати одну з наступних дій: - змінити систему, яка контролюється, щоб виправити проблему, яка викликала сповіщення (наприклад, замінити диск або переконфігурувати logrotate або щось подібне) - змінити систему моніторингу, щоб уникнути сповіщення відправляється наступного разу, коли виникає ситуація. (наприклад, змініть рівні на "без диска", щоб диск міг заповнити до 90% замість лише 80%)
Я здебільшого знайомий з Nagios та його багатослівною конфігурацією, і з тих пір був підключений до мультисайту Check-mk. Нещодавно я дізнався, що check_mk має таке поняття Business Intelligence (починаючи з 1.11), яке, здається, добре відповідає цьому мисленню. Ви можете визначити, що перевірки в nagios є частиною більшого сервісу і мають правила, що визначають стан "Сервісу" як функцію стану багатьох перевірок, що агрегуються до найгіршого або найкращого стану.
Один з найважливіших моментів, які компанії забувають, обираючи рішення для моніторингу, - це те, що не все вирішується з негайними операційними проблемами, це з завтрашніми непередбаченими проблемами! Я маю на увазі, звичайно, важливе вирішення негайних питань, але повірте, у багатьох випадках ця недалекоглядна стратегія не гарантує виживання компанії.
На ринку є десятки чудових моніторингових рішень. Шорт-лист невеликого набору рішень, які задовольняють ваші вимоги, є складним і довгим завданням, крім того, знайти таке, яке відповідає вашому бюджету, ще складніше. Цікава частина - пошук тієї, яка відповідає вашому теперішньому та майбутньому . І не існує жодного процесу оцінки, який би виявив це, це питання досвіду + інтуїції + дуже важливий фактор: довіра , яку не так легко зламати .
Як правило, шукайте та копайте історії успіху вашого списку моніторингових списків, особливо якщо це стосується компанії з вашого сектору. Попросіть продавця про їхні історії успіху і навіть попросіть дозволу поговорити з одним із своїх клієнтів. Компанії, які не бояться цього шоу, у них реальні стосунки зі своїми клієнтами, і вони цього не приховують, і це надзвичайно рідко можна знайти сьогодні.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... всі вони мають свої злети і падіння, але справжньою проблемою є пошук того, який з них краще адаптується до вашого майбутнього.
Якщо ви розглядаєте можливість віддаленого моніторингу системи, можливо, було б корисно шукати фактичні випробування локацій. Проблеми з підключенням не є минулим, і якщо ваше обладнання обслуговує групу в певному регіоні, ви можете переконатися, що ваші ресурси доступні саме в цьому місці.