Огляд архітектури та підсистем деплоя і моніторингу. Як інженери роблять систему прозорою для розробки



Костянтин Нікіфоров ( melazyk
Доповідь про всякі секретні і не дуже штуки, що така велика компанія, як Mail.Ru використовує в моніторингу і для деплоя, і для управління конфігурацією.

Мене звати Костянтин Никифоров, я є керівником групи системних адміністраторів в компанії Mail.Ru. Наша група займається обслуговуванням проектів target.my.com, рекламними системами Mail.Ru і проектом top.mail.ru. Всі три наших проекту досить специфічні, бо ми не володіємо ніяким юзер контентом, ми в основному паразитуємо на вас, як користувачів, і наша особливість полягає в тому, що у нас дуже великі PPS на фронтах, що не в багатьох проектів є. Тобто в таких проектів, як Однокласники, ВКонтакте, це зрозуміло, тому що вони просто величезні, у більш дрібних проектів такого немає. А ми розміщуємося на всіх вищеперелічених і на всіх сторінках Mail.Ru тому наш PPS ще більше, ніж у цих проектів.


Ми поговоримо про те, як ми деплоим код. Від моменту, коли розробники нам його віддають, до моменту, коли він з'являється в productionе, і користувач бачить ефект від його зміни.



Моя доповідь буде розділений на три частини: у першій частині ми поговоримо про деплое, у другій частині ми поговоримо про Graphite як спосіб реалізації роботи проекту, і в третій частині ми поговоримо, як ми об'єднуємо наш Graphite, нашу систему деплоя, в даному випадку Puppet, і нашу систему моніторингу.



Спочатку про організацію зберігання маніфестів Puppet, і чому ми вибрали Puppet. Puppet ми обрали з однієї причини – тому що це є практично корпоративних стандартів компанії Mail.Ru. Всі відділи всіх проектів використовують для maintain конфігурації Puppet. Будь-яка система конфігурації марна без контролю версій, тому що якщо ти не можеш показати, що ти зраджував в проекті, сенсу в цьому ніякого немає. Природно, зараз дуже велика кількість різних систем контролю версій, ми використовуємо найбільш популярну на даний момент, це GIT.

Як організовано сам процес Puppet, тобто як організоване оточення Puppet'а? Ми поділяємо всіх наших користувачів на environment'и. Тобто кожен користувач, заведений root'ом на сервері, є власником одного environment'а, іменований для нього. Ну, для мене це «Никифоров», для моїх підлеглих – це їх прізвища. І один environment «Production», який є поточною конфігурацією production системи. Відповідно, всі сервери повинні бути синхронізовані саме з environment «Production». Для тестування, для розробки нових маніфестів, для розробки модулів, для розробки і тестування якихось нових фіч або якихось нових підходів ми використовуємо тільки environment, щоб не зламати production систему.

Ще одна умова, яку ми виконуємо завжди, пов'язане з тим, про що я розповім далі. Всі сервера в наших проектах, без винятку, управляються Puppet'ом. 100% серверів. Немає жодної викладки, яку ми б робили без commit'а. Але щоб правильно організувати різні версії софта на різних серверах, різні тестові, різні експериментальні варіанти системи – для цього ми використовуємо деякі угоди, які нам дозволяють це робити найбільш гнучко і найбільш зручно для нас. Одне з таких угод – це модуль base:, який ми пишемо cross всі сервера, тобто у нас не може піднятися сервер без цього модуля. Вважається, що дефолтний define ноди – це клас base:. Для чого це зроблено? Зрозуміло, що це накочує всілякі core системи, всякі, баші, syslog'і, config'і і подібні речі, але ключова річ у цьому класі base: – клас base: зберігає роль сервера.



Зараз ви бачите трикутник, який показує структуру нашої Hiera, застосування зміни наших змінних. З верхнього рівня – дефолтні змінні, які ми використовуємо за замовчуванням, далі перезаписуємо це справа співвідносно ОС, щодо майданчика, щодо ролі і хоста.

З цих п'яти речей дві речі досить службові – ОС і майданчик.

Чому ОС? Вона потрібна тільки для того, щоб трохи відредагувати клас base:, тому що все-таки за набором софта системи CentOS 7, CentOS 6, які ми використовуємо, відрізняються. І щоб це справа синхронізувати і нівелювати, ми використовуємо цю проміжну Hiera, якої ми вирівнюємо дефолтні значення.

Майданчик, здебільшого, належить до того класу, щоб зробити локалізацію трафіків всередині майданчика. Наприклад, нерозумно ходити з одного майданчика в LDAP-сервера на інший майданчику, це зовсім нікому не потрібно, та у разі відвалу майданчики приводить, взагалі-то, до деструктивних дій. Тому в даному випадку ми це використовуємо в більш службових цілях. У нас є така функа, називається FQDN rotate IP, яка робить таку річ – ми передаємо, наприклад, LDAP-сервера; у нас є їх 12 штук, ми їх запихаємо в один масив і говоримо, типу, ці LDAP-сервера накотити на всі сервери. Але наш FQDN rotate розумний – він бере весь цей масив, вигрібає з сервера, які є сусідніми для цього сервера, перемішує їх, щоб розподілити небагато навантаження, кладе їх у початок списку, щоб використовувати їх пріоритетно, інші перемішує далі. Т. о. відбувається невелика ентропія як в перемішуванні всередині майданчика, так відбувається ентропія при перемішуванні в LDAP-майданчику. І на різних майданчиках це все ротується.

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

І ключова річ – роль – це змінна в класі base:. Зрозуміло, що роль поділяє сервера логічно, припустимо, фронтенды, MySQL, Tarantool і т. д. Але чому ми включаємо це base:? Тому що це дозволяє нам цю роль перевизначати. Якщо ви будете прибивати, наприклад, в Hiera якусь змінну, вам доведеться стежити за тим, що ви будете Hiera'ой завжди ігнорувати якусь роль. Припустимо, ви написали в хост: це роль «фронтенд». Ви будете зобов'язані кожну ноду написати, що це роль «фронтенд». Вам не буде достатньо взяти ще один сервер, розповісти типу, «ось такий клас» і Enter. Ні, вам потрібно буде піти в Hiera і прописати, що він «фронтенд». В даному випадку ми можемо цю base роль перевизначати. Припустимо, ми можемо поставити сервер, сервер буде без ролі, потім ми йому призначаємо роль, наприклад, «MySQL», а потім її переназначаем в якому-небудь іншому маніфесті в іншій частині. Це ми можемо зробити. І це дозволяє нам більш гнучко поводитися з цими ролями.

Нижній рівень – це хост. Тобто по факту ми отримуємо тільки три рівня. Як я говорив, ОС і майданчик – це службові рівні, які ми використовуємо остільки-оскільки, не використовуємо в момент розробки маніфестів. Ми використовуємо три рівні: загальні змінні, роль і хост. Як показала практика, трьох рівнів цілком достатньо для того, щоб гнучким чином налаштувати всі змінні сервера та хостів, як таких.

Є, звичайно, деяку незручність. Припустимо, у нас є роль яких-небудь «Nginx», і на 15-ти Nginx'ах з 38-ми нам треба викотити якусь конкретну версію. Тут доведеться це визначати в кожному хості, на жаль, але такого софта в наших проектах не так багато. Таких всього лише один, в якому ми активно міняємо версії, все решта ми просто розподілили за ролями. Розділили, і цього виявилося достатньо.



Тепер поговоримо про те, як ми пишемо маніфести.

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

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

Паролі. Паролі, ми зберігаємо досить хитрим чином. Я, чесно кажучи, не знаю, використовує чи хто-небудь таку ж систему. Справа в тому, що ми намагаємося зробити нашу систему прозорою для нашої розробки. Це дуже важливо, тому що розробка – це те, заради чого, власне, живе проект, завдяки чому живе проект. Ми все-таки така допоміжна служба, яка допомагає всьому цьому жити. Тому розробці треба надати велику кількість інформації, і ми розробці віддаємо всі маніфести, всі модулі, оскільки програмісти більш здатні до програмування як такого. І сподіватися на те, що служба експлуатації програмує краще, ніж служба розробки – це нерозумно. Тому ми віддаємо всі наші маніфести, але ми не можемо віддати паролі, що ж робити з цим? Є дуже просте рішення, яке ми придумали – ми відокремлюємо всі паролі в окремий файл PP, який ми зберігаємо поза нашого репозиторію. Всередині репозиторію ми робимо симлинк на цей файл, незалежним чином бэкапим і незалежним чином стежимо за версіями, за версионностью. Що гріха таїти, це просто RCS, насправді. Але це дозволяє нам розділити весь код проекту від паролів.

Таким чином, ми можемо віддати всі наші модулі всім відділам у компанії. Звичайно, ми не можемо їх викласти в open source, по тій простій причині, що буде видна структура, архітектура проекту, що саме по собі досить секретна інформація. Але, тим не менш, ми можемо це віддати всім нашим колегам, які можуть скористатися нашим досвідом, а можуть і поправити наші помилки. Це дуже важливо.

І третє – «розкажи всім». Є у нас система моніторингу, про яку мене Саша попросив не розповідати особливо, тому що вона closed source, і ми намагаємося поменше про це говорити, але сенс полягає в тому, що у нас є якийсь ресурс, яким ми можемо экспортить прямо з Puppet'а роль у моніторинг. Тобто ми можемо, наприклад, сказати, що на цьому сервері ми встановили MySQL, накотили маніфест, і в цей же момент у нас у моніторингу з'являється «тут ми встановили MySQL».

Визначити роль ми можемо будь-який, не обов'язково це має бути модуль, але хорошим тоном є – написав модуль, накотив на якийсь сервер, і ми повинні знати, що ми цей модуль кудись накотили, наприклад, який-небудь новий софт. Але такими ролями, пушами в наш моніторинг можуть бути, наприклад, різні конфігурації фронтендов, можуть бути різні шарды. Наприклад, можемо підняти вісім Tarantool'ів, які є шардами однієї сутності, що одних даних, і ми можемо побачити, що у нас встановлений Tarantool. Ця інформація нам, загалом, нічого не дає. Ну, Tarantool і Tarantool. C допомогою цієї штуки ми можемо експортувати безпосередньо шарды. У нас є, скажімо, клас, який визначає шардінг, грубо кажучи, ми знаємо точно, який Tarantool яким шардом є, і цю ж інформацію ми можемо запушить прямо в опис хоста в моніторинг. Це допомагає дуже швидко знайти потрібні сутності в нашому проекті.



Перейдемо до деплою. Концепція червоної кнопки. Є у нас така концепція, яка на наш погляд є найбільш вірною. Дуже багато вішають хуки на різні системи контролю версій, за якими код виїжджає в production. Ми відмовилися від цієї речі, тому що в компанії Mail.Ru прийнято угоду того, що адмін, який викочує код, несе відповідальність за все. Не важливо, що в цьому коді написали. Тому, якщо ти викотив якусь неправильну програму, ти повинен це полагодити. Розробник не несе в даному випадку відповідальності. Звичайно ж, він несе відповідальність перед тобою і перед своєю совістю, але, тим не менш, прийдуть до тебе, і ти будеш це все справа виправляти.

Тому у нас є концепція червоної кнопки deploy.sh. Це звичайний Bash-скрипт, який вміє робити дуже просту річ – він вміє викочувати з майстра GIT в environment «Production». Тобто все, що він робить – він бере з майстра і кладе в environment «Production».

У нього є деякі опції – це «викотити майстер» на яку-небудь дату, тобто якщо ми можемо сказати: «Викотити на вчора на 9 ранку», він, відповідно, знайде commit, який був актуальний на 9 ранку, і викотить його. Або безпосередньо «передати commit». Додатковою опцією до всього цій справі є log.

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

У цей момент повинен бути один єдиний відповідальний чоловік, який повинен сказати: «Хлопці, вистачить!». Як правило, це «Хлопці, вистачить!» зіставляється з откаткой коду. У нашому випадку, з откаткой маніфесту. Тому ми випробовуємо маніфести, використовуючи другу або третю опції, і лочим цей деплой. Т. о., коли адмін приходить і намагається викотити в production що-небудь нове, що йому розробник нарадив і сказав, що зараз все починится, він нападає на ту ситуацію, коли йому кажуть: «Ні, ось такий-то людина залочил, і більше ми нічого не викочуємо». Це дозволяє зробити такий стопор, який не дозволяє ламати проект далі.

За останні три роки такий функціонал нам знадобився один раз, може, два. Один пам'ятаю точно, другий, мабуть, вигадав. І в цей момент я ні краплі не пошкодував про таке прийняте рішення. Але це, знову ж таки, все на ваш розсуд – хтось дуже впевнений у своїх commit'ах, я не впевнений. Ні в одному commit'е я не впевнений в нашому маніфесті, тому повинна бути ще й система, яка стежить за тим, що ми не тільки накотили одну групу серверів, але і не зламали іншу групу серверів. Про це й поговоримо далі.



Зараз ми поговоримо про те, як у нас викочується код production і, взагалі, цілком і повністю повний цикл.

Повний цикл дуже простий: ми робимо Branch від майстра, далі редагуємо свій Branch. Це може займати, може, день, може, два, може бути, тиждень, тому ми протягом редагування свого Branch, ребейзимся про майстер, щоб мати шанс потім, взагалі, помержиться з ним. Далі тестуємо всі залежно від хоста, від групи і т. д. в потрібних позиціях з свого environment'а й перед выкаткой у production, мержим це майстер, deploy.sh, погнали по всьому. І при невдалому merge все повертається, зациклюється, і цикл повторюється кілька разів, якщо це необхідно.



Цей слайд я випадково сюди встромив. Насправді, ідея була така, що я розповідаю про те, що Puppet досить гнучка система, яку можна масштабувати, і будь-яка людина, який розумів веб-проект, розуміє, що така система масштабування дуже проста і може бути з нього Puppet. Тому я вважаю, що пропустимо цей слайд. Єдине, можу сказати, що ми використовуємо одне DNS-ім'я, на яке виписуємо сертифікат. Це DNS-ім'я у нас є синеймом, тому ми, копіюючи сертифікати і копіюючи адреси, можемо носити разом із сертифікатами на будь-які машини Puppet і піднімати їх хоч 200 штук. А все інше – стандартне масштабоване додаток.



А тепер про альтернативу – Puppet kick. Пам'ятайте про те, що я говорив, що нам потрібно знати, чи актуальна наша система в цілому, коли ми змінили один єдиний шматочок? У Puppet була така штуковина Puppet kick, яку вони випиляли. Вона була дуже страшна, чесно кажучи, дуже незручна і дуже негарна, але вона дозволяла з майстер-ноди зробити викладку по всім проектам. Потім вони поміняли на Marionette, але досить «мікроскопом по горобцях», тому що все-таки можна з таким же успіхом просто Puppet агент вбахать, або з крона… Досить сумнівна штука, тому ми зробили свою систему, клієнт-серверну систему Puppet агентом, ми її назвали Puppet kill по причині того, що на серверній частині, у нас працюють scheduler'и і там черга завдань, що накочується на наш production; ми можемо регулювати одночасну накатку на групу, тобто в межах групи не котити більше ніж два сервери одночасно або три. Можемо регулювати накатку по всім серверам. Загалом, стандартні завдання scheduler'а.

У чому плюс? Плюс полягає в тому, що ця штука вміє зберігати ім'я ноди, статус останньої команди, час останнього сһеск'а, останнього апдейта і час останнього конекту, тобто якщо у нас машина відірветься від нашого Puppet-агента, ми про це дізнаємося.

kick, lock – це службові частини, не важливо.

У чому плюси? Плюси полягають у тому, що наш scheduler – це веб-додаток. Тобто за фактом я можу викотити код на весь production, не заходячи на сервер, взагалі. Виглядає це наступним чином: я відкривають GIT, відповідно, проходжу всі кола пекла до deploy.sh, який я описував на попередньому слайді, а далі просто мишкою виділяю в интерфейсике і натискаю «накотити». Тепер питання: як я дізнаюся, що все не зламалося, крім моніторингу?

Є три статусу. Ця штука вміє не лише показувати ці статуси, вона ще показує останній log Puppet'а. Тому у нас є колірна диференціація наших серверів, яка має три кольори – зелений, жовтий і червоний. Зелений, зрозуміло, це означає, що система актуальна, жовтий – що система має якісь оновлення, але вони не накачані, і червоний, говорить про те, що маніфести зламані на цій ноде, тобто каталог для цієї ноди не будується.

Дана штука запускає Puppet сһеск, ну, -t –noop, в той момент, якщо їм не користувалися більше, ніж чотири години. Тобто якщо ми бачимо в нашій «простирадлі» все зелененькі квадратики, ми знаємо, що чотири години тому в нас була актуальна конфігурація. Звичайно, цей час можна варіювати, але просто ітерація викладки і ітерація розмноження коду займає трохи тривалий час, тому що, ви самі розумієте, що бувають не те, щоб «викотити версію» буває «викотити версію, оновити MySLQ, перестартить всі memcached і ще щось таке». Але, тим не менш, завдяки цій штуці, ми точно знаємо:

  • a) не зламали ми чотири години тому де-небудь наші маніфести, будується каталог для всіх нсд;
  • b) поточний стан нод, відповідно ±4 години;
  • c) ми маємо интерфейсик для накочування конфігурації і стеження за цим real time, тобто вони моргають – цей сһеск, цей update і т. д. Дуже круто виглядає. На жаль, я хотів вам показати демонстрацію всього цього діла, але ми не встигли підготувати стенд.


Друга частина системи, яку ми використовуємо, це Graphite. Це open source рішення, яке багато хто з вас напевно використовують, яка вміє лише дві речі – зберігати чиселки, прив'язані до timestamp, показувати ці чиселки, і більше вона не вміє нічого, чим вона, на мій погляд, прекрасна. Базується вона на трьох китах: це демон carbon, що приймає udp-пакети; це база даних whisper (зараз це ceres), яка дозволяє динамічно розсовувати її; і Graphite-web – це морда.

У чому плюси даного продукту? Справа в тому, що всі три частини ми можемо замінити. Всі ці три частини мають альтернативи. Наприклад, в якості бекенду ми можемо використовувати такі речі як fluxdb. Як Graphite web є величезна кількість морд, яке ми можемо використовувати. В Яндексі, я знаю, використовують нестандартну, ми використовуємо стандартну.

Але ключовий момент у цьому всьому – це carbon, тому що це саме та частина, яку ми для свого проекту модифікували.



Спочатку поговоримо про те, які метрики ми зберігаємо. Зрозуміло, стандартні метрики, які зберігають всі і малюють все. Метрики додатків, завдяки тому, що Graphite використовує не тільки TCP-протокол, але і UDP, ми можемо з додатка в неблокирующем режимі надсилати будь-які метрики, які нас цікавлять. Наприклад, в нашому рекламному сервері target'а хлопці доходять до такого маразму, що вони шлють просто всі змінні, які у них є в демона, тобто, наприклад, у нас є графік версії пакету. Версія у них зашита в бінарі, і ви розумієте, як цей графік виглядає – така пряма на 3 дні, зліт, і ще пряма на 4 дні, і далі ця драбинка, іноді вона, звичайно, йде вниз, але абсолютно даремна штука. Зберігаємо, наприклад, час зльоту демона, теж дуже «корисно» – злітаємо і пряма. Але нам це не складно, нам це не дорого, тому нам все одно, які метрики вони малюють, чим більше метрик, тим краще, це допомагає в подальшому аналізі ситуації, коли ситуація виходить з-під контролю. І складно одержувані показники – це показники, які ми вважаємо із статистичних даних, це в основному завдання бізнесу.



Тепер перейдемо до тієї речі, яку, напевно, я постараюся вам продати. Деякі речі нестандартні, метрики додатків, стають стандартними. Один з таких прикладів – це Graphite-nginx-module. Це модуль для Nginx, який дозволяє відсилати різні метрики per location, тобто наприклад, ми можемо незалежно в одному Nginx відсилати rps на всіх location'ах, окремо. Я не знаю жодного способу це зробити. Хто-небудь знає?

З залу: Ще можна парсити log'і, і через Logstash відправляти дані в Graphite.

Я чекав відповіді, спасибі вам величезне. Значить так, розповідаю про парсинг log'ів. Ситуація полягає в тому, що кількість запитів по нашому проекту така, що якщо ми будемо писати log'і наш сервіс не буде працювати. Одна річ, в якій ми пишемо log'та, від якої ми не можемо відмовитися, на жаль, тому що вона нам потрібна для debug'а, тому що, щоб розслідувати інциденти, нам потрібні безпосередньо log'в. Ця штуковина пише log'ів на один сервер 1 Тбайт на добу. Це мало. Це мало. А тепер помножте це в «дцять» і парсите. Удачі!



У Graphite є очевидні проблеми, які відомі всім. Дуже багато використовують Graphite наступним чином: беруть StatsD, ставлять StatsD, з програми шлють якісь подієві и (клік по банеру, наприклад), шлють пакетик, пакетики ці агрегує StatsD, а агреговану статистику шле в наш Graphite. Це вирішує ту проблему, що якщо ми будемо слати це безпосередньо в наш Graphite, він може просто загнутися по UDP, але при цьому якщо ми будемо слати на StatsD величезна кількість цих UDP-пакетів, у нас все одно буде межа. Але це вирішується класичним масштабуванням, різними динамічними маршрутизациями і т. д. Про це я не буду розмовляти, всі ми системні адміністратори, всі ми розуміємо, як це робиться.

Друга проблема – це кластеризація. З якоїсь версії Graphite навчився збирати з декількох carbon'ів графіки в одну морду, це дуже зручна штука, але має ряд незручностей. Перше в ряду незручностей, єдине і найбільше, що є – це якщо ви пошлете в два carbon'a однакові метрики, то він вибере будь-яку. Не знаю, як. Не цікаво, тому що це абсолютно неюзабильно. З цієї причини масштабування – штука досить складна в поточній реалізації carbon. Але ми пішли трохи іншим шляхом – замість масштабування ми використовували інший carbon.

У мене тут черепашка над повільним carbon'ом намальована, ми з цієї черепашки зробили таку черепашку:



Відповідно, стандартний carbon в його поточній реалізації. Ще треба врахувати, що перша версія carbon'а була трохи спритніші, перед тим як вони її переписали на ООП, там була втрата продуктивності відсотків 15. І, на жаль, це архітектурна штука, і навіть розробники самі зізнавалися, що «Так, але зате ми зробили гарний код». Тому ми дуже довго жили на новій морді Graphite і на старому carbon'е.

Коли наші метрики на один сервер приходили вже в 1-1,2 млн., CPU на сервері став закінчуватися. Зовсім. Це втрата метрик, втрата даних. У нас не так багато метрик, тому що проводимо ревізії та чищення, ми знаходимо мертві метрики, які ми шолом. У нас метрик надсилається десь в районі мільйона, під мільйон. Велика проблема для нашої служби інфраструктури, тому що у них ця цифра перевищує нашу рази в три. І тут приходить на допомогу наш go-carbon. Це імплементація carbon мовою go. Несподівано. Просто заміна carbon дає boost десь в 3-4 рази. За нашими розрахунками на цьому залізі ми прокачували 1.2 млн. Розрахункові дані говорять про те, що ми в поточному ж сервері, тільки замінивши один carbon, можемо прокачувати вже до 8 млн. метрик.



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

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

Як моніторити додаток? Ніхто не знає, як працює додаток. Ось, тобі прийшов новий додаток «трам-пара-пам Д», треба запустити. Запускаєш. І що? А що моніторити? Що не впав? Ну, здорово. Реально, це проблема кожного системного адміністратора – з'явилася нова сутність, незрозуміло, що з нею робити. І в даному випадку ми домовилися з розробниками, що вони всі наші log'і стандартизують, у нас все log'і в однаковому форматі. Типу: timestаmp, рівень і далі помилочка. Всі демони роблять це однаково, тому наша штука вміє тейлить log, і в разі errors, info і т. д. це экспортится прямо в моніторинг. Тобто базове налаштування сервера ми моніторимо дуже просто. Ми говоримо: «Моніторимо його log». І якщо він в log шле щось погане, ми про це завжди дізнаємося.

І ще є експорт помилок у великій моніторинг, але це зрозуміло, що не буде по нашому готельному моніторингу працювати велика служба duty адмінів, які обдзвонюють n проектів. Тому у нас є агрегація моніторингу, яку дивиться безпосередньо черговий адміністратор цілодобово, і є система оповіщення – SMS і всі супутні речі.

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



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

І в якості кінця, речі, про які я говорив – про модулі Nginx, go-carbon – це open source продукти тепер. Дякую Саші Бикову, Міші Кириченко і Ромі Ломоносову, які це все написали, які врахували наші побажання, виправили те, що треба, так що ви можете використовувати, можете писати feedbacks, чим більше буде відгуків, тим якісніше буде продукт, якщо він вам буде потрібен.

Контакти
» melazyk
» k.nikiforov@corp.mail.ru
» Блог компанії Mail.Ru

Ця доповідь — розшифровка одного з кращих виступів на професійній конференції з експлуатації та devops RootConf.

На сайті можна підписатися на список розсилки з новинами і ось такими статтями :)

Ну і головна новина — ми почали підготовку весняного фестивалю "Російські інтернет-технології", в який входить вісім конференцій, включаючи RootConf.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.