Константин Никифоров ( 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’а.
В чем плюс? Плюс заключается в том, что эта штука умеет хранить имя ноды, статус последней команды, время последнего сheck’а, последнего апдейта и время последнего коннекта, т.е. если у нас машина оторвется от нашего Puppet-агента, мы об этом узнаем.
kick, lock – это служебные части, не важно.
В чем плюсы? Плюсы заключаются в том, что наш scheduler – это веб-приложение. Т.е. по факту я могу выкатить код на весь production, не заходя на сервер, вообще. Выглядит это следующим образом: я открывают GIT, соответственно, прохожу все круги ада до deploy.sh, который я описывал на предыдущем слайде, а дальше просто мышкой выделяю в интерфейсике и нажимаю «накатить». Теперь вопрос: как я узнаю, что все не сломалось, помимо мониторинга?
Есть три статуса. Эта штука умеет не только показывать эти статусы, она еще показывает последний log Puppet’а. Поэтому у нас есть цветовая дифференциация наших серверов, которая имеет три цвета – зеленый, желтый и красный. Зеленый, понятно, это значит, что система актуальна, желтый – что система имеет какие-то обновления, но они не накачены, и красный, говорит о том, что манифесты сломаны на этой ноде, т.е. каталог для этой ноды не строится.
Данная штука запускает Puppet сheck, ну, -t –noop, в тот момент, если им не пользовались больше, чем четыре часа. Т.е. если мы видим в нашей «простыне» все зелененькие квадратики, мы знаем, что четыре часа назад у нас была актуальная конфигурация. Конечно, это время можно варьировать, но просто итерация выкладки и итерация размножения кода занимает немного продолжительное время, потому что, вы сами понимаете, что бывают не то, чтобы «выкатить версию», бывает «выкатить версию, обновить MySLQ, перестартить все memcached и еще что-то такое». Но, тем не менее, благодаря этой штуке, мы точно знаем:
- a) не сломали ли мы четыре часа назад где-нибудь наши манифесты, строится ли каталог для всех нод;
- b) текущее состояние нод, соответственно ±4 часа;
- c) мы имеем интерфейсик для накатывания конфигурации и слежения за этим в real time, т.е. они моргают – этот сheck, этот 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, из приложения шлют какие-то event’ы (клик по баннеру, например), шлют пакетик, пакетики эти агрегирует 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.
Автор:
