Чи може хтось пояснити "випадки використання" для графіків munin за замовчуванням?


9

Встановлюючи munin, він активує набір плагінів за замовчуванням (принаймні, на ubuntu). Крім того, ви можете просто запустити, munin-node-configureщоб зрозуміти, які плагіни підтримуються у вашій системі. Більшість цих плагінів відображають прямі дані. Моє запитання не в тому, щоб пояснити природу даних (ну ... можливо, для деяких), а що саме ви шукаєте на цих графіках?

Встановити munin легко і подивитися вигадливі графіки. Але наявність графіків і неможливість їх "прочитати" робить їх абсолютно марними.

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

Тож дозвольте мені розділити це питання на три частини:

  • Плагіни, де я навіть не розумію даних
  • Плагіни, де я розумію дані, але не знаю, на що слід звертати увагу
  • Плагіни, які я думаю зрозуміти

Плагіни, де я навіть не розумію даних

Вони можуть містити питання, не обов'язково спрямовані лише на мунін. Нерозуміння даних зазвичай означає прогалину в фундаментальних знаннях про операційні системи / обладнання ....;) Не соромтеся відповісти "гійф" відповіддю.

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

  • Дискові виводи на пристрій (IOs / секунду)
    Що таке IO. Я знаю, що це означає вхід / вихід. Але це наскільки це йде.
  • Затримка диска на пристрій (середнє очікування вводу-виводу)
    Не підказка, що таке "очікування IO" ...
  • Час обслуговування IO
    Цей величезний безлад, і майже неможливо побачити щось на графіку.

Плагіни, де я розумію дані, але не знаю, на що слід звертати увагу

  • IOStat (блоки / друге читання / написане)
    Я припускаю, що на що слід звернути увагу - це шипи? Що означало б, що пристрій використовується у великій кількості?
  • Наявна ентропія (байти)
    Я припускаю, що це важливо для генерації випадкових чисел? Навіщо я буду це графікувати? Поки значення завжди було майже постійним.
  • VMStat (запущені процеси сну / введення / виведення)
    Яка різниця між цим та графіком "процеси"? Обидва показують процеси запуску / сну, тоді як, здається, в графіку "Процеси" є більше деталей.
  • Пропускна здатність диска на пристрій (байти / секунду прочитаного / записаного)
    Яка різниця між цим графіком та графіком "IOStat"?
  • використання таблиці inode
    Що слід шукати на цьому графіку?

Плагіни, які я думаю зрозуміти

Я зараз здогадаюсь про деякі речі ... виправте мене, якщо я помиляюся.

  • Використання диска у відсотках (відсотках)
    Скільки місця на диску використовується. Оскільки це наближається до 100%, вам слід подумати про очищення або розширення розділу. Це надзвичайно важливо для кореневого розділу.
  • Пропускна здатність брандмауера (пакети в секунду)
    Кількість пакетів, що проходять через брандмауер. Якщо це шипіння протягом більш тривалого періоду часу, це може бути ознакою атаки DOS (або ми просто отримуємо великий файл). Це також може дати вам уявлення про продуктивність вашого брандмауера. Якщо він вирівнюється і вам потрібна більша «потужність», слід розглянути питання про балансування навантаження. Якщо він вирівнюється і бачить співвідношення з завантаженням вашого процесора, це також може означати, що обладнання не досить швидко. Кореляції з використанням диска можуть вказувати на надмірні цілі LOG у вашій конфігурації FW.
  • Помилки eth0 (пакети в / в)
    Помилки мережі. Якщо це значення зростає, це може бути ознакою несправного обладнання.
  • et0 трафік (біт / секунда в / в)
    Сирий мережевий трафік. Це має відповідати пропускній здатності брандмауера.
  • кількість потоків
    Постійно зростаюче значення може вказувати на процес неправильного закриття ниток. Розслідуйте!
  • процеси
    Розпад активних процесів (включаючи сон). Швидкий сплеск тут може вказувати на вилку-бомбу. Повільне, але постійно зростаюче значення може вказувати на додаткові нерестові програми, але не закривати їх належним чином. Дослідіть за допомогою ps faux.
  • пріоритет процесу
    Це показує розподіл пріоритетів процесу. Наявність лише високоприоритетних процесів не приносить великої користі. Розглянемо деприоритетність деяких.
  • використання процесора
    Досить прямо. Якщо це спринцювання, у вас може статися атака, або процес піднімає процесор. Якщо це повільно зростає і наближається до максимуму в звичайних операціях, вам слід розглянути можливість оновлення обладнання (або збалансування навантаження).
  • використання файлової таблиці
    Кількість активно відкритих файлів. Якщо ця величина досягає максимуму, можливо, у вас відкриється процес, але не належним чином випускається файли.
  • load load
    Показує узагальнене значення для завантаження системи. Слід співвідноситись із використанням процесора. Збільшення значень може надходити з ряду джерел. Шукайте кореляції з іншими графіками.
  • використання пам'яті
    Графічне зображення пам’яті вам. Поки у вас є багато невикористаних + кеш + буферів, у вас все добре.
  • swap in / out
    Показує активність на вашому розділі swap. Це завжди має бути 0. Якщо ви бачите активність на цьому, вам слід додати більше пам’яті до вашої машини!

Чудове запитання, легко застосовно до кактусів та інших графічних програм. Графіки часто виглядають чудово, але досить важко розібратися, що вони означають, і більше, як виглядає щось, що потребує подальшої уваги.
dunxd

2
Для "Чому я буду це графікувати? Поки що значення завжди було майже постійним". частина, пам’ятайте, що більшість інформації, як правило, цінні лише у випадку проблем.
Стів Шнепп

Відповіді:


11

Дискові вводу-виводи на пристрій (IOs / секунду)

Для традиційних жорстких дисків це дуже важливе число. Операція вводу / виводу - це операція читання або запису на диск. За допомогою обертових шпинделів ви можете обійти від десятків до, можливо, 200 IOPS в секунду, в залежності від швидкості диска та його використання.

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

Затримка диска на пристрій (середнє очікування вводу-виводу)

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

Час обслуговування IO

Загальна ефективність роботи вашої дискової підсистеми (можливо, містить багато дисків).

IOStat (блоки / друге читання / написане)

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

Доступна ентропія (байти)

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

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

Одним із способів позбутися цієї проблеми є переключення програм на використання лише напіввипадкових даних (/ dev / urandom), але це вже не входить до цієї теми.

VMStat (запуск / процес сну / виводу)

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

Пропускна здатність диска на пристрій (байти / секундне читання / записане)

Це чисто байти, що читаються / записуються в секунду, і частіше це форма , що читається більш людиною, ніж блоки , які можуть змінюватися. Розмір блоку може відрізнятися через використовувані диски, файлову систему (та її налаштування) тощо. Іноді розмір блоку може становити 512 байт, інший раз 4096 байт, іноді щось інше.

використання таблиці inode

З файловими системами, що мають динамічні вставки (наприклад, XFS), нічого. З файловими системами, що мають статичні карти вкладень (наприклад, ext3), все. Якщо у вас є поєднання статичних входів, величезна файлова система та величезна кількість каталогів і невеликих файлів, ви можете зіткнутися з ситуацією, коли ви не можете створити більше файлів на цьому розділі, хоча теоретично залишилося б багато вільного місця. Без вільних вводів == погано.


враховуючи використання inode. Наразі я використовую ext4, а max-indodes та open-inodes у цьому графіку надзвичайно близькі (відкрито: розмір таблиці 31.11k: 32.12k). Котрий би залишив мені близько 1k inodes, що залишився. Оскільки система тільки що встановлена, я не вірю, що це вказує на проблему. Чи є ext4 динамічно розподіляючи вузли? Я нічого не знайшов про це в google ...
exhuma

Дивіться df -i, він повідомляє про ваше поточне використання inode. ext4 має виправлені inode, наприклад мої звіти Fedora 16 для мого кореневого розділуrootfs 3276800 238083 3038717 8% /
Janne Pikkarainen

Хммм ... цікаво. Це говорить про те, що графік муніна невірний. Я також просто не зрозумів, що графік муніна показує лише одне значення. Чи не повинно відображатись одне значення для файлової системи, щоб бути корисним? Дивіться також df -iскріншот ( i44.tinypic.com/oixkiq.png ) vs munin-graph ( i39.tinypic.com/dxl64z.png )
exhuma

... Значення в графіку (25,57k) насправді зовсім не видно у dfвисновку.
ексгума

Після подальшого дослідження я бачу, що плагін munin open_inodesприймає значення /proc/sys/fs/inode-nr. Це значення ядра, а не значення файлової системи. Трохи більше googling вказав на це: mjmwired.net/kernel/Documentation/sysctl/fs.txt#119 З цього документа я б припустив, що межу можна знайти в inode-max. Але цей файл не існує в моїй системі. Чи можливо це більше не стосується новіших ядер? Це дозволило б мені видалити цей графік із мого екземпляра munin!
ексгума
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.