Моніторинг навантаження сервера
Моніторинг сервера від HostTracker зчитує навантаження CPU, RAM і диска з вашого сервера на Linux або Windows через легкий колектор або SNMP, будує графік тренду і сповіщає вас, коли перевищено заданий поріг, - до того, як сервер вийде з ладу.
Як проходить перевірка навантаження сервера, від колектора до сповіщення
Оберіть один; на вашу машину нічого не надсилається.
Готовий скрипт для хоста на Linux чи Unix, що вже має PHP. Розмістіть його в каталозі, доступному через веб, і спрямуйте монітор на цю базову URL-адресу. Він локально зчитує власні показники CPU, пам’яті й диска машини та повертає число у відповіді.
Аналог для Windows, для хоста на IIS. Та сама ідея, плюс доступ до будь-якого лічильника продуктивності Windows за категорією, назвою та інстансом - тож усе, що локально показує Performance Monitor, можна відстежувати віддалено.
Спрямуйте монітор на будь-яку URL-адресу, яку забажаєте, і поверніть невеликий об’єкт JSON. Десять рядків будь-якою мовою, нічого на вашому сервері, чого ви не написали самі, і ви точно вирішуєте, які числа розкривати. Саме цей варіант зрештою обирає більшість інженерних команд.
HostTracker моніторить навантаження CPU, щоб сервери працювали ефективно й стабільно. Сервіс відстежує використання процесора вашого сервера, виявляючи проблеми та сповіщаючи про нетипові сплески. Моніторинг навантаження CPU допомагає адміністраторам підтримувати стабільну роботу серверів і запобігати простоям.
HostTracker моніторить використання пам’яті, щоб підтримувати продуктивність сервера. Ця функція відстежує використання RAM і виявляє тренди, що можуть спричинити уповільнення чи збої. Звіти та сповіщення допомагають адміністраторам покращувати використання пам’яті. Якісний моніторинг RAM означає, що застосунки працюють добре і без несподіванок через проблеми з пам’яттю.
Моніторинг HDD від HostTracker запобігає проблемам зі сховищем, що впливають на продуктивність сервера. Сервіс відстежує використання дискового простору та сповіщає адміністраторів, щоб запобігти таким проблемам, як брак місця чи збої диска. Моніторинг і звітність допомагають тримати руку на пульсі щодо місця на диску, тож на вашому сервері завжди достатньо простору для стабільної роботи. Це підтримує надійність серверів і запобігає втраті даних через проблеми зі сховищем.
Значення за кожною перевіркою відносно обох порогів, тож тенденцію видно задовго до сповіщення.
CPU, RAM або диск у часі з нанесеними лініями попередження та критичного рівня - диск, що заповнюється, це схил, а не несподіванка.
Попередження та критичний рівень доходять до своїх контактів після заданої вами кількості невдалих перевірок.
Сайти, сервери, API, сертифікати. Один тип перевірки на сторінку, за всіма - ті самі локації, сповіщення та звіти.
"Я вже довго користуюся цим сервісом моніторингу, і моя щоденна рутина більше не є проблемою. Він тихо стежить за всіма моїми сайтами і дозволяє мені реагувати в ту мить, коли щось йде не так."
Нам довіряють команди з
Кожен розділ відкривається на місці, тож сторінка залишається короткою.
Більшість продуктів для моніторингу серверів просять встановити агента: фоновий процес із системним доступом, що постійно працює на вашій машині й транслює дані назовні. HostTracker навмисно так не робить. Це зовнішній сервіс моніторингу, і перевірка навантаження сервера працює навпаки - ваш сервер відкриває одну невелику доступну лише для читання кінцеву точку, яка повідомляє одне число, і HostTracker запитує її за обраним вами розкладом.
Ця інверсія і є всім задумом. Не потрібен демон, який слід підтримувати живим, немає привілейованого програмного забезпечення, яке ви не писали, що працює на продакшені, немає облікових даних, переданих третій стороні, і немає вхідного порту керування. Ви розкриваєте URL-адресу, яка не приймає команд, нічого не змінює й повертає одне значення.
На вашу машину ніколи нічого не надсилається. Колектор розгортаєте ви, коли вирішите, а HostTracker лише надсилає до нього запити. Якщо ви його приберете, моніторинг зупиниться - іншого способу проникнути в систему немає.
Кожен монітор стежить за одним значенням, тож типовий сервер зрештою має три чи чотири монітори - і кожен зі своїм порогом, своєю історією та своїм сповіщенням. Типи значень такі:
| Метрика | Подається як | Для чого корисна |
|---|---|---|
| CPU | Відсоток використання | Стійке насичення, процеси, що вийшли з-під контролю, недостатньо потужні інстанси, навантаження, додане релізом |
| RAM | Відсоток використання | Витоки пам’яті, поступове зростання споживання між перезапусками, тиск, що передує примусовому завершенню через нестачу пам’яті |
| Диск | Відсоток використання названого вами шляху чи диска | Логи, завантаження й бекапи, що заповнюють том, - найповільніший і найпередбачуваніший з усіх можливих простоїв |
| TCP-порт | Час підключення в мілісекундах | Чи все ще приймає підключення служба на машині, і наскільки швидко |
| SQL Server | Час підключення в мілісекундах | Доступність бази даних і автентифікація з точки зору самого сервера |
| MySQL | Час підключення в мілісекундах | Те саме, для MySQL |
| Лічильник продуктивності Windows | Те, що повідомляє лічильник | Усе, що розкриває Performance Monitor, за категорією, назвою лічильника й інстансом - довжини черг, дескриптори, показники по процесах |
Якщо вам потрібна база даних за сервером, а не час підключення до нього, - це інша, глибша перевірка: монітор запитів до бази даних підключається, автентифікується, виконує написаний вами запит і звіряє отримане значення з порогом.
Контракт навмисно тривіальний, адже суть у тому, щоб ви могли прочитати його за один раз і реалізувати будь-якою мовою, яку вже використовує ваша команда. HostTracker запитує вашу URL-адресу; ваша кінцева точка відповідає об’єктом JSON, що несе значення:
{ "v": 42.7 }Це весь обов’язковий контракт. Два опційні члени роблять результат кориснішим: e несе рядок помилки, коли цього разу значення не вдалося зчитати, - набагато кращий результат, ніж повідомити оманливий нуль, - а vs несе власний рядок версії, який з’являється в результаті, тож ви можете дізнатись, яка збірка колектора відповіла.
{ "v": 91.4, "e": "", "vs": "collector-2.1" }Оскільки ви пишете зчитувач самі, ви не обмежені тим, що вміє збирати типовий агент. Глибина черги, коефіцієнт влучань у кеш, кількість завдань в очікуванні, вік найстарішого необробленого запису, вільні inode, розмір каталогу, що ніколи не має рости, - будь-що, що можна виразити числом, стає відстежуваним значенням із порогами, історією й прив’язаними сповіщеннями.
Захистіть кінцеву точку. Вона має бути доступна для перевірних вузлів, що її запитують, тож поводьтеся з нею як з будь-якою іншою публічною URL-адресою: розмістіть на непередбачуваному шляху, тримайте доступною лише для читання й розкривайте лише ті числа, які вам комфортно розкривати. Вона не приймає жодних параметрів, що щось змінюють, - це й обмежує розкриття рівно одним значенням.
Сире число - це дані; поріг - це те, що перетворює їх на моніторинг. Кожен монітор несе умову й одне чи два обмеження, тож ви можете виразити форму "неправильного", а не просто стелю:
Поряд із порогом стоїть лічильник послідовних перевантажених перевірок до того, як монітор перейде в стан "не працює", регульований від нуля до двадцяти. Це найцінніше налаштування на сторінці і те, яке найчастіше залишають без змін. Сервер на 95% CPU протягом одного вимірювання під час нічного бекапу - не інцидент. Сервер на 95% протягом п’яти перевірок поспіль - уже так. Налаштуйте лічильник так, щоб він відповідав тому, наскільки довго ваше навантаження законно може бути зайнятим, - і ціла категорія хибних тривог о третій ночі зникає без жодного пом’якшення самого порогу.
Тут це має більше значення, ніж у веб-перевірці, бо метрику сервера зчитує одне авторитетне джерело - ваш власний колектор, - а не підтверджують кілька незалежних вузлів, як у перевірці доступності. Немає другої думки, яка б усереднила миттєвий сплеск, тож саме лічильник дебаунсу відіграє цю роль.
Три основні метрики виходять з ладу справді по-різному, і знання, на яку саме ви дивитесь, підказує, скільки у вас часу.
| Метрика | Як настає збій | Скільки попередження ви отримуєте |
|---|---|---|
| CPU | Нічого не ламається. Усе просто сповільнюється - кожен запит, кожен запит до бази, кожне фонове завдання, - і сайт деградує задовго до того, як впаде. | Зазвичай достатньо, якщо ви спостерігаєте. Стійке зростання видно годинами чи днями, перш ніж воно стане помітним користувачам. |
| RAM | Раптово й різко. Операційна система примусово завершує застосунки, щоб звільнити пам’ять, вони перезапускаються, і їх знову завершують - це точнісінько той переривчастий, невідтворюваний збій, який найважче діагностувати. | Мало, аж до самого кінця. Але повільне зростання витоку пам’яті між перезапусками - один з найбільш читабельних сигналів у моніторингу, якщо історія збережена. |
| Диск | Усе одразу. Логи перестають писатись, база даних відмовляє в записі, сесії падають, тимчасові файли неможливо створити, - а причина невидима з власних повідомлень про помилки застосунку. | Найбільше попередження з усіх - і найчастіше пропущене. Том, що заповнюється зі сталою швидкістю, передбачуваний за дні наперед. |
| Час підключення | Залежність, на яку покладається сервер, стала повільною чи недоступною - ще до того, як це проявилось як повний збій. | Часто найраніший сигнал, що щось нижче за течією не в порядку. |
Диск заслуговує на репутацію класичного простою, якого можна уникнути. Це той збій, який монітор з порогом і тижнем історії завжди виявить першим, і той, який найсоромніше пояснювати згодом.
Кожне вимірювання зберігається, тож у кожного монітора сервера є власний графік значення в часі із середнім, мінімумом і максимумом для вибраного вами вікна. Відсотки відображаються як відсотки, а час підключення - в мілісекундах, тож монітор CPU і монітор затримки бази даних кожен читається так, як ви очікуєте.
Сповіщення каже вам, що щось перетнуло лінію; графік дає дві речі, які насправді потрібні далі. Це нове? - сплеск, що виглядає тривожним ізольовано, часто виявляється тим самим сплеском, що стається щовівторка о 02:00 вже рік. І куди це прямує? - показник пам’яті, що стало росте між перезапусками, - витік, яким би не було його поточне значення, а диск, що росте на два відсотки на тиждень, має прив’язану до себе дату.
Це друге питання - застосування моніторингу сервера для планування потужностей, і саме тому варто почати збирати метрику ще до того, як ви знаєте, який поріг на неї поставити. Поріг можна додати через місяць, коли історія покаже, як виглядає норма. Історія, яку ви не зібрали, - та, яку вже не повернути.
Вони доповнюють одне одного, а не є альтернативами, і межа між ними достатньо чітка, щоб озвучити її прямо.
| Моніторинг доступності | Моніторинг сервера | |
|---|---|---|
| На яке питання відповідає | Чи може відвідувач зайти на сайт прямо зараз? | Чи достатньо здорова машина під ним, щоб і далі відповідати? |
| Звідки дивиться | Ззовні - 300+ точок у 158 містах | Зсередини - значення, зчитане на самій машині |
| Типовий момент повідомлення | Повідомляє в момент збою | Повідомляє до збою, якщо ви встановили поріг нижче за обрив |
| Контроль хибних тривог | Провалене спостереження перевіряється повторно з інших локацій і підтверджується кворумом | Одне авторитетне вимірювання з лічильником послідовних перевантажень як дебаунсом |
| Виявляє витік пам’яті | Ні - поки щось зрештою не впаде | Так - як тренд, за тижні наперед |
| Виявляє збій мережевого маршруту між вашими користувачами й вами | Так | Ні - машина цілком щаслива |
Використання лише одного з них залишає реальну прогалину в кожному напрямку. Комбінація, на якій зупиняється більшість акаунтів, - це одно хвилинна перевірка доступності з кількох локацій плюс жменька моніторів сервера на CPU, пам’ять і том, що найімовірніше заповниться.
Роутери, комутатори, файрволи, ДБЖ і принтери не можуть хостити скрипт, але майже всі вони вже вміють SNMP. Окрема перевірка SNMP зчитує числове значення напряму з пристрою за OID - лічильники інтерфейсу, температуру, навантаження, аптайм, заряд батареї - через SNMP v1, v2c чи v3, включно з v3 з автентифікацією та приватністю, тож облікові дані не передаються у відкритому вигляді.
Чесно про те, де це наразі перебуває: перевірка SNMP зчитує й фіксує значення, яке повідомляє пристрій. Сповіщення на основі порогу для значення SNMP наразі недоступне - коли вам потрібно, щоб число справді підняло інцидент, використовуйте монітор навантаження сервера проти колектора, який має повну модель умов і дебаунсу, описану вище.
Моніторинг сервера - це постійне відстеження ключових ресурсів вашого сервера: навантаження CPU, використання RAM (пам’яті) та навантаження HDD (диска), - щоб бачити, як інфраструктура працює насправді, а не лише чи відповідає сайт, що на ній розміщений. Моніторинг сервера від HostTracker перевіряє ці три метрики та звітує про тренди й сплески з часом, а це важливо, адже вичерпання ресурсів - одна з найпоширеніших причин повільної роботи, збоїв і прямого простою. Сервер може технічно бути "онлайн" і при цьому за мить до відмови, якщо завантаження CPU зашкалює, пам’ять майже вичерпана або місця на диску критично мало - нічого з цього звичайна перевірка доступності може й не показати, поки проблема справді не спричинить видимий простій.
Сервер може лишатися доступним і технічно онлайн, водночас працюючи небезпечно близько до межі своїх ресурсів, тож високе навантаження CPU або RAM часто є раннім сигналом проблеми, а не самою проблемою. Стійке високе навантаження CPU уповільнює обробку кожного запиту сервером, погіршуючи досвід кожного відвідувача, навіть якщо сайт формально не падає. Тиск на пам’ять ще небезпечніший - коли використання RAM наближається до межі, застосунки можуть починати падати, перезапускатися або їх примусово завершує операційна система, щоб звільнити пам’ять, що часто спричиняє переривчасті, складні для діагностики збої, які виглядають як випадкові глюки, а не як явна відмова. Якщо помітити підвищене навантаження CPU чи RAM через моніторинг сервера ще до того, як воно переросте у збій, адміністратори встигають дослідити причину й заздалегідь наростити потужність.
Коли моніторинг CPU, RAM або дискового навантаження виявляє нетипову активність - стійкий сплеск, пам’ять, що наближається до межі, або дедалі менше вільного місця на диску, - HostTracker надсилає сповіщення через будь-який із 9 налаштованих каналів оповіщення, зокрема електронну пошту, SMS, голосовий дзвінок, webhook, Slack і месенджери на кшталт Telegram, Discord та Viber. Це означає, що відповідальний за серверну інфраструктуру дізнається про проблему з ресурсами, що назріває, напряму, а не виявляє її вже після того, як вона спричинила уповільнення чи збій, помітний клієнтам. Оскільки звіти й сповіщення формуються автоматично на основі даних моніторингу, адміністратори отримують документовану історію трендів навантаження ресурсів разом із сповіщенням у реальному часі, що допомагає відрізнити разовий сплеск від справжньої проблеми з потужністю, яка потребує довгострокового вирішення.
Моніторинг доступності відповідає на вужче питання: чи доступний сайт або сервіс і чи відповідає він просто зараз. Моніторинг сервера заглядає глибше, під поверхню, - на інфраструктуру, що фактично обслуговує сайт: навантаження CPU, використання пам’яті та місце на диску, - які часто є першопричиною збою доступності, а не окремою непов’язаною проблемою. Сервер, якому бракує пам’яті чи місця на диску, може ще певний час проходити перевірку доступності, перш ніж зрештою впасти або сповільнитися до відмови, тож покладаючись лише на моніторинг доступності, ви дізнаєтеся про проблему вже тоді, коли вона стала простоєм. Поєднання обох підходів дає повнішу картину: моніторинг доступності підтверджує, що сайт зараз доступний, а моніторинг сервера відстежує тренди навантаження ресурсів, які показують, чи лишиться він таким і надалі.
Частота перевірок налаштовується під те, наскільки швидко вам потрібно дізнаватися про проблему з ресурсами, що назріває. Платні плани HostTracker підтримують інтервали моніторингу аж до одного разу на хвилину, що корисно для серверів із критично важливими для бізнесу застосунками, де сплеск навантаження потрібно виявити й усунути швидко. Менш критичні або менш навантажені сервери можуть використовувати довший інтервал, а безкоштовний план без обмеження в часі перевіряє два монітори кожні 30 хвилин, чого зазвичай достатньо, щоб помітити стійкий тренд - наприклад, місце на диску, що поступово закінчується протягом кількох днів, - хоч він і не вловить дуже короткочасний сплеск CPU. 30-денний пробний період з усіма функціями без прив’язки картки дозволяє спробувати швидші інтервали перевірки й побачити, наскільки детальні дані вони дають, перш ніж обирати план.
Ні - жодного агента HostTracker встановлювати не потрібно, жодного демона підтримувати запущеним і жодних облікових даних передавати нікому. Перевірка навантаження сервера працює навпаки: ваш сервер відкриває одну невелику доступну лише для читання кінцеву точку, яка повідомляє одне число, і HostTracker запитує її за обраним вами розкладом. У вас є три способи це надати. Два з них - готові скрипти-колектори, які ви розміщуєте на сервері, що вже маєте, - один для PHP на Linux чи Unix, один для ASP.NET на IIS, - а третій - написати кінцеву точку самостійно, що займає близько десяти рядків будь-якою мовою: прочитайте значення так, як вам зручно, і поверніть невеликий об’єкт JSON із ним. Цей третій варіант багато команд зрештою обирають, бо він означає, що на їхній машині не працює нічого, що вони не написали самі, і вони точно вирішують, які саме числа розкриваються. На ваш сервер ніколи нічого не надсилається автоматично, і HostTracker ніколи не відкриває на ньому сесію керування.
Кінцева точка колектора має бути доступна для перевірних вузлів HostTracker, тож сервер за файрволом без жодного вхідного доступу опитати напряму не вдасться. На практиці це менша перешкода, ніж здається, бо розкрити потрібно лише одну доступну для читання URL-адресу, яка повертає одне число, - не SSH, не порт керування, не протокол моніторингу. Звичні підходи - опублікувати кінцеву точку на непередбачуваному шляху, обмежити її адресами, з яких надходять запити, або розмістити її на машині в тій самій мережі, що вже звернена в інтернет, і нехай вона звітує від імені приватного хоста. Що б ви не обрали, розкриття навмисно мінімальне: кінцева точка не приймає жодних команд, нічого не змінює й повертає одне число. Це зовсім інша розмова про безпеку, ніж встановлення стороннього агента з системним доступом, і саме тому перевірку спроєктовано саме так.
Моніторинг навантаження сервера - перевірки CPU, RAM і HDD - один із 13 типів перевірок, доступних у HostTracker, а безкоштовний план без обмеження в часі дозволяє безкоштовно моніторити два сервери чи сайти з перевірками кожні 30 хвилин. HostTracker загалом не є суто безкоштовним продуктом - це платний сервіс моніторингу з безкоштовним рівнем поряд із ним, - тож безкоштовний план добре підходить, щоб спробувати моніторинг сервера на кількох машинах або як легкий варіант для невеликих проєктів, а не як основну пропозицію. Для моніторингу більшої кількості серверів, коротших інтервалів перевірки або критично важливої для бізнесу інфраструктури, де важлива швидша реакція, платні плани починаються приблизно від $5 на місяць, а 30-денний пробний період з усіма функціями без прив’язки картки дозволяє протестувати швидші інтервали перед вибором плану.
Почніть безкоштовний пробний період і отримуйте сповіщення, коли навантаження CPU, RAM чи диска перевищує ваші пороги.
Частина інструментів моніторингу сайту HostTracker.