Посібник з налаштування моніторингу бази даних

Перш ніж почати

Перевірки Database не йдуть із розподіленої публічної мережі моніторингу HostTracker так, як це робить перевірка Http чи Ping, тому в цій формі взагалі немає розділу «Локації моніторингу». Натомість кожна перевірка звертається до вашого сервера з власної приватної інфраструктури перевірки HostTracker, використовуючи дві фіксовані початкові адреси: 4.207.101.172 і 20.107.152.200 (Північна Європа). Перш ніж зберегти монітор, додайте обидві адреси до списку дозволених файрвола чи групи безпеки сервера бази даних і переконайтеся, що сервер приймає з'єднання на своєму порту з публічного інтернету, або принаймні з цих двох адрес. Якщо порт недосяжний, кожна перевірка провалюється з помилкою з'єднання, незалежно від того, як налаштовано решту монітора.

Налаштуйте сам моніторинговий акаунт, перш ніж починати: створіть користувача бази даних спеціально для перевірки, дайте йому лише те, що потрібно перевірці (зазвичай це просто право підключитися, плюс SELECT на таблицю, до якої звертається ваш запит), і уникайте повторного використання акаунта застосунку чи адміністратора. Якщо запит, який ви плануєте виконувати, змінює дані, дайте цьому акаунту право запису лише на конкретну задіяну таблицю, не ширше.

Цільова база даних

Три поля визначають, до чого підключається перевірка, і стоять над секціями, що згортаються, оскільки вони обов'язкові:

• Тип сервера - розкривний список підтримуваних провайдерів: Microsoft SQL Server, Oracle, MySQL, PostgreSQL і Firebird.
• Сервер : Порт - ім'я хоста чи IP сервера бази даних і його порт. Під час зміни типу сервера автоматично підставляється типовий порт цього провайдера (1433 для SQL Server, 1521 для Oracle, 3306 для MySQL, 5432 для PostgreSQL, 3050 для Firebird) - перевизначати його потрібно, лише якщо ваш сервер слухає на іншому порту.
• Database (або, для Oracle, замість цього Service і Instance name (SID)) - назва бази даних для підключення. Для Oracle можна вказати назву сервісу, SID, або обидва значення, залежно від того, як налаштовано ваш listener.

Нижче необов'язкове поле Name дає змогу підписати монітор для сповіщень, звітів і віджетів - корисно, коли у вас більш ніж одна перевірка бази даних і їх потрібно швидко розрізняти.

Main Settings

Ця група містить розклад і два загальні перемикачі, які є в будь-якого типу перевірки:

• Interval - як часто виконується перевірка, доступні значення від 10 хвилин до 24 годин (10, 15, 30, 45 хвилин, тоді 1, 2, 4, 6, 12 і 24 години), плюс альтернатива у вигляді cron-розкладу для менш регулярного графіка. Перевірки Database не пропонують інтервали коротші за 10 хвилин, доступні в деяких інших типів перевірок.
• Tags - довільні мітки для групування й фільтрування моніторів в інших місцях панелі керування.
• Full Log - зберігає кожен окремий результат перевірки замість лише згрупованих зведень, корисно, коли потрібно бачити точний час відповіді чи значення в часі, а не лише історію "працює/не працює".
• Open Stats - робить сторінку статистики й логу цього монітора доступною для перегляду, зокрема людям без входу в акаунт.

Connection

Оскільки ціль уже задано вище, цей розділ описує, як перевірка автентифікується і як вона обробляє невдалу спробу підключення:

• DB user name і DB user password - облікові дані моніторингового акаунта, описаного вище. Обидва поля необов'язкові: лишіть їх порожніми, якщо ваша база даних допускає довірене чи анонімне підключення з адреси зі списку дозволених, що буває в деяких внутрішніх налаштуваннях.
• Сама панель показує дві початкові адреси, з яких виконуються перевірки (4.207.101.172, 20.107.152.200), з нагадуванням додати їх до списку дозволених файрвола вашої бази даних - це та сама вимога, що описана в розділі «Перш ніж почати», повторена тут, бо саме тут перебувають облікові дані.
• Retry on connect fail - перемикач, увімкнений за замовчуванням, що повторює спробу підключення один раз, перш ніж позначити перевірку як провалену. Він стосується лише самого кроку підключення, а не запиту.

Response Validation

Це ключове рішення в перевірці Database: тестуєте ви саму працездатність з'єднання чи те, що конкретний запит і далі поводиться як очікується.

• Query - лишіть це поле порожнім, і перевірка тестуватиме лише з'єднання: воно відкривається і закривається, і це вся перевірка цілком. Впишіть будь-який SQL, який дозволено виконувати вашому моніторинговому акаунту, - SELECT чи інструкцію, що змінює дані, на кшталт UPDATE, DELETE чи INSERT, - і перевірка виконуватиме його при кожному опитуванні й зможе оцінювати результат.
• Query result (показується лише після введення запиту) - оберіть Scalar value, щоб прочитати значення з першого стовпця першого поверненого рядка (природний вибір для SELECT, або для UPDATE/INSERT із реченням OUTPUT), або Row count, щоб прочитати, скільки рядків було зачеплено (природний вибір для звичайного UPDATE, DELETE чи INSERT без власного набору результатів).
• Result verification - порівняння, застосоване до цього значення: No verification (запит просто має виконатися без помилки), Equal to, Not equal to, Greater than, Less than, In range чи Out of range. Варіанти більше/менше й діапазон додають одне чи два числові поля з перемикачем включення/виключення на кожній межі діапазону.
• Retry query on error - перемикач, увімкнений за замовчуванням, що повторює виконання запиту один раз у разі невдачі, окремо від повтору на рівні з'єднання вище.

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

Alert Subscriptions

Виберіть, які контакти дізнаються про цей монітор і за якими подіями - Up, Down і Repeat (повторне нагадування, поки перевірка лишається в Down). Один перемикач підписує всі контакти одразу на Up/Down, або оберіть окремі контакти й події в таблиці під ним.

Report Subscriptions

Окремо від сповіщень оберіть, хто отримує періодичні звіти про аптайм і продуктивність цього монітора - щоденні, щотижневі чи щомісячні - електронною поштою.

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

Спостереження за продакшн-базою PostgreSQL, від якої залежить застосунок: тип сервера PostgreSQL, Сервер : Порт db.example.com:5432, база даних myapp_prod. У розділі Connection вказано виділений акаунт лише для читання, а обидві початкові IP-адреси заздалегідь додано до групи безпеки бази даних. У полі Query вказано SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Query result - Scalar value, а Result verification - Greater than з лімітом 0: якщо за останню годину не записано жодного замовлення, значить щось вище за течією перестало писати, і перевірка йде в Down, навіть попри те що база даних досяжна. Interval - 15 хвилин, обидва перемикачі Retry лишаються ввімкненими, щоб короткочасний збій не піднімав хибне сповіщення, сповіщення йдуть усій команді за підпискою Up/Down, а щотижневий звіт іде власнику акаунта.

Діагностика

• Кожна перевірка провалюється з помилкою з'єднання. Найпоширеніша причина - файрвол, не відкритий для двох початкових адрес HostTracker: переконайтеся, що 4.207.101.172 і 20.107.152.200 у списку дозволених, і що сам порт відкритий для них.
• З'єднання встановлюється, але автентифікація провалюється. Перевірте, що ім'я користувача й пароль БД правильні і що акаунт має право підключатися саме до вказаної бази даних, а не лише до сервера.
• Запит, що чудово працює в клієнтському інструменті, тут нічого не повертає. У звичайного UPDATE, DELETE чи INSERT без речення OUTPUT немає набору результатів, який можна прочитати як Scalar value - перемкніть Query result на Row count, або додайте речення OUTPUT, якщо вам потрібні дані рядка назад.
• Result verification ніколи не спрацьовує. Переконайтеся, що порівняння й числові поля відповідають очікуваному діапазону: межа, встановлена як "виключена", а не "включена", - простий спосіб зробити так, щоб ліміт ніколи не спрацював.
• Поодинокі збої, які ви підозрюєте короткочасними. Обидва перемикачі повтору ввімкнені за замовчуванням і вже повторюють спробу один раз, перш ніж провалити перевірку - якщо збої все одно часті, проблема радше реальна, пов'язана зі з'єднанням чи запитом, а не шум.

Пов'язане

• Моніторинг запитів до бази даних - сторінка продукту для цього типу перевірки.
• Посібник з моніторингу CPU, RAM і диска - ще одна перевірка, що працює з приватної інфраструктури HostTracker, а не з публічної мережі, корисна поряд із перевіркою бази даних на тому самому сервері.
• Посібник з моніторингу SNMP - для читання значень напряму з мережевого обладнання замість бази даних.
• Режим тверджень і правила перевірки відповіді - мова правил перевірки відповіді, що використовується й в інших типах перевірок HostTracker.
• Усі можливості моніторингу HostTracker - перегляньте всі типи перевірок поруч одне з одним.
• 503 Service Unavailable - статус, який сайт повертає, коли база даних за ним перестає відповідати.
• Усі посібники з моніторингу - посібник з налаштування для кожного іншого типу перевірки.