Усіх із п'ятницею! Друзі, сьогодні ми продовжуємо серію публікацій присвячених курсу , бо заняття у новій групі з курсу стартують уже наприкінці наступного тижня. Тож почнемо!
Моніторинг - це просто. Це — відомий факт. Підніміть Nagios, запустіть NRPE на дистанційній системі, налаштуйте Nagios на порт NRPE TCP 5666 і у вас є моніторинг.
Це так легко, що нецікаво. Тепер у вас є основні метрики за процесорним часом, дисковою підсистемою, оперативною пам'яттю, що надходять за замовчуванням у Nagios та NRPE. Але насправді це не моніторинг як такий. Це лише початок.
(Зазвичай ставлять PNP4Nagios, RRDtool та Thruk, налаштовують повідомлення у Slack і йдуть прямо на nagiosexchange, але поки що опустимо це).
Хороший моніторинг насправді досить складний, вам дійсно потрібно знати нутрощі програми, за якою ви спостерігаєте.
Моніторинг – це складно?
Будь-який сервер, чи то Linux чи Windows, за визначенням слугуватиме якийсь мети. Apache, Samba, Tomcat, сховище файлів, LDAP - всі ці сервіси більш менш унікальні в одному або декількох відносинах. Кожен має свою функцію, свої особливості. Є різні способи отримання метрик, KPI (ключових показників ефективності), цікавих для вас, коли сервер буде під навантаженням.
Автор фото на
( хотілося б, щоб мої дашборди були пофарбовані в неоново-сині кольори - мрійливо зітхаючи - хм ...)
Будь-яке програмне забезпечення, що надає послуги, повинно мати механізм для збирання метрик. Apache має модуль mod-status, що відображає сторінку стану сервера. У Nginx - stub_status. Tomcat має JMX або спеціальні веб-програми, які показують ключові метрики. MySQL має команду «show global status» тощо.
То чому ж розробники не вбудовують подібні механізми до додатків, які вони створюють?
Чи тільки розробники це роблять?
Певний рівень байдужості до вбудовування метриків не обмежується розробниками. Я працював у компаніях, де розробляли додатки з використанням Tomcat і не видавали жодних своїх метрик, жодних логів активності сервісу, окрім загальних журналів помилок Tomcat. Деякі розробники генерують велику кількість логів, які нічого не значать для системного адміністратора, якому не пощастило їх читати о 3:15 ранку.
Автор фото на
Системні інженери, які дозволяють таким продуктам виходити в реліз, також мають відповідати за ситуацію. Небагато системних інженерів мають час і дбають про те, щоб спробувати отримати значні метрики з логів, без контексту цих метрик і можливості інтерпретувати їх у світлі активності програми. Деякі не розуміють, яку користь вони можуть отримати від цього, окрім показників на кшталт «щось нині (чи буде скоро) не так».
Зміна мислення щодо необхідності метрик має відбуватися як серед розробників, а й серед системних інженерів.
Для будь-якого системного інженера, якому необхідно не лише реагувати на критичні події, але й гарантувати їхню відсутність, відсутність метрик зазвичай є перешкодою для цього.
Однак системні інженери зазвичай не копаються у коді, заробляючи гроші для своєї компанії. Їм потрібні провідні розробники, які розуміють важливість відповідальності системного інженера у виявленні проблем, підвищенні обізнаності з проблемами продуктивності тощо.
Ця devops річ
Менталітет devops описує синергію мислення розробників (dev) та експлуатації (ops). Будь-яка компанія, яка заявляє, що вони «роблять devops», повинна:
- говорити те, що вони, ймовірно, не роблять (натяк на мем з фільму "Принцеса-Наречена" - "Я не думаю, що це означає те, що ти думаєш, що це означає!")
- заохочувати позицію постійного вдосконалення товару.
Ви не можете покращити продукт і знати, що він був покращений, якщо ви не знаєте, як він працює в даний час. Ви не зможете дізнатися, як працює продукт, якщо не розумієте, як працюють його компоненти, сервіси, від яких він залежить, його основні болючі точки і вузькі місця.
Якщо ви не спостерігаєте за потенційно вузькими місцями, ви не зможете слідувати техніці «П'ять чому» під час написання Postmortem'у. Ви не зможете зібрати все на одному екрані, щоб побачити, як працює продукт або дізнатися, як він виглядає "нормально та щасливо".
Зрушення вліво, ВЛІВО, Я СКАЗАВ, ЛЕЄЄЄЕЕ—
Для мене одним із ключових принципів Devops є "Зсув вліво" (shift left). Зсув вліво в цьому контексті означає зміщення можливості (не відповідальності, а тільки можливості) робити те, що піклуються зазвичай системні інженери, наприклад, створювати метрики продуктивності, ефективніше використовувати логи і т. д., вліво в життєвому циклі доставки програмного забезпечення (Software Delivery Life Cycle).
Автор фото на
Розробники програмного забезпечення повинні мати можливість використовувати та знати засоби моніторингу, які використовує компанія, щоб здійснювати моніторинг у всіх його формах, метриках, логуванні, інтерфейсах моніторингу та, що найважливіше, спостерігати як їхній продукт працює у продакшені. Ви не можете wзмусити розробників вкласти сили та час у моніторинг, поки вони не зможуть бачити метрики та впливати на те, як вони виглядають, як власник продукту представить їх CTO на наступному брифінгу тощо.
Коротше кажучи
- Приведіть коня до води. Покажіть розробникам скільки проблем вони зможуть уникнути для себе, допоможіть їм виділити правильні KPI та метрики для своїх програм, щоб було менше крику від власника продукту, на який кричить технічний директор (CTO). Виведіть їх на світ, м'яко та спокійно. Якщо це не вийде, підкупіть, погрожуйте і вмовляйте або їх, або власника продукту, щоб якнайшвидше реалізувати отримання цих метрик з додатків, а потім намалюйте діаграми. Це буде складно, оскільки це не буде розглядатися як пріоритет, і в дорожній карті продукту буде багато очікуваних реалізації проектів, що приносять дохід. Тому вам знадобиться економічне обґрунтування, щоб виправдати час та кошти, витрачені на використання моніторингу в продукт.
- Допоможіть системним інженерам виспатися. Покажіть їм, що застосування чек-листа «випускаємо реліз» для будь-якого продукту, що випускається, — це добре. І перевірка того, що всі програми в продакшені покриті метриками, допоможе досягти здорового сну ночами, дозволяючи розробникам бачити, що і де працює не так. Тим не менш, правильний спосіб дратувати та засмучувати будь-якого розробника, власника продукту та технічного директора – це наполегливо вставляти палиці у колеса та чинити опір. Така поведінка вплине на дату релізу будь-якого продукту, якщо знову чекати до останньої хвилини, так що знову виконайте зсув ліворуч і якнайшвидше включіть ці питання в план проекту. Якщо потрібно пробратися на зустрічі, присвячені продукту. Носіть підроблені вуса і фетр або щось таке, це ніколи не підведе. Повідомте про свої проблеми, покажіть очевидні переваги та євангелізуйте.
- Переконайтеся, що як розробники (dev), так і експлуатація (ops) розуміють значення та наслідок переходу метрик продукту в червону зону. Не залишайте експлуатацію як єдиний вартовий працездатності продукту, переконайтеся, що розробники також беруть участь у цьому (#productsquads).
- Логи – чудова штука, але метрики теж. Об'єднайте їх і не дозволяйте вашим логам стати сміттям у величезній палаючій кулі марності. Поясніть і покажіть розробникам, чому ніхто крім них не розбереться в їхніх логах, покажіть їм, як це дивитися на марні логи о 3:15 ранку.
Автор фото на
На цьому все. Новий матеріал вийде наступного тижня. Якщо ви бажаєте докладніше дізнатися про курс, запрошуємо на , що пройде вже у понеділок. А зараз ми традиційно чекаємо на ваші коментарі.
Джерело: habr.com