check_postgres_database_sizep - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

check_postgres - сценарій моніторингу Postgres для Nagios, MRTG, Cacti та інших

Цей документ описує check_postgres версії 2.22.0

СИНТАКСИС

## Створіть усі символічні посилання
check_postgres --символьні посилання

## Перевірте підключення до бази даних Postgres 'pluto':
check_postgres --action=з'єднання --db=pluto

## Те саме, але з використанням символічного посилання
check_postgres_connection --db=плутон

## Попереджати, якщо > 100 блокувань, критично, якщо > 200, або > 20 виключних
check_postgres_locks --warning=100 --critical="total=200:exclusive=20"

## Показати поточну кількість неактивних з'єднань на порту 6543:
check_postgres_txn_idle --port=6543 --output=простий

## Є багато інших дій та варіантів, будь ласка, продовжуйте читати.

Останні новини та документацію завжди можна знайти за адресою:
http://bucardo.org/check_postgres/

ОПИС

check_postgres — це скрипт Perl, який виконує багато різних тестів для одного або кількох
Бази даних Postgres. Він використовує програму psql для збору інформації та виводить файл
результати в одному з трьох форматів: Nagios, MRTG або просто.

Вихід Режими
Вихід можна змінити за допомогою параметра «--output». Вихід за замовчуванням – nagios,
хоча за бажанням це можна змінити у верхній частині сценарію. Поточний варіант
вибір є Nagios, mrtg та простий. Щоб уникнути необхідності вводити вихідний аргумент кожний
часу, тип виводу встановлюється автоматично, якщо не вказано аргумент --output, і якщо параметр
поточний каталог має одну з опцій виводу в назві. Наприклад, створення a
каталогу з ім’ям mrtg і заповнюючи його символічними посиланнями через файл --символьні посилання аргумент би
переконайтеся, що будь-які дії, запущені з цього каталогу, завжди будуть за замовчуванням виводити «mrtg»
Як ярлик для --output=simple, ви можете ввести --simple, який також замінює
трюк з іменуванням каталогу.

Нагіос вихід

Формат виводу за замовчуванням призначений для Nagios, який є одним рядком інформації разом із
чотири конкретні коди виходу:

0 (ОК)
1 (УВАГА)
2 (КРИТИЧНО)
3 (НЕВІДОМО)

Вихідний рядок – це одне із наведених вище слів, двокрапка, а потім короткий опис чого
був виміряний. Додаткова статистика, а також загальний час виконання команди
take, також можна вивести: дивіться документацію щодо аргументів --showperf,
-- perflimit та --час показу.

MRTG вихід

Вихід MRTG складається з чотирьох рядків, причому перший рядок завжди дає одне число
важливості. Якщо можливо, це число представляє фактичне значення, наприклад число
байт, але це також може бути 1 або 0 для дій, які повертають лише "true" або "false", наприклад
як check_postgres_version. Другий рядок є додатковою характеристикою і використовується лише для
деякі дії. Третій рядок вказує на «час роботи» і не використовується. Четвертий рядок - а
опис і зазвичай вказує ім'я бази даних стат з першого рядка
було вилучено з, але може відрізнятися залежно від дії.

Деякі дії приймають необов’язковий --mrtg аргумент для подальшого контролю виходу.

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

простий вихід

Простий вихід – це просто урізана версія MRTG і просто повертає
перший номер і більше нічого. Це дуже корисно, коли ви просто хочете перевірити стан
чогось, незважаючи на будь-який поріг. Ви можете перетворити числовий вихід за допомогою
додавання KB, MB, GB, TB або EB до вихідного аргументу, наприклад:

--output=простий,МБ

Кактуси вихід

Вихід Ccti складається з одного або кількох елементів в одному рядку з простою назвою a
двокрапку, а потім число. На даний момент єдиною дією з явним виведенням Cacti є
'dbstats', а використання параметра --output у цьому випадку не потрібне, оскільки Cacti є єдиним
вихід для цієї дії. Для багатьох інших дій достатньо використовувати --simple, щоб зробити Кактуси
щасливий.

DATABASE ПІДКЛЮЧЕННЯ ВАРІАНТИ

Усі дії приймають загальний набір параметрів бази даних.

-H ІМ'Я or --host=NAME
Підключіться до хоста, зазначеного NAME. Може бути список імен, розділених комами.
Допускається кілька аргументів хоста. Якщо хост не вказано, за замовчуванням встановлюється "PGHOST"
змінна середовища або взагалі відсутній хост (що вказує на використання локального Unix-сокета).
Ви також можете використовувати "--dbhost".

-p PORT or --порт=ПОРТ
Підключається за допомогою вказаного номера PORT. Може бути список портів, розділених комами
чисел, а також допускається кілька аргументів порту. Якщо номер порту не вказано, значення за замовчуванням
до змінної середовища "PGPORT". Якщо це не встановлено, за замовчуванням встановлено значення 5432. Ви можете
також використовуйте "--dbport"

-дб ІМ'Я or --dbname=ІМ'Я
Вказує, до якої бази даних підключатися. Може бути розділений комами список імен і
Допускається декілька аргументів dbname. Якщо параметр dbname не надано, за замовчуванням
змінна середовища "PGDATABASE". Якщо це не встановлено, за замовчуванням він має значення "postgres"
якщо psql є версією 8 або новішої, і 'template1' в іншому випадку.

-u USERNAME or --dbuser=ІМ'Я КОРИСТУВАЧА
Ім'я користувача бази даних для підключення. Це може бути список, розділений комами
імена користувачів, а також дозволено кілька аргументів dbuser. Якщо цього не передбачено, то
за замовчуванням має значення змінної середовища "PGUSER", інакше - "postgres".

--dbpass=ПАРОЛЬ
Надає пароль для підключення до бази даних. Використання цієї опції дуже велике
знеохочений. Замість цього слід використовувати файл .pgpass або pg_service.conf.

--dbservice=ІМЯ
Ім'я служби всередині файлу pg_service.conf. До версії 9.0
Postgres, це глобальний файл, зазвичай знаходиться в /etc/pg_service.conf. Якщо ви
використовуючи Postgres версії 9.0 або вище, ви можете використовувати файл ".pg_service.conf" у
домашній каталог користувача, який запускає скрипт, наприклад nagios.

Цей файл містить простий список параметрів підключення. Ви також можете передати додаткові
інформація під час використання цієї опції, наприклад --dbservice="maindatabase sslmode=require"

Документацію до цього файлу можна знайти за адресою
http://www.postgresql.org/docs/current/static/libpq-pgservice.html

Варіанти підключення до бази даних можна згрупувати: --хост=a,b --host=c --порт=1234
--порт=3344 підключатиметься до a-1234, b-1234 і c-3344. Зауважте, що після встановлення опція
зберігається, поки не буде знову змінено.

Приклади:

--host=a,b --port=5433 --db=c
Двічі підключається до порту 5433, використовуючи базу даних c, до хостів a і b: a-5433-c b-5433-c

--host=a,b --port=5433 --db=c,d
Підключається чотири рази: a-5433-c a-5433-d b-5433-c b-5433-d

--host=a,b --host=foo --port=1234 --port=5433 --db=e,f
Підключається шість разів: a-1234-e a-1234-f b-1234-e b-1234-f foo-5433-e foo-5433-f

--host=a,b --host=x --port=5432,5433 --dbuser=alice --dbuser=bob -db=baz
Підключається тричі: a-5432-alice-baz b-5433-alice-baz x-5433-bob-baz

--dbservice="foo" --port=5433
Підключається за допомогою названої служби 'foo' у файлі pg_service.conf, але замінює порт

ІНШІ ВАРІАНТИ

Інші варіанти включають:

--action=NAME
Вказує, які дії ми проводимо. Обов’язковий, якщо не використовується файл із символічним посиланням, у якому
якщо ім'я файлу використовується для визначення дії.

--warning=VAL or -w VAL
Встановлює поріг, при якому спрацьовує попередження. Допустимі варіанти для цього
опція залежить від використовуваної дії.

--критично = VAL or -c VAL
Встановлює поріг, при якому спрацьовує критичне сповіщення. Допустимі варіанти для цього
опція залежить від використовуваної дії.

-t VAL or --timeout=VAL
Встановлює час очікування в секундах, після якого сценарій припиняє все, що він робив
повернути статус НЕВІДНО. Час очікування для кластера Postgres, а не для всього
сценарій. Значення за замовчуванням — 10; одиниці вимірювання завжди в секундах.

--припустимо-режим очікування
Якщо вказано, спочатку буде виконано перевірку, чи сервер у режимі очікування (--datadir
якщо так, усі перевірки, які вимагають SQL-запитів, ігноруватимуться і «Server
в режимі очікування» зі статусом OK.

приклад:

postgres@db$./check_postgres --action=version --warning=8.1 --datadir /var/lib/postgresql/8.3/main/ --assume-standby-mode
POSTGRES_VERSION OK: Сервер у режимі очікування | час=0.00

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

приклад:

postgres@db$./check_postgres --action=checkpoint --datadir /var/lib/postgresql/8.3/main/ --assume-prod
POSTGRES_CHECKPOINT OK: Остання контрольна точка була 72 секунди тому | вік=72;;300 режим=МАСТЕР

-h or --допомога
Відображає екран довідки з підсумком усіх дій і параметрів.

-- чоловік
Відображає весь посібник.

-V or -- версія
Показує поточну версію.

-v or -багатослівний
Встановіть рівень детальності. Можна подзвонити кілька разів, щоб підвищити рівень. Налаштування на
три або вище (іншими словами, видача "-v -v -v") вмикає інформацію про налагодження
для цієї програми, яка надсилається до stderr.

--showperf=VAL
Визначає, чи ми виводимо додаткові дані про продуктивність у стандартному форматі Nagios (в кінці
рядка після символу вертикальної лінії, використовуючи ім’я=значення). VAL має бути 0 або 1. За замовчуванням
дорівнює 1. Набирає чинності лише при використанні режиму виводу Nagios.

--perflimit=i
Встановлює обмеження щодо кількості цікавих об’єктів, які повертаються під час використання
showperf варіант. Це впливає лише на дії, які повертають велику кількість
предмети, такі як розмір_таблиці. За замовчуванням 0 або без обмежень. Будьте обережні, використовуючи це
з --включати or --виключити варіанти, оскільки ці обмеження діють після
запит було виконано, і, таким чином, ваше обмеження може не включати потрібні елементи. Тільки бере
ефект, якщо використовується режим виводу Nagios.

--showtime=VAL
Визначає, чи відображається час, необхідний для виконання кожного запиту, у вихідних даних. VAL має бути 0
або 1. За замовчуванням 1. Немає ефекту, якщо showperf увімкнено. Набирає чинності лише при використанні
Режим виведення Nagios.

--тест
Вмикає тестовий режим. Дивіться розділ «ТЕСТОВИЙ РЕЖИМ» нижче.

--PGBINDIR=ШЛЯХ
Повідомляє скрипту, де знайти двійкові файли psql. Корисно, якщо у вас більше одного
версії виконуваних файлів PostgreSQL у вашій системі, або якщо їх немає у вашій
шлях. Зауважте, що ця опція написана у верхньому регістрі. За замовчуванням ця опція є НЕ
дозволено. Щоб увімкнути його, ви повинні змінити $NO_PSQL_OPTION у верхній частині сценарію
до 0. Уникайте використання цієї опції, якщо можете, а замість цього використовуйте змінну середовища
c або жорстко закодована змінна $PGBINDIR, також у верхній частині сценарію, щоб встановити
шлях до PostgreSQL для використання.

--PSQL=ШЛЯХ
(не підтримується, це варіант може be віддалений in a майбутнє звільни!) Вказує сценарій, де
щоб знайти програму psql. Корисно, якщо у вас є кілька версій psql
виконуваний у вашій системі, або якщо на вашому шляху немає програми psql. Зверніть увагу, що це
опція у верхньому регістрі. За замовчуванням ця опція є НЕ дозволено. Щоб увімкнути його, ви
необхідно змінити $NO_PSQL_OPTION у верхній частині сценарію на 0. Уникайте використання цього
варіант, якщо ви можете, і замість цього жорстко закодуйте своє розташування psql у змінній $PSQL,
також у верхній частині сценарію.

--символьні посилання
Створює символічні посилання на основну програму для кожної дії.

--вихід=VAL
Визначає формат виводу для використання в різних програмах. За замовчуванням є
'nagios'. Доступні параметри: "nagios", "mrtg", "simple" і "cacti".

--mrtg=VAL
Використовується лише для MRTG або простого виводу, для кількох конкретних дій.

--debugoutput=VAL
Виводить точний рядок, який повертає psql, для використання під час налагодження. Значення - один або
більше літер, які визначають, відображатиметься результат чи ні, де 'a' = все, 'c'
= критично, 'w' = попередження, 'o' = добре, і 'u' = невідомо. Букви можна комбінувати.

--get_method=VAL
Дозволяє специфікувати метод, який використовується для отримання інформації для "new_version_cp",
Перевірки "new_version_pg", "new_version_bc", "new_version_box" і "new_version_tnm".
Наступні програми намагаються отримати інформацію з Інтернету: GET,
wget, fetch, curl, lynx, посилання. Щоб змусити використовувати лише один (і таким чином видалити
накладні витрати на спробу всіх інших, поки одна з цих не спрацює), введіть одне з назв як
аргумент get_method. Наприклад, поле BSD може ввести наступний рядок
їхній файл ".check_postgresrc":

get_method=вибірка

--мова=VAL
Встановіть мову для всіх вихідних повідомлень. Зазвичай це виявляється за допомогою
перевіряючи змінні середовища LC_ALL, LC_MESSAGES і LANG, але встановлюючи це
параметр перевизначить будь-яке таке виявлення.

ДІЇ

Сценарій виконує одну або кілька дій. Це можна зробити або за допомогою прапорця --action, або за допомогою
використовуючи символічне посилання на основний файл, що містить назву дії всередині нього. Для
наприклад, щоб запустити дію "timesync", ви можете виконати:

check_postgres --action=timesync

або скористайтеся програмою з назвою:

check_postgres_timesync

Усі символічні посилання створюються для вас у поточному каталозі, якщо використовувати параметр --symlinks

perl check_postgres --символьні посилання

Якщо ім'я файлу вже існує, воно не буде перезаписано. Якщо файл існує і є a
символічного посилання, ви можете змусити його перезаписати, використовуючи "--action=build_symlinks_force"

Більшість дій здійснюють а --увага і --критично параметр, що вказує, в який момент ми змінюємо
від ОК до ПОПЕРЕДЖЕННЯ, а в який момент ми переходимо до КРИТИЧНОГО. Зауважте, що оскільки критичні
завжди перевіряється першим, встановлення попередження рівним критичному є ефективним способом
вимкнути попередження і завжди давати критичне значення.

Поточні підтримувані дії:

archive_ready
("symlink: check_postgres_archive_ready") Перевіряє, скільки файлів WAL з розширенням .готовий
існують у pg_xlog/archive_status каталог, який знайдено поза вашим каталог_даних.
Цю дію необхідно виконати як суперкористувач, щоб отримати доступ до вмісту файлу
pg_xlog/archive_status каталог. Мінімальна версія для використання цієї дії – Postgres 8.1.
Команда --увага та --критично варіанти - це просто кількість .готовий файли в
pg_xlog/archive_status каталог. Зазвичай ці значення мають бути низькими, вмикаючи
Механізм архівування, ми зазвичай хочемо, щоб файли WAL архівувалися якомога швидше.

Якщо команда архівування не вдалася, номер WAL у вашому pg_xlog каталог буде рости до тих пір, поки
виснажує весь дисковий простір і змушує PostgreSQL негайно зупинитися.

Приклад 1: Перевірте, чи кількість готових файлів WAL становить 10 або менше на хості "pluto"

check_postgres_archive_ready --host=pluto --critical=10

Для виведення MRTG повідомляє кількість готових файлів WAL у рядку 1.

autovac_freeze
("symlink: check_postgres_autovac_freeze") Перевіряє, наскільки близько кожна база даних знаходиться до
Постгрес autovacuum_freeze_max_age налаштування. Ця дія працюватиме лише для баз даних
версія 8.2 або вище. The --увага та --критично варіанти мають бути виражені як
відсотки. «Вік» транзакцій у кожній базі даних порівнюється з
autovacuum_freeze_max_age (200 мільйонів за замовчуванням), щоб створити округлений
відсоток. Значення за замовчуванням: 90% за попередження і 95% для критичних. Бази даних
можна відфільтрувати за допомогою --включати та --виключити варіанти. Дивіться розділ «ОСНОВНА ФІЛЬТРАЦІЯ»
розділ, щоб дізнатися більше.

Приклад 1. Видавати попередження, коли будь-які бази даних на порту 5432 перевищують 97%

check_postgres_autovac_freeze --port=5432 --warning="97%"

Для виходу MRTG найвищий загальний відсоток повідомляється в першому рядку та
найвищий вік зазначено у другому рядку. Усі бази даних, які мають відсоток від
перший рядок повідомляється в четвертому рядку, розділених символом вертикальної лінії.

бекенд
("symlink: check_postgres_backends") Перевіряє поточну кількість з'єднань для одного або
більше баз даних і за бажанням порівнює його з максимально дозволеним, який визначається за допомогою
змінну конфігурації Postgres max_connections, --увага та --критично опції
може приймати одну з трьох форм. По-перше, можна дати просте число, яке представляє
кількість з'єднань, на яких буде видано сповіщення. Цей вибір не використовує
max_connections налаштування. По-друге, можна вказати відсоток доступних підключень.
По-третє, можна дати від’ємне число, яке представляє кількість з’єднань, що залишилися
до max_connections досягнуто. Значення за замовчуванням для --увага та --критично він має
"90%" і "95%". Ви також можете фільтрувати бази даних за допомогою --включати та --виключити
варіанти. Додаткову інформацію дивіться у розділі «ОСНОВНА ФІЛЬТРАЦІЯ».

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

Приклад 1. Видавати попередження, коли кількість підключень на хості quirm досягає 120, і
критично, якщо досягає 150.

check_postgres_backends --host=quirm --warning=120 --critical=150

Приклад 2. Дайте критичне значення, коли ми досягнемо 75% наших параметрів max_connections на хостах
lancre або lancre2.

check_postgres_backends --warning='75%' --critical='75%' --host=lancre,lancre2

Приклад 3. Видавати попередження, коли на хості залишилося лише 10 слотів підключення
плазміда, а критична, коли у нас залишилося лише 5.

check_postgres_backends --warning=-10 --critical=-5 --host=plasmid

Приклад 4. Перевірте всі бази даних, окрім тих, у назві яких є "test", але дозвольте такі бази даних
мають назву "pg_greatest". Підключіться як порт 5432 на перших двох хостах і як порт 5433 на
третій. Ми хочемо завжди кидати критичний, коли досягнемо 30 або більше підключень.

check_postgres_backends --dbhost=hong,kong --dbhost=fooey --dbport=5432 --dbport=5433 --warning=30 --critical=30 --exclude="~test" --include="pg_greatest,~prod "

Для виходу MRTG кількість підключень повідомляється в першому і четвертому рядку
рядок вказує ім'я бази даних плюс поточний максимум_з'єднань. Якщо більше ніж
була запитана одна база даних, виводиться та з найбільшою кількістю підключень.

здуття
("symlink: check_postgres_bloat") Перевіряє кількість роздутості в таблицях та індексах. (Здуття
Як правило, це кількість мертвого невикористаного місця, зайнятого в таблиці або індексі. Цей простір є
зазвичай відновлюється за допомогою команди VACUUM.) Для цієї дії необхідна статистика
збір увімкнено в цільових базах даних і вимагає запуску ANALYZE
часто. The --включати та --виключити параметри можна використовувати, щоб відфільтрувати, які таблиці слід
подивись на. Додаткову інформацію дивіться у розділі «ОСНОВНА ФІЛЬТРАЦІЯ».

Команда --увага та --критично параметри можна вказати як розміри, відсотки або обидва. Дійсний
одиницями розміру є байти, кілобайти, мегабайти, гігабайти, терабайти, екзабайти, петабайти та
зеттабайт. Ви можете скоротити всі з першої літери. Предмети без одиниць є
приймаються як "байти". Значеннями за замовчуванням є «1 ГБ» і «5 ГБ». Значення представляє
кількість «витрачених байтів» або різниця між тим, що фактично використовується таблицею і
індекс, і яким ми обчислюємо, що він має бути.

Зауважте, що ця дія має два жорстко закодованих значення, щоб уникнути помилкових тривог на менших
відносини. Таблиці повинні мати щонайменше 10 сторінок, а індекси не менше 15, перш ніж вони можуть бути
розглядається цим тестом. Якщо ви дійсно хочете налаштувати ці значення, ви можете знайти
змінні $MINPAGES та $MINIPAGES у верхній частині підпрограми "check_bloat". Ці
значення ігноруються, якщо обидва --виключити or --включати використовується.

Показано лише топ-10 найбільш роздутих стосунків. Ви можете змінити цей номер за допомогою
-- perflimit можливість встановити власний ліміт.

Схема з назвою 'information_schema' виключена з цього тесту, оскільки в ній є єдині таблиці
містить невеликі і не змінюються.

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

Приклад 1: попереджати, якщо будь-яка таблиця на порту 5432 заповнена понад 100 МБ і критична, якщо більше 200
MB

check_postgres_bloat --port=5432 --warning='100 M' --critical='200 M'

Приклад 2. Дайте критичне значення, якщо таблиця 'orders' на хості 'sami' має більше 10 мегабайт роздутості

check_postgres_bloat --host=sami --include=orders --critical='10 МБ'

Приклад 3. Дайте критичне значення, якщо таблиця "q4" у базі даних "продажі" більш ніж на 50% роздута

check_postgres_bloat --db=sales --include=q4 --critical='50%'

Приклад 4: Дайте критичне значення, будь-яка таблиця роздута на 20%. та має понад 150 МБ роздутості:

check_postgres_bloat --port=5432 --critical='20% і 150 M'

Приклад 5: Дайте критичне значення, будь-яка таблиця роздута на 40%. or має понад 500 МБ роздутості:

check_postgres_bloat --port=5432 --warning='500 M або 40%'

Для виводу MRTG перший рядок дає найбільшу кількість втрачених байтів для таблиць,
а другий рядок дає найбільшу кількість втрачених байтів для індексів. Четвертий
рядок містить інформацію про назву бази даних, ім’я таблиці та назву індексу. Якщо ти хочеш
замість цього виведіть коефіцієнт роздуття (у скільки разів більше відношення порівняно з як
великим це має бути), просто введіть "--mrtg=ratio".

КПП
("symlink: check_postgres_checkpoint") Визначає, скільки часу відбулася остання контрольна точка
запущено. Це повинно виконуватися на тому ж сервері, що й база даних, яка перевіряється (наприклад,
-h прапор не працюватиме). Ця перевірка призначена для виконання на сервері «теплого очікування».
активно обробляє надіслані файли WAL, і призначений для перевірки того, чи працює ваше гаряче очікування
справді «теплий». Каталог даних має бути встановлений або змінною середовища
"PGDATA" або передача аргументу "--datadir". Він повертає кількість секунд, що пройшли з моменту
була запущена остання контрольна точка, як визначено шляхом аналізу виклику "pg_controldata". Тому що
при цьому виконуваний файл pg_controldata повинен бути доступним у поточному шляху. Крім того,
Ви можете вказати "PGBINDIR" як каталог, в якому він знаходиться. Також можна використовувати
спеціальні опції --припустимо-прод or --припустимо-режим очікування, якщо знайдений режим не є
один очікуваний, випромінюється CRITICAL.

Необхідно встановити принаймні одне попередження або критичний аргумент.

Для цієї дії потрібен модуль Date::Parse.

Для MRTG або простого виведення повертає кількість секунд.

cluster_id
("symlink: check_postgres_cluster-id") Перевіряє, чи надано системний ідентифікатор бази даних
від pg_controldata такий самий, як і востаннє, коли ви перевіряли. Це повинно виконуватися на тому ж сервері
як база даних, яка перевіряється (наприклад, прапор -h не працюватиме). Або
--увага або --критично Варто надати варіант, але не обидва. Цінність кожного з них
ідентифікатор кластера, ціле значення. Ви можете запустити зі спеціальним "--critical=0"
можливість дізнатися існуючий ідентифікатор кластера.

Приклад 1: Знайдіть початковий ідентифікатор

check_postgres_cluster_id --critical=0 --datadir=/var//lib/postgresql/9.0/main

Приклад 2. Переконайтеся, що кластер однаковий, і попередьте, якщо ні, використовуючи результат зверху.

check_postgres_cluster_id --critical=5633695740047915135

Для виводу MRTG повертає 1 або 0, що вказує на успіх збою ідентифікатора
матч. Як аргумент «--mrtg» необхідно надати ідентифікатор. Четвертий рядок завжди
дає поточний ідентифікатор.

commitratio
("symlink: check_postgres_commitratio") Перевіряє співвідношення фіксації всіх баз даних і
скаржиться, коли вони занадто низькі. Немає необхідності виконувати цю команду більше одного разу
кластер баз даних. Бази даних можна фільтрувати за допомогою --включати та --виключити варіанти. Побачити
розділ «ОСНОВНА ФІЛЬТРАЦІЯ» для отримання додаткової інформації. Їх також може відфільтрувати власник
база даних з --includeuser та --excludeuser варіанти. Дивіться "ІМ'Я КОРИСТУВАЧА
ФІЛЬТРУВАННЯ» для більш детальної інформації.

Попередження та критичні параметри слід вказати у відсотках. Нема
значення за замовчуванням для цієї дії: необхідно вказати попередження та критичний. Значення попередження
не може перевищувати критичне значення. Вихід повертає всі бази даних, відсортовані за
commitratio, найменший спочатку.

Приклад: попереджати, якщо будь-яка база даних на флагі хоста становить менше 90% у commitratio та є критичною
якщо менше 80%.

check_postgres_database_commitratio --host=flagg --warning='90%' --critical='80%'

Для виводу MRTG повертає відсоток бази даних з увімкненою найменшою фіксацією
перший рядок, а ім'я бази даних у четвертому рядку.

зв'язку
("symlink: check_postgres_connection") Просто підключається, видає "SELECT версія()', і
листя. Бере ні --увага or --критично Варіанти.

Для виходу MRTG просто виводить 1 (гарне з’єднання) або 0 (погане з’єднання) на першому
лінія.

custom_query
("symlink: check_postgres_custom_query") Виконує користувацький запит на ваш вибір та аналізує
результати. Сам запит передається через аргумент "запит" і має бути таким
максимально простий. Якщо це взагалі можливо, оберніть його у подання або функцію, щоб зберегти
речами легше керувати. Запит повинен повертати один або два стовпці. Це вимагається
один із стовпців матиме назву "результат" і є елементом, який буде перевірено з вашим
попереджувальні та критичні значення. Другий стовпець містить дані про продуктивність і будь-яку назву
можна використовувати: це буде «значення» всередині розділу даних про продуктивність.

Необхідно вказати принаймні одне попередження або критичний аргумент. На що вони налаштовані, залежить
за типом запиту, який ви виконуєте. Існують чотири типи custom_queries
run, визначений аргументом "valtype". Якщо нічого не вказано, ця дія за замовчуванням
'ціле число'. Є чотири типи:

ціле: Виконує просте ціле порівняння. Перший стовпець має бути простим цілим числом,
а значення попередження та критичні значення мають бути однаковими.

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

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

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

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

Приклад 1: попередити, якщо будь-яке відношення понад 100 сторінок має назву "rad", введіть кількість сторінок
всередині розділу даних про продуктивність.

check_postgres_custom_query --valtype=string -w "rad" --query=
"SELECT relname AS результат, relpages AS сторінки FROM pg_class WHERE relpages > 100"

Приклад 2. Дайте критичне значення, якщо функція "foobar" повертає число понад 5 МБ:

check_postgres_custom_query --critical='5MB'--valtype=size --query="ВИБРАТИ foobar() AS результат"

Приклад 2: Попередження, якщо функція "snazzo" повертає менше 42:

check_postgres_custom_query --critical=42 --query="SELECT snazzo() AS результат" --reverse

Якщо ви придумали корисний custom_query, розгляньте можливість відправки виправлення до цієї програми на адресу
перетворити його на стандартну дію, яку можуть використовувати інші люди.

Ця дія ще не підтримує MRTG або простий вихід.

розмір_бази
("symlink: check_postgres_database_size") Перевіряє розмір усіх баз даних і скаржиться
коли вони занадто великі. Немає необхідності виконувати цю команду більше одного разу на базу даних
кластер. Бази даних можна фільтрувати за допомогою --включати та --виключити варіанти. Див
Розділ «ОСНОВНА ФІЛЬТРАЦІЯ» для більш детальної інформації. Їх також може відфільтрувати власник
бази даних з --includeuser та --excludeuser варіанти. Дивіться розділ "ФІЛЬТРІВАННЯ ІМЕН КОРИСТУВАЧА"
розділ, щоб дізнатися більше.

Попередження та критичні параметри можна вказати як байти, кілобайти, мегабайти,
гігабайти, терабайти або ексабайти. Кожне може бути скорочено до першої літери.
Якщо одиниці вимірювання не вказано, вважається, що одиниці є байтами. Для цього немає значень за замовчуванням
дія: необхідно вказати попередження та критичний. Значення попередження не може бути більшим
ніж критичне значення. Вихідні дані повертають усі бази даних, відсортовані за найбільшим розміром спочатку,
показує як необроблені байти, так і "гарну" версію розміру.

Приклад 1: попереджати, якщо будь-яка база даних на хості має розмір понад 1 ТБ і критична, якщо більше
1.1 TB.

check_postgres_database_size --host=flagg --warning='1 ТБ' --critical='1.1 t'

Приклад 2: Укажіть критичне значення, якщо розмір бази даних template1 на порту 5432 перевищує 10 МБ.

check_postgres_database_size --port=5432 --include=template1 --warning='10MB' --critical='10MB'

Приклад 3: попередити, якщо будь-яка база даних на хості "tardis", що належить користувачу "tom", закінчилася
5 GB

check_postgres_database_size --host=tardis --includeuser=tom --warning='5 ГБ' --critical='10 ГБ'

Для виводу MRTG повертає розмір у байтах найбільшої бази даних у першому рядку та
ім'я бази даних у четвертому рядку.

dbstats
("symlink: check_postgres_dbstats") Звітує інформацію з представлення pg_stat_database,
і виводить його у зручний для кактусів спосіб. Ніякий інший вихід не підтримується, як і вихід
інформаційний і не піддається сповіщенням, наприклад, що використовується з Nagios. Якщо немає варіантів
дані, повертаються всі бази даних, по одній на рядок. Ви можете включити певну базу даних
за допомогою параметра "--include" або параметра "--dbname".

У кожному рядку повертається одинадцять елементів у форматі ім’я:значення, розділених одиницею
простір. Це:

бекенд
Кількість запущених серверів для цієї бази даних.

зобов'язується
Загальна кількість комітів для цієї бази даних з моменту її створення або скидання.

відкати
Загальна кількість відкатів для цієї бази даних з моменту її створення або скидання.

зчитування
Загальна кількість прочитаних дискових блоків.

hit Загальна кількість звернень в буфер.

ret Загальна кількість повернених рядків.

отримувати
Загальна кількість отриманих рядків.

ins Загальна кількість вставлених рядків.

upd Загальна кількість оновлених рядків.

del Загальна кількість видалених рядків.

dbname
Ім'я бази даних.

Зверніть увагу, що елементи ret, fetch, ins, upd і del завжди будуть рівними 0, якщо Postgres має версію 8.2
або нижче, оскільки ця статистика була недоступна в цих версіях.

Якщо вказано аргумент dbname, повертається сім додаткових елементів:

idxscan
Загальна кількість сканувань індексу користувача.

idxtupread
Загальна кількість повернутих записів індексу користувача.

idxtupfetch
Загальна кількість рядків, отриманих шляхом простого сканування індексу користувача.

idxblksread
Загальна кількість прочитаних дискових блоків для всіх індексів користувача.

idxblkshit
Загальна кількість звернень в буфер для всіх індексів користувачів.

seqscan
Загальна кількість послідовних перевірок усіх таблиць користувачів.

sectupread
Загальна кількість кортежів, повернутих з усіх таблиць користувачів.

Приклад 1. Отримайте статистику для бази даних з назвою "products" на хості "willow":

check_postgres_dbstats --dbhost willow --dbname продукти

Повернутий результат буде таким (все в одному рядку, не загорнутий):

backends: 82 фіксації: 58374408 rollbacks: 1651 read: 268435543 hit: 2920381758 idxscan: 310931294 idxtupread: 2777040927
idxtupfetch:1840241349 idxblksread:62860110 idxblkshit:1107812216 seqscan:5085305 seqtupread:5370500520
ret:0 отримати:0 ins:0 upd:0 del:0 dbname:willow

disabled_triggers
("symlink: check_postgres_disabled_triggers") Перевіряє кількість вимкнених тригерів
всередині бази даних. The --увага та --критично параметри – кількість таких тригерів
знайдено, і обидва за замовчуванням мають значення "1", оскільки при нормальному використанні вимкнення тригерів є небезпечним
подія. Якщо перевіряється база даних 8.3 або вище, перевіряється кількість
тригери, які перебувають у статусі «вимкнено» (на відміну від «завжди» або «репліки»). The
Вихідні дані показують назву таблиці та назву тригера для кожного вимкненого
тригер.

Приклад 1. Переконайтеся, що немає вимкнених тригерів

check_postgres_disabled_triggers

Для виводу MRTG повертає кількість вимкнених тригерів у першому рядку.

disk_space
("symlink: check_postgres_disk_space") Перевіряє доступний фізичний дисковий простір, що використовується
Postgres. Для цієї дії потрібно, щоб у вас був виконуваний файл "/bin/df"доступний для звіту
на дисках розмірів, і його також потрібно запускати як суперкористувач, щоб він міг перевіряти
каталог_даних налаштування всередині Postgres. The --увага та --критично надаються варіанти
у розмірах або у відсотках, або в обох. Якщо використовуються розміри, стандартними є типи одиниць
дозволені: байти, кілобайти, гігабайти, мегабайти, гігабайти, терабайти або ексабайти. Кожен
може бути скорочено лише до першої літери; відсутність одиниць взагалі означає "байти". The
значення за замовчуванням — «90%» і «95%».

Ця команда перевіряє наведені нижче речі, щоб визначити всі різні фізичні диски
використовується Postgres.

каталог_даних - Диск, на якому знаходиться основний каталог даних.

журнал каталог - Диск, на якому знаходяться файли журналу.

WAL файл каталог - Диск, на якому ведуться журнали попередження запису (наприклад, pg_xlog із символічним посиланням)

табличні простори - Кожен табличний простір, що знаходиться на окремому диску.

Вихідні дані показують загальний розмір використовуваного та доступного на кожному диску, а також файл
відсоток, упорядкований за відсотком від найвищого до найменшого використаного. Кожен пункт вище відображається у файлі
система: вони можуть бути включені або виключені. Додаткову інформацію дивіться в розділі «ОСНОВНА ФІЛЬТРАЦІЯ».
подробиці

Приклад 1. Переконайтеся, що жодна файлова система не перевищує 90% для бази даних на порту 5432.

check_postgres_disk_space --port=5432 --warning='90%' --critical='90%'

Приклад 2. Перевірте, чи всі файлові системи, починаючи з /dev/sda, мають розмір менше 10 ГБ і
11 ГБ (попередження та критично)

check_postgres_disk_space --port=5432 --warning='10 ГБ' --critical='11 ГБ' --include="~^/dev/sda"

Приклад 4. Переконайтеся, що жодна файлова система не перевищує 50% та має понад 15 ГБ

check_postgres_disk_space --critical='50% і 15 ГБ'

Приклад 5. Видайте попередження, якщо будь-яка файлова система заповнена понад 70%. or має більше 1 т

check_postgres_disk_space --warning='1T або 75'

Для виводу MRTG повертає розмір файлової системи в байтах у першому рядку та
ім'я файлової системи в четвертому рядку.

fsm_pages
("symlink: check_postgres_fsm_pages") Перевіряє, наскільки близький кластер до Postgres
max_fsm_pages налаштування. Ця дія працюватиме лише для баз даних 8.2 або вище, і це
потрібен модуль contrib pg_freespacemap бути встановлені. The --увага та --критично
варіанти мають бути виражені у відсотках. Кількість використаних сторінок у карті вільного простору
визначається шляхом перегляду у поданні pg_freespacemap_relations та виконання формули
на основі формули, що використовується для виведення слотів вільного простору на карті сторінок у вакуумному дослівному
команда. Значення за замовчуванням: 85% за попередження і 95% для критичних.

Приклад 1: попередити, коли наш кластер використає 76% вільного місця для сторінок,
з pg_freespacemap, встановленим у базі даних Robert

check_postgres_fsm_pages --dbname=robert --warning="76%"

Хоча вам потрібно передати ім’я бази даних, де встановлено pg_freespacemap, ви
Цю перевірку потрібно виконати лише один раз на кластер. Крім того, необхідно перевірити цю інформацію
отримати спеціальні блокування на карті вільного простору, тому не рекомендується запускати це
перевіряти з короткими інтервалами.

Для виводу MRTG повертає відсоток карти вільного простору в першому рядку та число
сторінок, які зараз використовуються в другому рядку.

fsm_relations
("symlink: check_postgres_fsm_relations") Перевіряє, наскільки близький кластер до Postgres
max_fsm_relations налаштування. Ця дія працюватиме лише для баз даних 8.2 або вище
для цього потрібен модуль contrib pg_freespacemap бути встановлені. The --увага та --критично
Варіанти мають бути виражені у відсотках. Кількість використаних відносин у вільному-
space-map визначається переглядом у поданні pg_freespacemap_relations. За замовчуванням
значення є 85% за попередження і 95% для критичних.

Приклад 1: попередити, коли наш кластер використає 80% відношень вільного простору,
з pg_freespacemap, встановленим у базі даних dylan

check_postgres_fsm_relations --dbname=dylan --warning="75%"

Хоча вам потрібно передати ім’я бази даних, де встановлено pg_freespacemap, ви
Цю перевірку потрібно виконати лише один раз на кластер. Крім того, необхідно перевірити цю інформацію
отримати спеціальні блокування на карті вільного простору, тому не рекомендується запускати це
перевіряти з короткими інтервалами.

Для виводу MRTG повертає відсоток карти вільного простору в першому рядку, кількість
відносини, які зараз використовуються на другому рядку.

hitratio
("symlink: check_postgres_hitratio") Перевіряє коефіцієнт звернень усіх баз даних та скаржиться
коли вони занадто низькі. Немає необхідності виконувати цю команду більше одного разу на базу даних
кластер. Бази даних можна фільтрувати за допомогою --включати та --виключити варіанти. Див
Розділ «ОСНОВНА ФІЛЬТРАЦІЯ» для більш детальної інформації. Їх також може відфільтрувати власник
бази даних з --includeuser та --excludeuser варіанти. Дивіться розділ "ФІЛЬТРІВАННЯ ІМЕН КОРИСТУВАЧА"
розділ, щоб дізнатися більше.

Попередження та критичні параметри слід вказати у відсотках. Нема
значення за замовчуванням для цієї дії: необхідно вказати попередження та критичний. Значення попередження
не може перевищувати критичне значення. Вихід повертає всі бази даних, відсортовані за
hitratio, найменший спочатку.

Приклад: попереджати, якщо будь-яка база даних на хост-прапорці менша за 90% у співвідношенні, і критично якщо
менше 80%.

check_postgres_hitratio --host=flagg --warning='90%' --critical='80%'

Для виводу MRTG повертає відсоток бази даних з найменшим коефіцієнтом звернення
перший рядок, а назва бази даних у четвертому рядку.

гарячий режим очікування
("symlink: check_hot_standby_delay") Перевіряє затримку потокової реплікації, обчислюючи
дельта між поточною позицією xlog головного сервера та місцем відтворення a
підключений до нього раб. Підпорядкований сервер повинен перебувати в режимі гарячого очікування (наприклад, тільки для читання),
тому мінімальна версія для використання цієї дії – Postgres 9.0. The --увага та
--критично Параметри — це дельта між розташуваннями xlog. Оскільки ці значення є байтовими
зміщення в WAL вони повинні відповідати очікуваному об’єму транзакцій вашої програми
щоб запобігти хибнопозитивним або негативним результатам.

Перші параметри «--dbname», «--host» і «--port» тощо вважаються головними; в
другий належить рабу.

Значення байтів повинні ґрунтуватися на обсязі транзакцій, необхідних для потокової передачі
відключення реплікації від провідника через занадто велике відставання, визначене Postgres
змінна конфігурації wal_keep_segments. Для одиниць часу дійсними одиницями є "секунди",
"хвилини", "години" або "дні". Кожне може бути записане в однині або скорочено до просто
перша літера. Якщо вказати обидва, у формі 'bytes та час', повинні бути обидві умови
правда для досягнення порогу.

Ви повинні надати інформацію про те, як отримати доступ до баз даних, розділивши їх комами
список до параметрів --dbhost і --dbport, наприклад "--dbport=5432,5543". Якщо не дано,
дія не вдається.

Приклад 1. Попередження, що база даних з локальною реплікою на порту 5433 відстає під час будь-якого відтворення xlog
взагалі

check_hot_standby_delay --dbport=5432,5433 --warning='1'

Приклад 2: Укажіть критичне значення, якщо остання транзакція, отримана replica1, перевищує 10
хвилин тому

check_hot_standby_delay --dbhost=master,replica1 --critical='10 хв'

Приклад 3: Дозвольте репліці1 бути на 1 сегмент WAL позаду, якщо ведучий на мить бачить
більше активності, ніж може обробити з’єднання потокової реплікації, або на 10 хвилин позаду,
якщо господар бачить дуже мало активності і не обробляє жодних транзакцій, але ні
обидва, що вказує на тривалі проблеми з підключенням реплікації.

check_hot_standby_delay --dbhost=master,replica1 --warning='1048576 і 2 хв' --critical='16777216 і 10 хв'

розмір_індексу
розмір_таблиці
розмір_відношення
(символьні посилання: "check_postgres_index_size", "check_postgres_table_size" та
"check_postgres_relation_size") Дії розмір_таблиці та розмір_індексу просто
варіації розмір_відношення дії, яка перевіряє зв’язок, який також виріс
великий. Відносини (іншими словами, таблиці та індекси) можна фільтрувати за допомогою --включати
та --виключити варіанти. Додаткову інформацію дивіться у розділі «ОСНОВНА ФІЛЬТРАЦІЯ». Відносини можуть
також фільтруватися користувачем, якому вони належать, за допомогою --includeuser та --excludeuser
варіанти. Додаткову інформацію див. у розділі «ФІЛЬТР ІМЕНІ КОРИСТУВАЧІВ».

Значення для --увага та --критично параметри є розмірами файлів і можуть мати одиниці
байти, кілобайти, мегабайти, гігабайти, терабайти або ексабайти. Кожен може бути скороченим
до першої літери. Якщо одиниці вимірювання не вказано, приймаються байти. За замовчуванням немає
значення: повинні бути вказані як попередження, так і критичний параметр. Текст повернення показує
розмір найбільшого знайденого відношення.

Якщо --showperf опція увімкнена, всі буде подано співвідношення з їх розмірами.
Щоб запобігти цьому, рекомендується встановити параметр -- perflimit варіант, який спричинить
запит на виконання "ОБМЕЖЕННЯ DESC ORDER BY size (perflimit)".

Приклад 1: Дайте критичне значення, якщо будь-яка таблиця перевищує 600 МБ на хості Burrick.

check_postgres_table_size --critical='600 МБ' --warning='600 МБ' --host=burrick

Приклад 2: попереджати, якщо розмір таблиці продуктів перевищує 4 ГБ, і дає критичне значення на рівні 4.5 ГБ.

check_postgres_table_size --host=burrick --warning='4 ГБ' --critical='4.5 ГБ' --include=продукти

Приклад 3: Попереджати, якщо будь-який індекс, який не належить postgres, перевищує 500 МБ.

check_postgres_index_size --port=5432 --excludeuser=postgres -w 500MB -c 600MB

Для виводу MRTG повертає розмір у байтах найбільшого відношення та ім’я
база даних і зв'язок як четвертий рядок.

останній_аналіз
останній вакуум
last_autoanalyze
останній_автовакуум
(символьні посилання: "check_postgres_last_analyze", "check_postgres_last_vacuum",
"check_postgres_last_autoanalyze" і "check_postgres_last_autovacuum") Перевіряє, як довго
це було з моменту останнього запуску вакуумування (або аналізу) для кожної таблиці в одній або кількох базах даних.
Використання цих дій вимагає, щоб цільова база даних була версії 8.3 або вище
версія 8.2 і змінна конфігурації stats_row_level було ввімкнено. Таблиці
можна відфільтрувати за допомогою --включати та --виключити варіанти. Дивіться розділ «ОСНОВНА ФІЛЬТРАЦІЯ»
розділ для більш детальної інформації. Таблиці також можуть бути відфільтровані їх власником за допомогою
--includeuser та --excludeuser варіанти. Додаткову інформацію див. у розділі «ФІЛЬТР ІМЕНІ КОРИСТУВАЧІВ».
подробиці

Одиниці для --увага та --критично вказуються як часи. Допустимі одиниці - секунди,
хвилини, години та дні; все можна скоротити до першої літери. Якщо одиниць немає
задані, припускаються "секунди". Значеннями за замовчуванням є «1 день» і «2 дні». Будь ласка, запиши
що є випадки, коли це поле не заповнюється автоматично. Якщо впевнений
таблиці створюють проблеми, переконайтеся, що в них є мертві рядки, які потрібно очистити, або просто
виключити їх з тесту.

Схема з назвою 'information_schema' виключена з цього тесту, оскільки в ній є єдині таблиці
містить невеликі і не змінюються.

Зауважте, що не «автоматичні» версії також перевірятимуть автоматичні версії. В інших
словами, використання last_vacuum повідомить про останній вакуум, чи був це звичайний вакуум,
або запущений демоном autovacuum.

Приклад 1: Попереджайте, якщо будь-який стіл не був пропилососитий протягом 3 днів, і дайте критичний
тиждень, для господаря полину

check_postgres_last_vacuum --host=wormwood --warning='3d' --critical='7d'

Приклад 2: Те саме, що і вище, але пропускати таблиці, що належать користувачам "eve" або "mallory"

check_postgres_last_vacuum --host=wormwood --warning='3d' --critical='7d' --excludeusers=eve,mallory

Для виводу MRTG повертає (у першому рядку) НАЙМЕНШУ кількість часу в секундах з моменту a
стіл востаннє пропилососили або аналізували. Четвертий рядок повертає назву бази даних і
назва таблиці.

слухач
("symlink: check_postgres_listener") Підтвердьте, що хтось слухає один або кілька
певні рядки (за допомогою системи LISTEN/NOTIFY), дивлячись на таблицю pg_listener.
Потрібне лише одне з попереджувальних чи критичних. Формат являє собою простий рядок, що представляє
Ціль LISTEN або символ тильди, за яким слідує рядок для перевірки регулярного виразу.
Зауважте, що ця перевірка не працюватиме у версіях Postgres 9.0 або вище.

Приклад 1: попередити, якщо ніхто не слухає рядок bucardo_mcp_ping на портах
5555 і 5556

check_postgres_listener --port=5555,5556 --warning=bucardo_mcp_ping

Приклад 2: Дайте критичне значення, якщо немає активних запитів LISTEN, які відповідають 'grimm'
база даних oskar

check_postgres_listener --db oskar --critical=~grimm

Для виходу MRTG повертає 1 або 0 на першому, що вказує на успіх або невдачу. Ім'я
повідомлення має бути надано через --mrtg варіант.

замки
("symlink: check_postgres_locks") Перевірте загальну кількість блокувань на одному або кількох
бази даних. Немає необхідності виконувати це більше одного разу на кластер бази даних. Бази даних можуть
фільтрувати за допомогою --включати та --виключити варіанти. Дивіться розділ «ОСНОВНА ФІЛЬТРАЦІЯ».
для більш докладної інформації.

Команда --увага та --критично опції можна задати як прості числа, які представляють
загальна кількість замків, або їх можна розбити за типом замка. Допустимі назви замків
є "total", "waiting" або назва типу блокування, який використовується Postgres. Ці імена є
не чутливий до регістру і не потребує частини «замок» на кінці, тому ексклюзивний буде відповідати
«Ексклюзивний замок». Формат – ім’я=число, різні елементи розділяються двокрапками або
крапка з комою (або будь-який інший символ).

Приклад 1: попереджати, якщо кількість блокувань становить 100 або більше, і критично, якщо 200 або більше, на
господар Гаррет

check_postgres_locks --host=garrett --warning=100 --critical=200

Приклад 2: на хості artemus попередити, якщо існує 200 або більше блокувань, і дати критичний, якщо
існує понад 250 загальних блокувань, або якщо існує понад 20 ексклюзивних замків, або якщо більше 5 з’єднань
чекають на замок.

check_postgres_locks --host=artemus --warning=200 --critical="total=250:waiting=5:exclusive=20"

Для виводу MRTG повертає кількість блокувань у першому рядку та назву
база даних на четвертому рядку.

файл журналу
("symlink: check_postgres_logfile") Переконує, що файл журналу знаходиться в очікуваному місці
і реєструється. Ця дія дає команду, яка викликає помилку для кожного
базу даних, яку вона перевіряє, і гарантує, що повідомлення відображатиметься в журналах. Він сканує
різні параметри log_* всередині Postgres, щоб зрозуміти, де мають бути журнали. Якщо ви
використовує syslog, він виконує грубе (але не надійне) сканування /etc/syslog.conf.
Крім того, ви можете вказати ім’я файлу журналу з файлом --файл журналу варіант. Це
особливо корисно, якщо журнали мають спеціальну схему ротації, керовану зовнішньою програмою.
Команда --файл журналу Опція підтримує такі escape-символи: "%Y %m %d %H", що
представляють поточний рік, місяць, число та годину відповідно. Помилка завжди
повідомляється як критичне, якщо параметр попередження не був переданий як ненульове значення.
Крім цього конкретного використання, мають бути параметри "--warning" та "--critical". НЕ be
використаний

Приклад 1: на порту 5432 переконайтеся, що файл журналу записується у файл
/home/greg/pg8.2.log

check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log

Приклад 2: Те саме, що й вище, але попередження, а не критичне значення

check_postgres_logfile --port=5432 --logfile=/home/greg/pg8.2.log -w 1

Для виходу MRTG повертає 1 або 0 у першому рядку, що вказує на успіх або невдачу. в
у випадку збою, четвертий рядок надасть більш детальну інформацію про виниклу помилку.

нова_версія_bc
("symlink: check_postgres_new_version_bc") Перевіряє, чи є новіша версія Bucardo
програма доступна. Поточна версія отримується за допомогою "bucardo_ctl --version".
Якщо доступне серйозне оновлення, повертається попередження. Якщо оновлення версії є
доступний, повертається критичний. (Букардо — пан рабу, господар — господарю
система реплікації для Postgres: див http://bucardo.org для отримання додаткової інформації). Дивись також
інформацію про параметр "--get_method".

new_version_box
("symlink: check_postgres_new_version_box") Перевіряє, чи є новіша версія boxinfo
програма доступна. Поточну версію можна отримати, запустивши "boxinfo.pl --version".
Якщо доступне серйозне оновлення, повертається попередження. Якщо оновлення версії є
доступний, повертається критичний. (boxinfo - це програма для захоплення важливих
інформації із сервера та введення її у формат HTML: див
http://bucardo.org/wiki/boxinfo для отримання додаткової інформації). Дивіться також інформацію про
Параметр "--get_method".

нова_версія_cp
("symlink: check_postgres_new_version_cp") Перевіряє, чи є новіша версія цієї програми
(check_postgres) доступний, захопивши версію з невеликого текстового файлу на головній
сторінку домашньої сторінки проекту. Повертає попередження, якщо повернута версія ні
відповідати тому, яким ви працюєте. Рекомендований інтервал перевірки – один раз на день. Дивіться також
інформацію про параметр "--get_method".

нова_версія_стор
("symlink: check_postgres_new_version_pg") Перевіряє, чи існує новіша версія Postgres
для кожної підключеної бази даних. Зауважте, що це лише перевіряє наявність перегляду, наприклад, вихід із
8.3.6-8.3.7. Ревізії завжди 100% бінарно сумісні і не передбачають дамп і
відновити для оновлення. Здійснюються зміни для усунення помилок, тому оновлюйте якомога швидше
завжди рекомендується. Повертає попередження, якщо у вас немає останньої версії. це є
рекомендується проводити цю перевірку принаймні раз на день. Дивіться також інформацію про
Параметр "--get_method".

нова_версія_tnm
("symlink: check_postgres_new_version_tnm") Перевіряє, чи є новіша версія tail_n_mail
програма доступна. Поточна версія отримується за допомогою "tail_n_mail --version".
Якщо доступне серйозне оновлення, повертається попередження. Якщо оновлення версії є
доступний, повертається критичний. (tail_n_mail – це інструмент моніторингу журналів, який можна надсилати
пошти, коли цікаві події з’являються у ваших журналах Postgres. Побачити:
http://bucardo.org/wiki/Tail_n_mail для отримання додаткової інформації). Дивіться також інформацію на
параметр "--get_method".

pgb_pool_cl_active
pgb_pool_cl_waiting
pgb_pool_sv_active
pgb_pool_sv_idle
pgb_pool_sv_used
pgb_pool_sv_tested
pgb_pool_sv_login
pgb_pool_maxwait
(символьні посилання: "check_postgres_pgb_pool_cl_active", "check_postgres_pgb_pool_cl_waiting",
"check_postgres_pgb_pool_sv_active", "check_postgres_pgb_pool_sv_idle",
"check_postgres_pgb_pool_sv_used", "check_postgres_pgb_pool_sv_tested",
"check_postgres_pgb_pool_sv_login" і "check_postgres_pgb_pool_maxwait")

Вивчає статистику пулу pgbouncer. Кожен пул має набір "клієнтських" з'єднань,
посилаючись на підключення від зовнішніх клієнтів, і на "серверні" з'єднання, посилаючись на
підключення до самого PostgreSQL. Пов'язані дії check_postgres мають префікс "cl_"
і "sv_" відповідно. Активні клієнтські з’єднання – це ті з’єднання, які зараз пов’язані
з активним підключенням до сервера. Клієнтські з’єднання також можуть бути «очікувальними», тобто вони
ще не призначено підключення до сервера. З'єднання з сервером "активні" (пов'язані
до клієнта), «неактивний» (очікується підключення клієнта для підключення), «використовується» (просто
від'єднано від клієнта і ще не повернуто до неактивного пулу), "перевірено" (на даний момент є
перевірено) та «вхід» (у процесі входу). Значення maxwait показує, як довго в
секунд очікування найстарішого клієнтського підключення.

pgbouncer_backends
("symlink: check_postgres_pgbouncer_backends") Перевіряє поточну кількість з'єднань
для однієї або кількох баз даних за допомогою pgbouncer і за бажанням порівнює його з максимальним
дозволено, що визначається змінною конфігурації pgbouncer max_client_conn,
--увага та --критично варіанти можуть мати одну з трьох форм. По-перше, просте число може
бути дано, що представляє кількість з’єднань, на яких буде видано сповіщення.
Цей вибір не використовує max_connections налаштування. По-друге, відсоток доступних
можна надати зв'язки. По-третє, можна дати від’ємне число, яке представляє
кількість підключень залишилося до max_connections досягнуто. Значення за замовчуванням для
--увага та --критично це "90%" і "95%". Ви також можете фільтрувати бази даних за допомогою
--включати та --виключити варіанти. Додаткову інформацію дивіться у розділі «ОСНОВНА ФІЛЬТРАЦІЯ».

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

Приклад 1. Видавати попередження, коли кількість підключень на хості quirm досягає 120, і
критично, якщо досягає 150.

check_postgres_pgbouncer_backends --host=quirm --warning=120 --critical=150 -p 6432 -u pgbouncer

Приклад 2. Дайте критичне значення, коли ми досягнемо 75% наших параметрів max_connections на хостах
lancre або lancre2.

check_postgres_pgbouncer_backends --warning='75%' --critical='75%' --host=lancre,lancre2 -p 6432 -u pgbouncer

Приклад 3. Видавати попередження, коли на хості залишилося лише 10 слотів підключення
плазміда, а критична, коли у нас залишилося лише 5.

check_postgres_pgbouncer_backends --warning=-10 --critical=-5 --host=plasmid -p 6432 -u pgbouncer

Для виходу MRTG кількість підключень повідомляється в першому і четвертому рядку
рядок дає назву бази даних плюс поточний max_client_conn. Якщо більше одного
запит на базу даних, виводиться те, що має найбільшу кількість з’єднань.

pgbouncer_checksum
("symlink: check_postgres_pgbouncer_checksum") Перевіряє, чи всі налаштування pgBouncer
так само, як і востаннє, коли ви перевіряли. Це робиться шляхом створення контрольної суми відсортованого списку
встановлення імен та їх значень. Зауважте, що вам не слід вказувати ім’я бази даних, це
автоматично за замовчуванням буде pgbouncer. Або --увага або --критично варіант
слід дати, але не обидва. Значенням кожного з них є контрольна сума, що складається з 32 символів
шістнадцяткове значення. Ви можете запустити спеціальну опцію "--critical=0", щоб дізнатися
існуюча контрольна сума.

Для цієї дії потрібен модуль Digest::MD5.

Приклад 1: Знайдіть початкову контрольну суму для конфігурації pgbouncer на порту 6432 за допомогою
користувач за замовчуванням (зазвичай postgres)

check_postgres_pgbouncer_checksum --port=6432 --critical=0

Приклад 2. Переконайтеся, що налаштування не змінено, і попередьте, якщо так, використовуючи контрольну суму від
вище.

check_postgres_pgbouncer_checksum --port=6432 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Для виводу MRTG повертає 1 або 0, що вказує на успішне збіг контрольної суми.
Контрольну суму необхідно надати як аргумент «--mrtg». Четвертий рядок завжди дає
поточна контрольна сума.

pgagent_jobs
("symlink: check_postgres_pgagent_jobs") Перевіряє, чи всі завдання pgAgent, які мають
виконані за попередній проміжок часу, були успішними. Це робиться шляхом перевірки на
будь-які кроки, які мають відмінний від нуля результат.

Як час можна вказати "--warning" або "--critical", або обидва, і завдання будуть
перевірено на наявність збоїв протягом зазначених проміжків часу до поточного часу. Дійсний
одиниці: секунди, хвилини, години та дні; все можна скоротити до першої літери.
Якщо одиниці вимірювання не вказані, припускаються «секунди».

Приклад 1: Дайте критичне значення, коли будь-які завдання, виконані за останній день, були невдалими.

check_postgres_pgagent_jobs --critical=1d

Приклад 2: Повідомте попередження, коли будь-які завдання, виконані за останній тиждень, були невдалими.

check_postgres_pgagent_jobs --warning=7d

Приклад 3: Надайте критичне значення для завдань, які не були виконані за останні 2 години, і попередження для
завдання, які були невдалими за останні 4 години:

check_postgres_pgagent_jobs --critical=2 год --warning=4 год

Готовий_txns
("symlink: check_postgres_prepared_txns") Перевірте вік будь-якого наявного підготовленого
операції. Зауважте, що більшість людей НЕ використовуватимуть підготовлені транзакції, оскільки вони є частиною
складається з двох частин і складний у підтримці. Їх також не слід плутати з
підготовлені ЗАЯВЛЕННЯ, про що думають більшість людей, коли чують, що готуються. The
Значення за замовчуванням для попередження становить 1 секунду, щоб виявити будь-яке використання підготовлених транзакцій, які
ймовірно, це помилка в більшості систем. Попередження та критичне значення – це кількість секунд a
підготовлена ​​транзакція була відкрита до отримання сповіщення.

Приклад 1. Дайте попередження про виявлення будь-яких підготовлених транзакцій:

check_postgres_prepared_txns -w 0

Приклад 2: Укажіть критичне значення, якщо будь-яка підготовлена ​​транзакція була відкрита більше 10
секунд, але дозвольте до 360 секунд для бази даних 'shrike':

check_postgres_prepared_txns --critical=10 --exclude=shrike
check_postgres_prepared_txns --critical=360 --include=shrike

Для виводу MRTG повертає кількість секунд, протягом яких найстаріша транзакція була відкрита як
перший рядок і з якої бази даних отримано як останній рядок.

query_runtime
("symlink: check_postgres_query_runtime") Перевіряє, скільки часу потрібно для виконання конкретного запиту,
шляхом виконання "ПОЯСНЕННЯ АНАЛІЗУ" щодо нього. The --увага та --критично варіанти
максимальна кількість часу, яку має зайняти запит. Допустимі одиниці: секунди, хвилини та години;
будь-який можна скоротити до першої літери. Якщо одиниці вимірювання не вказані, припускаються «секунди».
Необхідно надати як попередження, так і критичний варіант. Ім'я представлення або функції
для запуску необхідно передати в --ім'я запиту варіант. Він повинен складатися з одного слова
(або schema.word) з необов'язковими дужками в кінці.

Приклад 1: Дайте критичне значення, якщо функція з назвою «тест швидкості» не запускається протягом 10 секунд або
менше.

check_postgres_query_runtime --queryname='speedtest()' --critical=10 --warning=10

Для виводу MRTG повідомляє час у секундах для завершення запиту в першому рядку.
У четвертому рядку перелічено базу даних.

час_запиту
("symlink: check_postgres_query_time") Перевіряє тривалість запущених запитів на одному або кількох
бази даних. Немає необхідності виконувати це більше одного разу в одному кластері бази даних. Примітка
що це вже виключає запити, які "неактивні в транзакції". Бази даних можуть бути
відфільтровано за допомогою --включати та --виключити варіанти. Дивіться розділ «ОСНОВНА ФІЛЬТРАЦІЯ».
для більш детальної інформації. Ви також можете відфільтрувати користувача, який виконує запит, за допомогою --includeuser
та --excludeuser варіанти. Додаткову інформацію див. у розділі «ФІЛЬТР ІМЕНІ КОРИСТУВАЧІВ».

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

Для цієї дії потрібен Postgres 8.1 або новішої версії.

Приклад 1: попередження, якщо запит виконується більше 3 хвилин, і а
критично, якщо більше 5 хвилин.

check_postgres_query_time --port=5432 --warning='3 хвилини' --critical='5 хвилин'

Приклад 2: Використовуючи значення за замовчуванням (2 та 5 хвилин), перевірте всі бази даних, крім тих
починаючи з "шаблон".

check_postgres_query_time --port=5432 --exclude=~^шаблон

Приклад 3. Попередження, якщо запит користувача 'don' виконується більше 20 секунд

check_postgres_query_time --port=5432 --includeuser=don --warning=20s

Для виводу MRTG повертає довжину в секундах найдовшого запиту в першому
лінія. У четвертому рядку вказується назва бази даних.

replicate_row
("symlink: check_postgres_replicate_row") Перевіряє, чи працює реплікація "головний-підпорядкований"
одному або кільком рабам.

Перші параметри «--dbname», «--host» і «--port» тощо вважаються головними;
наступне використання — раби. Значення або --увага та --критично варіанти є
одиниці часу, і має бути вказано принаймні один (без умовчання). Допустимі одиниці: "секунди",
"хвилини", "години" або "дні". Кожне може бути записане в однині або скорочено до просто
перша літера. Якщо одиниці вимірювання не вказано, вважається, що це секунди.

Ця перевірка оновлює один рядок на головній сторінці, а потім вимірює, скільки часу це займе
застосовується до рабів. Для цього вам потрібно вибрати таблицю, яка реплікується
знайдіть рядок, який можна змінити і який не буде змінено жодним іншим процесом. А
конкретний стовпець цього рядка буде змінено з одного значення на інше. Все це годують
до параметра "repinfo" і має містити такі параметри, розділені комами:
ім'я таблиці, первинний ключ, ідентифікатор ключа, стовпець, перше значення, друге значення.

Приклад 1: Slony реплікує таблицю з назвою 'orders' з хосту 'alpha' на хост 'beta',
у базі даних «продажі». Первинний ключ таблиці називається id, і ми збираємося
перевірте рядок з ідентифікатором 3 (який є історичним і ніколи не змінювався). Є колона
під назвою 'salesrep', яке ми збираємося перемикати зі значення 'slon' на 'nols', щоб перевірити
реплікація. Ми хочемо надіслати попередження, якщо реплікація не відбудеться протягом 10
секунд.

check_postgres_replicate_row --host=alpha --dbname=sales --host=beta
--dbname=sales --warning=10 --repinfo=orders,id,3,salesrep,slon,nols

Приклад 2: Bucardo реплікує таблицю з назвою 'receipt' з хосту 'green' на хости
"червоний", "синій" і "жовтий". База даних для обох сторін є загальнодоступною. Підпорядковані бази даних
працюють на порту 5455. Первинний ключ називається "receipt_id", рядок, який ми хочемо використовувати
має значення 9, а стовпець, який ми хочемо змінити для тесту, називається «зоною». Добре
перемикатися між «північ» і «південний» для значення цього стовпця та кидати критичне значення, якщо
зміна не на всіх трьох підлеглих протягом 5 секунд.

check_postgres_replicate_row --host=зелений --port=5455 --host=червоний, синій, жовтий
--critical=5 --repinfo=квитанція,ідентифікатор_квитанції,9,зона,північ,південь

Для виводу MRTG повертає в першому рядку час у секундах, на який йде реплікація
закінчити. Максимальний час встановлюється на 4 хвилини 30 секунд: якщо повторення не було
місце за цей тривалий час видається помилка.

та сама_схема
("symlink: check_postgres_same_schema") Перевіряє, що дві або більше баз даних ідентичні
що стосується їх схеми (але не даних всередині). Це особливо зручно для виготовлення
переконайтеся, що ваші підпорядковані пристрої не були модифіковані та не пошкоджені будь-яким чином під час використання master to slave
реплікація. На відміну від більшості інших дій, це не має попередження чи критичних критеріїв -
бази даних або синхронізовані, або ні. Якщо вони відрізняються, докладний список
представлені відмінності.

Ви можете виключити або відфільтрувати певні відмінності. Спосіб зробити це – додати
рядків до параметра "--filter". Щоб виключити тип об'єкта, використовуйте "noname", де "name"
є типом об'єкта, наприклад, "noschema". Щоб виключити об’єкти певного типу за допомогою a
регулярний вираз проти їх імені, використовуйте "noname=regex". Перегляньте приклади нижче для а
краще розуміння.

Типи об’єктів, які можна відфільтрувати, включають:

користувач
схема
таблиця
вид
індекс
послідовність
обмеження
викликати
функція

Параметр фільтра "noposition" запобігає перевірці положення стовпців у межах a
таблиці.

Опція фільтра "nofuncbody" запобігає порівнянню тіл усіх функцій.

Параметр фільтра "noperm" запобігає порівнянню дозволів об'єкта.

Щоб надати другу базу даних, просто додайте відмінності до першої за допомогою виклику до
відповідний аргумент підключення. Наприклад, для порівняння баз даних на хостах alpha і
браво, використовуйте "--dbhost=alpha,bravo". Також дивіться приклади нижче.

Якщо вказано лише один хост, передбачається, що ми робимо звіт "на основі часу". The
Під час першого запуску моментальний знімок всіх елементів бази даних зберігається в локальному файлі
файл. Коли ви запустите його знову, цей знімок зчитується і стає «базою даних №2» і є
порівняно з поточною базою даних.

Щоб замінити старий збережений файл новою версією, використовуйте аргумент --replace.

Щоб увімкнути знімки в різні моменти часу, ви можете використовувати аргумент «--suffix».
імена файлів, унікальні для кожного запуску. Дивіться приклади нижче.

Приклад 1. Переконайтеся, що дві бази даних на хостах star і line однакові:

check_postgres_same_schema --dbhost=зірка,рядок

Приклад 2: Те саме, що й раніше, але виключіть будь-які тригери з "slony" в їх назві

check_postgres_same_schema --dbhost=зірка, рядок --filter="notrigger=slony"

Приклад 3: Те саме, що й раніше, але також виключаємо всі індекси

check_postgres_same_schema --dbhost=star,line --filter="notrigger=slony noindexes"

Приклад 4: Перевірте відмінності для бази даних "battlestar" на різних портах

check_postgres_same_schema --dbname=battlestar --dbport=5432,5544

Приклад 5. Створіть щоденний і щотижневий файл знімків

check_postgres_same_schema --dbname=cylon --suffix=daily
check_postgres_same_schema --dbname=cylon --suffix=щотижня

Приклад 6. Виконайте історичне порівняння, а потім замініть файл

check_postgres_same_schema --dbname=cylon --suffix=щодня --replace

послідовність
("symlink: check_postgres_sequence") Перевіряє, скільки місця залишилося для всіх послідовностей у
бази даних. Це вимірюється як відсоток від загальних можливих значень, які були використані
для кожної послідовності. The --увага та --критично варіанти мають бути виражені як
відсотки. Значення за замовчуванням: 85% за попередження і 95% для критичних. Ви можете
використовуйте --include та --exclude, щоб контролювати, які послідовності потрібно перевірити. Зауважте, що це
чек враховує незвичайне мінімальна вартість та приріст by цінності, але не хвилює, чи
послідовність налаштована на цикл чи ні.

Вихід для Nagios дає назву послідовності, використаний відсоток і номер
'викликів' залишилося, що вказує, скільки разів ще можна викликати nextval у цій послідовності
до досягнення максимального значення.

Вихід для MRTG повертає найвищий відсоток для всіх послідовностей у першому рядку,
і назву кожної послідовності з цим відсотком у четвертому рядку, розділених символом «|».
(pipe), якщо в цьому відсотку є більше однієї послідовності.

Приклад 1: Попереджайте, якщо якісь послідовності наближаються до 95% заповнення.

check_postgres_sequence --dbport=5432 --warning=95%

Приклад 2. Переконайтеся, що послідовність з назвою "orders_id_seq" заповнена не більше ніж наполовину.

check_postgres_sequence --dbport=5432 --critical=50% --include=orders_id_seq

налаштування_контрольної суми
("symlink: check_postgres_settings_checksum") Перевіряє, чи всі налаштування Postgres
так само, як і востаннє, коли ви перевіряли. Це робиться шляхом створення контрольної суми відсортованого списку
встановлення імен та їх значень. Зауважте, що різні користувачі в одній базі даних можуть мати
різні контрольні суми через використання ALTER USER та через те, що суперкористувачі бачать більше
налаштування ніж звичайні користувачі. Або --увага або --критично варіант повинен бути
дано, але не обидва. Значенням кожного з них є контрольна сума, 32-значне шістнадцяткове число
значення. Ви можете запустити спеціальну опцію «--critical=0», щоб дізнатися існуючу
контрольна сума.

Для цієї дії потрібен модуль Digest::MD5.

Приклад 1. Знайдіть початкову контрольну суму для бази даних на порту 5555, використовуючи користувача за замовчуванням
(зазвичай постгрес)

check_postgres_settings_checksum --port=5555 --critical=0

Приклад 2. Переконайтеся, що налаштування не змінено, і попередьте, якщо так, використовуючи контрольну суму від
вище.

check_postgres_settings_checksum --port=5555 --warning=cd2f3b5e129dc2b4f5c0f6d8d2e64231

Для виводу MRTG повертає 1 або 0, що вказує на успішне збіг контрольної суми.
Контрольну суму необхідно надати як аргумент «--mrtg». Четвертий рядок завжди дає
поточна контрольна сума.

slony_status
("symlink: check_postgres_slony_status") Перевіряє статус кластера Slony за допомогою
дивлячись на результати перегляду sl_status Slony. Це повертається як число
секунди «часу затримки». The --увага та --критично Варіанти мають бути виражені у вигляді разів.
Значення за замовчуванням: 60 seconds за попередження і 300 seconds для критичних.

Необов’язковий аргумент -- схема вказав схему, під якою встановлено Slony. Якщо це
не надано, схема буде визначатися автоматично щоразу, коли запускатиметься ця перевірка.

Приклад 1: Повідомте попередження, якщо Slony відстає більше ніж на 20 секунд

check_postgres_slony_status --попередження 20

Приклад 2: Дайте критичне значення, якщо Slony, встановлений за схемою "_slony", перевищує 10
хвилин із запізненням

check_postgres_slony_status --schema=_slony --critical=600

синхронізація часу
("symlink: check_postgres_timesync") Порівнює місцевий системний час із зазначеним часом
за допомогою однієї або кількох баз даних. The --увага та --критично параметри представляють кількість
секунд між двома системами, перш ніж буде подано сповіщення. Якщо жодне не вказано, то
Використовуються значення за замовчуванням, якими є «2» і «5». Значення попередження не може бути більше ніж
критичне значення. Через неточність цього тесту значення «0» або «1» не є
рекомендується.

Повернений рядок показує різницю в часі, а також записаний час на кожній стороні
поза.

Приклад 1. Перевірте, що баз даних на хостах ankh, morpork і klatch не більше 3
секунди від місцевого часу:

check_postgres_timesync --host=ankh,morpork,klatch --critical=3

Для виводу MRTG повертає один перший рядок кількість секунд різниці між
місцевий час і час бази даних. Четвертий рядок повертає назву бази даних.

txn_idle
("symlink: check_postgres_txn_idle") Перевіряє кількість і тривалість "бездіяльності в
транзакції" до однієї або кількох баз даних. Немає необхідності виконувати це більше одного разу
на одному кластері бази даних. Бази даних можна відфільтрувати за допомогою --включати та
--виключити варіанти. Додаткову інформацію див. у розділі «ОСНОВНА ФІЛЬТРАЦІЯ» нижче.

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

Для цієї дії потрібен Postgres 8.3 або новішої версії.

Приклад 1. Повідомте попередження, якщо будь-яке з’єднання було неактивним у транзакції більше 15
секунди:

check_postgres_txn_idle --port=5432 --warning='15 секунд'

Приклад 2. Повідомте попередження, якщо є 50 або більше транзакцій

check_postgres_txn_idle --port=5432 --warning='+50'

Приклад 3: Дайте критичне значення, якщо 5 або більше з’єднань були неактивними в транзакції більше
ніж 10 секунд:

check_postgres_txn_idle --port=5432 --critical='5 протягом 10 секунд'

Для виводу MRTG повертає час у секундах, протягом якого була найдовша неактивна транзакція
біг. Четвертий рядок повертає назву бази даних та іншу інформацію про
найдовша транзакція.

txn_time
("symlink: check_postgres_txn_time") Перевіряє тривалість відкритих транзакцій на одній або кількох
бази даних. Немає необхідності виконувати цю команду більше одного разу на кластер бази даних.
Бази даних можна відфільтрувати за допомогою --включати та --виключити варіанти. Дивіться розділ «ОСНОВНИЙ
ФІЛЬТРАВАННЯ" для отримання докладнішої інформації. Власника трансакції також можна відфільтрувати за
використання --includeuser та --excludeuser варіанти. Дивіться розділ «ФІЛЬТР ІМЕНІ КОРИСТУВАЧІВ».
для більш докладної інформації.

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

Для цієї дії потрібен Postgres 8.3 або новішої версії.

Приклад 1. Дайте критичне значення, якщо будь-яка транзакція відкрита більше 10 хвилин:

check_postgres_txn_time --port=5432 --critical='10 хвилин'

Приклад 1. Попередження, якщо у користувача "склад" транзакція відкрита протягом 30 секунд

check_postgres_txn_time --port-5432 --warning=30s --includeuser=склад

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

txn_wraparound
("symlink: check_postgres_txn_wraparound") Перевіряє, наскільки близько до транзакції обертається одна
або більше баз даних отримує. The --увага та --критично опції вказують номер
виконаних транзакцій і має бути додатним цілим числом. Якщо жодного з варіантів не надано, то
використовуються значення за замовчуванням 1.3 і 1.4 мільярда. Більше виконувати цю команду не потрібно
ніж один раз на кластер бази даних. Для більш детального обговорення, що це за номер
і що з цим робити, відвідайте сторінку
<http://www.postgresql.org/docs/current/static/routine-vacuuming.html#ВАКУУМ-ДЛЯ-ОБгортання>

Попередження та критичні значення можуть мати підкреслення в номері для розбірливості, як Perl
робить.

Приклад 1. Перевірте значення за замовчуванням для бази даних localhost

check_postgres_txn_wraparound --host=localhost

Приклад 2. Перевірте порт 6000 і дайте критичне значення, коли буде досягнуто 1.7 мільярда транзакцій:

check_postgres_txn_wraparound --port=6000 --critical=1_700_000_000

Для виходу MRTG повертає найбільшу кількість транзакцій для всіх баз даних у першому рядку,
а рядок 4 вказує, яка це база даних.

версія
("symlink: check_postgres_version") Перевіряє наявність потрібної версії Postgres
біг. The --увага та --критично параметри (потрібний лише один) мають бути у форматі
XY or XYZ де X є основним номером версії, Y - це додатковий номер версії, і Z is
перегляд.

Приклад 1. Подайте попередження, якщо база даних на порту 5678 не є версією 8.4.10:

check_postgres_version --port=5678 -w=8.4.10

Приклад 2. Повідомте попередження, якщо будь-яка база даних на хостах valley, grain або sunshine не має версії 8.3:

check_postgres_version -H долина,зерно,сонце --критично=8.3

Для виходу MRTG повідомляє 1 або 0, що вказує на успіх або невдачу в першому рядку. The
четвертий рядок вказує поточну версію. Версія повинна бути надана через "--mrtg"
варіант.

wal_files
("symlink: check_postgres_wal_files") Перевіряє, скільки файлів WAL існує в pg_xlog
каталог, який знайдено поза вашим каталог_даних, іноді як символічне посилання на інше
фізичного диска з міркувань продуктивності. Цю дію необхідно запустити як суперкористувач, щоб
отримати доступ до вмісту pg_xlog каталог. Мінімальна версія для використання цієї дії
Postgres 8.1. The --увага та --критично Параметри – це просто кількість файлів у файлі
pg_xlog каталог. Яке число встановити, буде відрізнятися, але загальна рекомендація — це вказати
число трохи вище, ніж зазвичай, щоб виявити проблеми завчасно.

Зазвичай файли WAL закриваються, а потім використовуються повторно, але тривала відкрита транзакція, або a
несправний archive_command сценарій, може призвести до створення в Postgre занадто великої кількості файлів. зрештою,
це призведе до того, що на диску, на якому вони знаходяться, не вистачить місця, і в цей момент Postgres
закрити.

Приклад 1. Перевірте, чи кількість файлів WAL становить 20 або менше на хості "pluto"

check_postgres_wal_files --host=pluto --critical=20

Для виведення MRTG повідомляє кількість файлів WAL у рядку 1.

rebuild_symlinks
rebuild_symlinks_force
Ця дія не вимагає інших аргументів і не підключається до будь-яких баз даних, а просто
створює символічні посилання в поточному каталозі для кожної дії у формі
check_postgres_. Якщо файл уже існує, він не буде перезаписаний. Якщо
дія rebuild_symlinks_force, тоді символічні посилання будуть перезаписані. Варіант
--symlinks – це коротший спосіб сказати --action=rebuild_symlinks

BASIC ФІЛЬТРУВАННЯ

Варіанти --включати та --виключити можна комбінувати, щоб обмежити те, які речі перевіряються,
залежно від дії. Ім'я бази даних можна відфільтрувати, використовуючи наступне
дії: backends, database_size, locks, query_time, txn_idle і txn_time. Ім'я
відношення можна відфільтрувати, використовуючи такі дії: bloat, index_size,
table_size, relation_size, last_vacuum, last_autovacuum, last_analyze та
last_autoanalyze. Ім’я параметра можна відфільтрувати за допомогою параметра settings_checksum
дії. Ім’я файлової системи можна відфільтрувати за допомогою дії disk_space.

Якщо вказано лише опцію включення, перевірятимуться ТІЛЬКИ ті ​​записи, які відповідають.
Однак, якщо вказано як виключення, так і включення, спочатку виконується виключення, а потім включення
після, щоб відновити речі, які, можливо, були виключені. Обидва --включати та --виключити може
надаватися кілька разів і/або у вигляді списків, розділених комами. Лідируюча тильда буде відповідати
наступне слово як регулярний вираз.

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

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

Приклади:

Перевіряє лише елементи з назвою pg_class:

--include=pg_class

Перевіряє лише елементи, що містять літери 'pg_':

--include=~pg_

Перевіряйте лише елементи, які починаються на "pg_":

--include=~^pg_

Виключіть елемент під назвою «тест»:

--exclude=тест

Виключити всі елементи, що містять літери 'test:

--exclude=~тест

Виключити всі елементи зі схеми 'pg_catalog':

--exclude='pg_catalog.'

Виключити всі елементи, що містять літери «ace», але дозволити елемент «faceoff»:

--exclude=~ace --include=faceoff

Виключити всі елементи, які починаються з літер 'pg_', які містять літери 'slon' або
які називаються 'sql_settings' або 'green'. Особливо перевіряйте елементи з літерами
'prod' в їхніх назвах і завжди перевіряйте елемент з назвою 'pg_relname':

--exclude=~^pg_,~slon,sql_settings --exclude=green --include=~prod,pg_relname

USER ІМ'Я ФІЛЬТРУВАННЯ

Варіанти --includeuser та --excludeuser можна використовувати для деяких дій лише для перевірки
об'єкти бази даних, що належать (або не належать) одному чи кільком користувачам. An --includeuser варіант
завжди перевершує --excludeuser варіант. Кожен варіант можна дати кілька разів
кількох користувачів, або ви можете надати список, розділений комами. Дії, які зараз використовуються
ці варіанти:

розмір_бази
останній_аналіз
last_autoanalyze
останній вакуум
останній_автовакуум
час_запиту
розмір_відношення
txn_time

Приклади:

Перевіряйте лише елементи, що належать користувачу на ім’я greg:

--includeuser=greg

Перевіряйте лише предмети, які належать Watson або Crick:

--includeuser=watson,crick

Перевіряйте лише предмети, які належать Crick, Franklin, Watson або Wilkins:

--includeuser=watson --includeuser=franklin --includeuser=crick,wilkins

Перевірте всі елементи, крім тих, що належать користувачу scott:

--excludeuser=scott

TEST РЕЖИМ

Щоб допомогти у налаштуваннях, цю програму можна запустити в «тестовому режимі», вказавши параметр
--тест варіант. Це виконає деякі основні тести, щоб переконатися, що бази даних можуть бути
зв’язалися, і що певні передумови для кожної дії виконуються, наприклад, чи є користувач
суперкористувача, якщо версія Postgres достатньо нова, і якщо stats_row_level увімкнено.

Використовуйте check_postgres_database_sizep онлайн за допомогою служб onworks.net