Як налаштувати перевірку Ping (покроковий посібник)

Url / Domain / IP

Введіть ім'я хоста, домен чи IP-адресу, яку потрібно пінгувати, у поле Url / Domain / IP. Ви також можете дати монітору коротке необов'язкове ім'я; воно показуватиметься в сповіщеннях, звітах і будь-яких вбудованих віджетах статусу, тож розпізнавана мітка (наприклад, "core-router-fra", а не сирий IP) легше зчитується пізніше.

Основні налаштування

• Моніторинг увімкнено: призупиняє чи відновлює перевірку без її видалення. Вимкніть на час планового обслуговування, щоб не отримувати сповіщення про зміну, про яку ви й так уже знаєте.
• Розклад за інтервалом / Розклад за cron: запускайте перевірку з фіксованим інтервалом або за cron-виразом. Повзунок інтервалу працює від 1 хвилини до 24 годин; перетягніть його або введіть точне значення в поле праворуч. Розклад за cron підставляє cron-вираз, коли потрібен патерн, який шкала інтервалу виразити не може.
• Tags: мітки через кому (наприклад, infra, vpn), за якими можна фільтрувати й шукати за списком моніторів. Суто організаційна штука - на роботу перевірки вони не впливають.
• Full Log: зберігає кожен окремий результат перевірки замість групування послідовних однакових результатів. Увімкніть для повної історії; лишіть вимкненим, щоб лог перевірки лишався компактнішим.
• Open Stats: робить сторінку статистики й логу цього монітора доступною для людей без входу у ваш акаунт. Не вмикайте це для того, що волієте тримати приватним.
• Прикріплені монітори - DNSBL: виконує перевірку DNS-чорного списку для того самого домену за власним 12-годинним розкладом, незалежним від інтервалу ping вище. Виявлений поганий стан сповіщає згідно з підписками Down/Repeat у розділі Alert Subscriptions, а не власними подіями перевірки Ping.
• Прикріплені монітори - Web Risk: виконує перевірку Google Web Risk для домену на предмет потрапляння в списки шкідливого ПЗ й фішингу, теж за власним розкладом. Доступність залежить від тарифу - якщо ваш акаунт його не включає, перемикач показується недоступним.

Налаштування запиту

Цей розділ містить один елемент керування, вибір DNS-сервера, і він має значення, лише коли ціль - ім'я хоста, а не голий IP:

• DNS-сервери за замовчуванням у локаціях: кожна локація моніторингу розв'язує ваш хост через власний набір публічних DNS-серверів, тож розв'язання йде за місцевими правилами цієї локації, так само, як це було б для реального відвідувача звідти.
• Публічний DNS: розв'язує через публічний пул DNS замість цього, з опційним списком виключених IP публічних DNS-серверів, щоб пропустити конкретні резолвери.
• Custom (свій): вкажіть власні IP DNS-серверів, по одному на рядок - вставте список через кому, пробіл чи перенесення рядка, і він автоматично розіб'ється на рядки. Перевірка тоді розв'язуватиме вашу ціль через ці сервери замість значень за замовчуванням для кожної локації.

Публічний DNS і Custom залежать від тарифу; на скриншоті вище обидва заблоковані банером апгрейду для цього конкретного акаунта. На тарифі, що їх включає, розкривний список працює так само, просто без блокування.

Перевірка відповіді

У Ping немає скриншота для цього розділу, але це все одно повноцінна група у формі монітора, і саме вона вирішує, чи зараховується перевірка як пройдена.

За замовчуванням перевірка проходить успішно, коли хоча б один із чотирьох ICMP echo-запитів до розв'язаної адреси отримує відповідь. Якщо перший розв'язаний кандидат не відповідає, перевірка повторює спробу ще для щонайбільше двох інших адрес, розв'язаних через DNS, перш ніж бути позначеною як провалена - домен, за яким стоїть кілька A-записів, може й далі показувати Up, навіть якщо одна з цих адрес перестала відповідати (див. розділ «Діагностика»).

• Expected IPs Validation: увімкніть це, щоб додатково вимагати, аби DNS розв'язував ваш хост в одну з указаних вами IP-адрес (по одній адресі IPv4 чи IPv6 на рядок, та сама поведінка розбиття при вставці, що й у списку custom DNS вище). Якщо хост починає розв'язуватися десь-інде - перехоплення DNS, неправильно налаштований запис, прострочений запис, - перевірка провалюється, навіть якщо щось за новою адресою й далі відповідає на пінги. Лишіть вимкненим, якщо не потрібно жорстко прив'язувати хост до конкретних адрес.

Alert Subscriptions

• Підписати всі контакти на події Up/Down: перемикач-ярлик, що одним рухом підписує всіх контактів вашого акаунта на сповіщення Up і Down для цього монітора.
• Перемикачі Down / Up / Repeat для кожного контакту: оберіть саме ті події, про які дізнається кожен контакт. Down спрацьовує при переході в стан збою, Up спрацьовує при відновленні, а Repeat повторно надсилає сповіщення Down за розкладом, поки монітор лишається в Down, тож тривалий збій не замовкає після першого сповіщення.
• Search contacts: фільтрує список за ім'ям чи адресою.

Report Subscriptions

• Підписати всі контакти на щотижневі/щомісячні звіти: підписує всіх контактів на обидві періодичності одразу.
• Перемикачі Daily / Weekly / Monthly для кожного контакту: оберіть, який регулярний лист зі зведенням аптайму отримує кожен контакт, незалежно від сповіщень у реальному часі вище.

Monitoring Locations

• Дерево локацій: оберіть, які локації моніторингу HostTracker виконують цю перевірку - за континентом, країною чи весь світ. Стовпець статусу показує, скільки агентів у кожній групі вибрано зараз із загальної кількості наявних там. «Copy locations from another task» клонує набір локацій наявного монітора замість того, щоб збирати його заново вручну.
• Search locations: фільтрує дерево за назвою.
• Стратегія повторної перевірки: керує тим, як підтверджується зміна стану, перш ніж її буде прийнято. За замовчуванням - голосування більшістю серед локацій повторної перевірки. Альтернативи: конкретна кількість локацій, що підтверджують Down (повзунок від 1 до 7, оскільки пул повторної перевірки набирають із щонайбільше 7 локацій); взагалі без повторної перевірки, коли першому результату довіряють одразу; повна згода всіх локацій повторної перевірки; або повна згода для Down, тоді як для Up достатньо більшості.
• Якщо вибрані локації недоступні: що відбувається, коли вибрані вами локації тимчасово офлайн. «Тільки вибрані локації» (за замовчуванням) чекає, поки одна з них повернеться, замість того щоб підставляти дані звідкись іще. «Найближчі локації» замість цього перезапускає перевірку з найближчих доступних локацій. «Будь-яка локація» перемикається на будь-яку доступну локацію по всьому світу.

Розібраний приклад

Припустімо, вам потрібен базовий моніторинг досяжності офісного VPN-шлюзу, на якому не піднято вебсервер. Встановіть в Url / Domain / IP публічний IP шлюзу й назвіть його "hq-vpn-gateway". У голого IP нема чого розв'язувати, тож лишіть Request Configuration за замовчуванням, і Response Validation теж лишіть за замовчуванням - однієї ICMP-відповіді із чотирьох спроб достатньо, щоб зарахувати Up. У Monitoring Locations оберіть дві-три локації, розкидані по регіонах, щоб локальний мережевий збій біля однієї з них сам по собі не спричинив хибне сповіщення, і лишіть Recheck strategy на голосуванні більшістю за замовчуванням. В Alert Subscriptions підпишіть вашого контакта з операційної команди і на Down, і на Up, і увімкніть Repeat, щоб і далі дізнаватися про проблему, якщо збій затягнеться. Додайте підписку на щотижневий звіт, якщо хочете регулярне зведення аптайму поряд зі сповіщеннями в реальному часі.

Діагностика

• ICMP заблоковано, HTTP гаразд: багато хмарних провайдерів і файрволів за замовчуванням блокують ICMP echo, продовжуючи при цьому нормально віддавати HTTP/HTTPS, тож перевірка Ping може показувати Down для сайту, що насправді віддає трафік. Або відкрийте ICMP у файрволі цілі, або перемкніться для цієї цілі на перевірку HTTP чи TCP-порту.
• Expected IPs застаріває: якщо ви увімкнули Expected IPs Validation, а потім перенесли хости чи змінили DNS-провайдера, ви побачите хибні Down, поки список очікуваних IP не збігатиметься з новими адресами.
• Кілька DNS-кандидатів можуть маскувати одну мертву адресу: оскільки перевірка повторює спробу для щонайбільше двох інших адрес, розв'язаних через DNS, перш ніж провалитися, домен із кількома A-записами може й далі показувати Up, навіть якщо одна конкретна адреса перестала відповідати. Моніторте окремі IP напряму або увімкніть Expected IPs Validation, щоб це впіймати.
• Немає налаштовуваного тайм-ауту: на відміну від деяких інших типів перевірки, таймінг окремої спроби в ping не налаштовується з цієї форми. Для більшої терпимості перед спрацюванням сповіщення використовуйте Recheck strategy в Monitoring Locations, а не шукайте поле тайм-ауту, якого тут немає.
• Відповідь не означає, що служба здорова: вона лише каже, що пристрій відповідає на ICMP, а не що на ньому працює щось корисне. Поєднуйте перевірку Ping із перевіркою HTTP чи порту на тому самому хості, щоб підтвердити, що справжня служба справді віддає трафік.

Пов'язане

• Моніторинг Ping - сторінка продукту для цього типу перевірки.
• Безкоштовний тест Ping - виконайте разовий пінг без створення монітора.
• Моніторинг трасування - природний наступний крок, коли перевірка Ping йде в Down: подивитися, де обривається маршрут.
• Безкоштовний інструмент трасування - виконайте разове трасування миттєво.
• Режим тверджень: повний довідник з перевірки відповіді - мова правил перевірки відповіді, що використовується й в інших типах перевірок.
• Сайт недоступний для всіх чи лише для мене? - разова версія того самого питання, виконана ззовні вашої мережі.
• Усі посібники з моніторингу - посібник з налаштування для кожного іншого типу перевірки.