Моніторинг сервера: перевірка CPU, RAM і навантаження диска
Моніторинг сервера від HostTracker відстежує навантаження CPU, RAM і HDD у реальному часі. Він контролює навантаження процесора, використання пам’яті та навантаження диска, допомагаючи оптимізувати продуктивність сервера й досвід користувачів.
Виявляйте проблеми з ресурсами до того, як вони спричинять простій
Відстеження навантаження CPU
HostTracker моніторить навантаження CPU, щоб сервери працювали ефективно й стабільно. Сервіс відстежує використання процесора вашого сервера, виявляючи проблеми та сповіщаючи про нетипові сплески. Моніторинг навантаження CPU допомагає адміністраторам підтримувати стабільну роботу серверів і запобігати простоям.
Тренди використання пам’яті
HostTracker моніторить використання пам’яті, щоб підтримувати продуктивність сервера. Ця функція відстежує використання RAM і виявляє тренди, що можуть спричинити уповільнення чи збої. Звіти та сповіщення допомагають адміністраторам покращувати використання пам’яті. Якісний моніторинг RAM означає, що застосунки працюють добре і без несподіванок через проблеми з пам’яттю.
Сповіщення про місце на диску
Моніторинг HDD від HostTracker запобігає проблемам зі сховищем, що впливають на продуктивність сервера. Сервіс відстежує використання дискового простору та сповіщає адміністраторів, щоб запобігти таким проблемам, як брак місця чи збої диска. Моніторинг і звітність допомагають тримати руку на пульсі щодо місця на диску, тож на вашому сервері завжди достатньо простору для стабільної роботи. Це підтримує надійність серверів і запобігає втраті даних через проблеми зі сховищем.
Як показники доходять до HostTracker - без жодного агента на вашому сервері
Більшість продуктів для моніторингу серверів просять встановити агента: фоновий процес із системним доступом, що постійно працює на вашій машині й транслює дані назовні. HostTracker навмисно так не робить. Це зовнішній сервіс моніторингу, і перевірка навантаження сервера працює навпаки - ваш сервер відкриває одну невелику доступну лише для читання кінцеву точку, яка повідомляє одне число, і HostTracker запитує її за обраним вами розкладом.
Ця інверсія і є всім задумом. Не потрібен демон, який слід підтримувати живим, немає привілейованого програмного забезпечення, яке ви не писали, що працює на продакшені, немає облікових даних, переданих третій стороні, і немає вхідного порту керування. Ви розкриваєте URL-адресу, яка не приймає команд, нічого не змінює й повертає одне значення.
Колектор на PHP
Готовий скрипт для хоста на Linux чи Unix, що вже має PHP. Розмістіть його в каталозі, доступному через веб, і спрямуйте монітор на цю базову URL-адресу. Він локально зчитує власні показники CPU, пам’яті й диска машини та повертає число у відповіді.
Колектор на ASP.NET
Аналог для Windows, для хоста на IIS. Та сама ідея, плюс доступ до будь-якого лічильника продуктивності Windows за категорією, назвою та інстансом - тож усе, що локально показує Performance Monitor, можна відстежувати віддалено.
Ваша власна кінцева точка
Спрямуйте монітор на будь-яку URL-адресу, яку забажаєте, і поверніть невеликий об’єкт JSON. Десять рядків будь-якою мовою, нічого на вашому сервері, чого ви не написали самі, і ви точно вирішуєте, які числа розкривати. Саме цей варіант зрештою обирає більшість інженерних команд.
На вашу машину ніколи нічого не надсилається. Колектор розгортаєте ви, коли вирішите, а 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-адресою: розмістіть на непередбачуваному шляху, тримайте доступною лише для читання й розкривайте лише ті числа, які вам комфортно розкривати. Вона не приймає жодних параметрів, що щось змінюють, - це й обмежує розкриття рівно одним значенням.
Налаштування порогу, який має сенс
Сире число - це дані; поріг - це те, що перетворює їх на моніторинг. Кожен монітор несе умову й одне чи два обмеження, тож ви можете виразити форму "неправильного", а не просто стелю:
- більше ніж або менше ніж ліміт - найповсякденніша форма. CPU вище 90. Вільний диск нижче 10.
- дорівнює або не дорівнює ліміту - для значення, що насправді є станом: кількість воркерів, яка має лишатися на рівні 4, прапорець, що має лишатися 0.
- усередині діапазону або поза діапазоном, із двома лімітами - правильна форма для будь-чого зі здоровим діапазоном, а не здоровим максимумом. Черга, яка зазвичай тримається між 10 і 500, каже вам щось, коли показує 0, і зовсім інше, коли показує 5000.
- без жодної умови - збирати й будувати графік значення, ніколи не проваляючи перевірку. Корисно для метрики, за якою ви хочете спершу зібрати історію, перш ніж зрозуміти, як виглядає "погано".
Дебаунс - налаштування, що зупиняє шум
Поряд із порогом стоїть лічильник послідовних перевантажених перевірок до того, як монітор перейде в стан "не працює", регульований від нуля до двадцяти. Це найцінніше налаштування на сторінці і те, яке найчастіше залишають без змін. Сервер на 95% CPU протягом одного вимірювання під час нічного бекапу - не інцидент. Сервер на 95% протягом п’яти перевірок поспіль - уже так. Налаштуйте лічильник так, щоб він відповідав тому, наскільки довго ваше навантаження законно може бути зайнятим, - і ціла категорія хибних тривог о третій ночі зникає без жодного пом’якшення самого порогу.
Тут це має більше значення, ніж у веб-перевірці, бо метрику сервера зчитує одне авторитетне джерело - ваш власний колектор, - а не підтверджують кілька незалежних вузлів, як у перевірці доступності. Немає другої думки, яка б усереднила миттєвий сплеск, тож саме лічильник дебаунсу відіграє цю роль.
Про що попереджає кожна метрика
Три основні метрики виходять з ладу справді по-різному, і знання, на яку саме ви дивитесь, підказує, скільки у вас часу.
| Метрика | Як настає збій | Скільки попередження ви отримуєте |
|---|---|---|
| CPU | Нічого не ламається. Усе просто сповільнюється - кожен запит, кожен запит до бази, кожне фонове завдання, - і сайт деградує задовго до того, як впаде. | Зазвичай достатньо, якщо ви спостерігаєте. Стійке зростання видно годинами чи днями, перш ніж воно стане помітним користувачам. |
| RAM | Раптово й різко. Операційна система примусово завершує застосунки, щоб звільнити пам’ять, вони перезапускаються, і їх знову завершують - це точнісінько той переривчастий, невідтворюваний збій, який найважче діагностувати. | Мало, аж до самого кінця. Але повільне зростання витоку пам’яті між перезапусками - один з найбільш читабельних сигналів у моніторингу, якщо історія збережена. |
| Диск | Усе одразу. Логи перестають писатись, база даних відмовляє в записі, сесії падають, тимчасові файли неможливо створити, - а причина невидима з власних повідомлень про помилки застосунку. | Найбільше попередження з усіх - і найчастіше пропущене. Том, що заповнюється зі сталою швидкістю, передбачуваний за дні наперед. |
| Час підключення | Залежність, на яку покладається сервер, стала повільною чи недоступною - ще до того, як це проявилось як повний збій. | Часто найраніший сигнал, що щось нижче за течією не в порядку. |
Диск заслуговує на репутацію класичного простою, якого можна уникнути. Це той збій, який монітор з порогом і тижнем історії завжди виявить першим, і той, який найсоромніше пояснювати згодом.
Читайте тренд, а не лише сповіщення
Кожне вимірювання зберігається, тож у кожного монітора сервера є власний графік значення в часі із середнім, мінімумом і максимумом для вибраного вами вікна. Відсотки відображаються як відсотки, а час підключення - в мілісекундах, тож монітор CPU і монітор затримки бази даних кожен читається так, як ви очікуєте.
Сповіщення каже вам, що щось перетнуло лінію; графік дає дві речі, які насправді потрібні далі. Це нове? - сплеск, що виглядає тривожним ізольовано, часто виявляється тим самим сплеском, що стається щовівторка о 02:00 вже рік. І куди це прямує? - показник пам’яті, що стало росте між перезапусками, - витік, яким би не було його поточне значення, а диск, що росте на два відсотки на тиждень, має прив’язану до себе дату.
Це друге питання - застосування моніторингу сервера для планування потужностей, і саме тому варто почати збирати метрику ще до того, як ви знаєте, який поріг на неї поставити. Поріг можна додати через місяць, коли історія покаже, як виглядає норма. Історія, яку ви не зібрали, - та, яку вже не повернути.
Моніторинг сервера й моніторинг доступності відповідають на різні питання
Вони доповнюють одне одного, а не є альтернативами, і межа між ними достатньо чітка, щоб озвучити її прямо.
| Моніторинг доступності | Моніторинг сервера | |
|---|---|---|
| На яке питання відповідає | Чи може відвідувач зайти на сайт прямо зараз? | Чи достатньо здорова машина під ним, щоб і далі відповідати? |
| Звідки дивиться | Ззовні - 300+ точок у 158 містах | Зсередини - значення, зчитане на самій машині |
| Типовий момент повідомлення | Повідомляє в момент збою | Повідомляє до збою, якщо ви встановили поріг нижче за обрив |
| Контроль хибних тривог | Провалене спостереження перевіряється повторно з інших локацій і підтверджується кворумом | Одне авторитетне вимірювання з лічильником послідовних перевантажень як дебаунсом |
| Виявляє витік пам’яті | Ні - поки щось зрештою не впаде | Так - як тренд, за тижні наперед |
| Виявляє збій мережевого маршруту між вашими користувачами й вами | Так | Ні - машина цілком щаслива |
Використання лише одного з них залишає реальну прогалину в кожному напрямку. Комбінація, на якій зупиняється більшість акаунтів, - це одно хвилинна перевірка доступності з кількох локацій плюс жменька моніторів сервера на CPU, пам’ять і том, що найімовірніше заповниться.
SNMP - для обладнання, яке ніколи не запустить колектор
Роутери, комутатори, файрволи, ДБЖ і принтери не можуть хостити скрипт, але майже всі вони вже вміють SNMP. Окрема перевірка SNMP зчитує числове значення напряму з пристрою за OID - лічильники інтерфейсу, температуру, навантаження, аптайм, заряд батареї - через SNMP v1, v2c чи v3, включно з v3 з автентифікацією та приватністю, тож облікові дані не передаються у відкритому вигляді.
Чесно про те, де це наразі перебуває: перевірка SNMP зчитує й фіксує значення, яке повідомляє пристрій. Сповіщення на основі порогу для значення SNMP наразі недоступне - коли вам потрібно, щоб число справді підняло інцидент, використовуйте монітор навантаження сервера проти колектора, який має повну модель умов і дебаунсу, описану вище.
Налаштування моніторингу сервера
- Вирішіть, що розкривати. Якщо на вашому сервері вже працює PHP чи IIS, відповідний готовий колектор - найшвидший шлях; інакше напишіть кінцеву точку самостійно - вона повертає одне число.
- Розгорніть її на сервері, який хочете відстежувати, і переконайтесь, що можете самі надіслати до неї запит. Розмістіть на непередбачуваному шляху. Якщо машина нова, безкоштовна перевірка TCP-порту та безкоштовний ping-тест - швидкий спосіб підтвердити, що вона доступна ззовні, перш ніж рухатись далі, - без входу в акаунт.
- Додайте монітор типу Моніторинг CPU, RAM, HDD, оберіть, яке значення він зчитує, і вкажіть URL-адресу колектора. Для монітора диска назвіть шлях чи диск; для монітора часу підключення до бази даних вкажіть деталі підключення, які має набрати колектор.
- Задайте умову й ліміти - і навмисно налаштуйте лічильник перевантажень до "не працює", а не залиште його за замовчуванням. Саме це налаштування вирішує, буде монітор корисним чи проігнорованим.
- Оберіть інтервал - будь-де від однієї хвилини до 24 годин. Одна хвилина підходить машині з чимось критично важливим для бізнесу; 5 чи 10 хвилин цілком достатньо для тренду на кшталт використання диска.
- Повторіть для кожного значення, важливого на цьому хості, - CPU, пам’ять і том, що найімовірніше заповниться, - розумний початковий набір, - а потім додайте контакти, яким варто про це знати.
- Дайте цьому попрацювати тиждень, перш ніж щось налаштовувати. Перший тиждень історії - те, що покаже, чи правильний ваш поріг, і це набагато краще свідчення, ніж здогад, зроблений у перший день.
Обмеження, про які варто знати
- Колектор має бути доступний. Хост без жодного вхідного доступу опитати не вдасться. Розкрити потрібно одну доступну лише для читання URL-адресу, а не порт керування, - але розкрити все ж треба.
- Один монітор стежить за одним значенням. CPU, пам’ять і диск - три монітори, кожен зі своїм порогом і своєю історією. Саме це робить сповіщення точними, і це справді означає, що завантажений сервер займає кілька слотів моніторів.
- Лічильники продуктивності Windows потребують колектора на ASP.NET. Трійку категорія / назва / інстанс локально зчитує саме цей колектор; PHP-хост натомість повідомляє CPU, пам’ять, диск і час підключення.
- Немає підтвердження з кількох локацій. На відміну від перевірки доступності, метрику сервера дає одне авторитетне джерело, тож одне аномальне вимірювання - справжнє вимірювання. Лічильник послідовних перевантажень - інструмент саме для цього, і його варто налаштувати.
- Повідомляється те, що повідомляє колектор. Якщо у вашій кастомній кінцевій точці є баг, монітор сумлінно сповіщає про неправильне число, - саме тому важливий опційний член помилки у відповіді: повідомляйте про помилку, а не про нуль.
- Немає лічильника пропускної здатності мережі. Доступні значення - CPU, пам’ять, використання диска, час підключення та лічильники продуктивності Windows; пропускна здатність серед них відсутня. Для пристрою, що повідомляє пропускну здатність через 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-денний пробний період з усіма функціями без прив’язки картки дозволяє протестувати швидші інтервали перед вибором плану.
Продовжуйте вивчати моніторинг HostTracker
Відстежуйте підключення до бази даних і результати запитів
Виконуйте періодичні перевірки підключення та перевіряйте результати запитів у MySQL, PostgreSQL, SQL Server та інших базах даних, щоб прихована проблема з базою даних ніколи не залишилася непоміченою.
Перегляньте всі можливості моніторингу HostTracker
Порівняйте всі 8 типів моніторингу поруч і комбінуйте перевірки, що підходять саме вашому сайту.
Зупиняйте перевантаження сервера до того, як воно вас підкосить
Почніть безкоштовний пробний період і отримуйте сповіщення, коли навантаження CPU, RAM чи диска перевищує ваші пороги.
Частина сервісу моніторингу сайтів HostTracker.