Pull to refresh

Comments 55

>В итоге, после того как инженер из команды мониторинга создаст отчёт и оформит все проблемы, руководители возлагают на администраторов следующие задачи

Похоже, сегодня это гифка дня. Из каждого утюга и по любому более-менее подходящему поводу. :(
Чем не устроили другие системы мониторинга, такие как zabbix или ibm tivoli monitoring?
Zabbix мы используем как оперативный мониторинг.
В статье описано решение того, как мы заранее узнаём о возможных проблемах в инфраструктуре. Zabbix для этой задачи не годится, потому что он плохо работает с таким кол-вом исторических данных, мы там храним только короткий (оперативный) промежуток времени.

Хотя Zabbix у нас используется для оперативного мониторинга, причем на срабатывания какого-либо триггера автоматически создаётся инцидент в JIRA.
А вы не пробовали хотя бы посмотреть в триал режиме, как будет справляться IBM Tivloi Monitoring?
Исходя из своего опыта общения с софтом IBM могу сказать, что время вы точно зря не потратите.
Просто у вас уже вырос из разряда «детских» и «юношеских», а инструменты решения задач остались на уровне стартаперских и самописных.

В целом, интересная статья, спасибо.
Достаточно почитать статью на забре про Tivoli, и желание использовать сей продукт пропадет само собой. Как говорится, «не читал, но осуждаю»:
  • интерфейс выглядит ужасно. С локализацией — вообще ад
  • написано чуть ли не в девяностых
  • стоит как космический корабль
  • саппорт у этого тула наверняка такой же адский, как и у всего остального IBM
  • попытки что-то погуглить не выдают горы ответов, поэтому, подозреваю, что в эксплуатации будет много трудностей


Впрочем, это все домыслы — с этим тулом я не работал. А вообще хочется что-то не очень дорогое, свежее и с большим коммьюнити.
Я какое-то время уже с Tivoli не работал, но постараюсь внести пару светлых пятен в ваше мрачное описание:
1. Настоящие пацаны интерфейсом не пользуются :) (шутка). Статья от 2013 года, в последних версиях ПО у IBM были довольно неплохие изменения на сколько я помню.
Что касается локализации, вот тут увы. На данный момент рынок корпоративного ПО довольно небольшой и локализации может не быть. Однако, с IBM всегда можно договориться о сотрудничестве. Они ребята умные и вежливые, может случиться так, что именно вы станете тем заказчиком для которого будет создана локализация.
2. Ядро написано довольно давно, но это не значит, что оно не модифицируется со временем и на мой взгляд задачи мониторинга с тех пор принципиально не изменились. Ньюансы-же настраиваемы.
3. Или как розовый слон :) Или как чугунный мост. Опять-же всё обсуждаемо и зависит от того на каких мощностях вы хотите использовать ПО. Там даже конфигуратор есть и программы типа On Demand. Вообще, на мой взгляд люди боятся IBM, т.к. думают что «оооо, это же IBM, у них всё дорого». Это не правильно. В конечном итоге и них дешевле, но не будем сейчас про TCO.
4. Я извиняюсь, но саппорт IBM был признан лучшим в мире. Сам с ним сталкивался, очень толковые специалисты + отличная система обработки тикетов + возможность привлечь ЛЮБОГО нужного специалиста компании по всему миру. Я не знаю откуда у вас негативная информация.
5. http://www.redbooks.ibm.com/. Вы меня, конечно, простите, но после окончания института пора уже перестать быть «стажёром» и вырасти до настоящего инженера, который знает где лежат руководства, пользуется best practices (которые, к стати тоже не глупые люди пишут) и который понимает, что если к софту есть инструкция, то её надо почитать.
Каюсь, сам из-за лени временами пытаюсь гуглить ответы на сайтах типа segfault и stackoverload, но когда дело касается серьёзного софта, решение в итоге проще и быстрее находится в руководствах.
Ещё boulder никто не отменял:
http://www.ibm.com/support/knowledgecenter/SSTFXA_6.3.0.1/com.ibm.itm.doc_6.3/welcome.htm
отличная библеотека по многим продуктам IBM.

Я за себя скажу: В один прекрасный день я проснулся и обнаружил, что есть мир за гранью командной строки Linux и глубже чем можно залезть мышью в Windows. Что серьёзные системы работают совсем на других ОС и что велосипеды которые придумывают в мире широкого потребления уже летают со сверхсветовыми скоростями где-то в датацентрах.
В общем, что касается Tivoli — стоит попробовать. ;)
Я не знаю откуда у вас негативная информация.

У меня совсем другие впечатления. Тикет вам конечно заведут — но фикса вы можете ждать много месяцев — и когда дождетесь, получите совсем не то, чего хотели.

Понимаю, что в мире ентерпрайза принято надувать щёки и хвастаться TCO. Но все продукты IBM, с которыми довелось работать, старали от одних и тех же проблем:
1. Неконсистентность. Ядро сделано нормальными инженерами, но плагины и отдельные фичи часто пишут на коленке где-то в Индии.
2. Любой продукт это «вещь в себе» и требует бородатого админа для обслуживания. Особенно забавно смотрятся вакансии интеграторов, где в требованиях перечисляют несколько малосвязанных продуктов или просто Tivoli.
3. Несмотря на формальное наличие всех нужных фичей, их реализация зачастую уступает конкурентам.
4. Отсутствует сообщество и мало информации в доступном виде. Есть курсы, но именно на них попался лектор с нулевой практикой, пересказывавший учебник вперемешку с рекламным булщитом.

А плюс IBM в неплохой поддержке, бекдорах сертификации ФСБ/ФСТЭК и возможности решить практически любую задачу, пусть дорого и с чудовищным юзабилити.

за "бабло", которое уйдет на Tivoli можно в космос слетать. спросите любого, кто внедрял эту "систему".

Сильно сказано. Добавить особо нечего, если не разводить философию на тему того, что идеального софта не бывает.
Посмотрите в сторону Moogsoft, интересное решение
По вашей ссылке статья не про Tivoli Monitoring а про другой продукт из линейки Tivoli.
Насчет ваших домыслов, то с какими-то из них соглашусь (продуктом пользовался). А насчет желания это да, всегда хочется дешево, быстро и качественно.
Попробую ответить или опровергнуть.
* Интерфейс и локализация, по сравнению с версией статьи 2013 года стала получше.
Я может сужу со своей колокольни, но читая переводы статей на сайте IBM, понимаешь что работали над ними, именно работали, а не гугл транслейт.
* То что написано чуть ли в не 90-ых есть свои плюсы, в статье более подробно.
* Горы ответов и вправду нет, всю документация только на сайте ibm, и не так такого сообщества как у Zabbix.

Спасибо за интересную статью, тема мониторинга думаю всегда будет интересна.
У нас настроена связка grafana + graphite + collectd. Icinga2 в роли оповещалки, часть метрик берет из графита. Графики можно накладывать друг на друга и анализировать. Сложно было только настраивать icinga2, но после недели чтения документации все прояснилось… Был заббикс по началу, но у него нет такой гибкости как у icinga2.
Тоже от Zabbix когда-то отказались и тоже такую связку используем, только вместо Icinga — sensu и оповещалка через PagerDuty. Функционал Icinga реализуется сенсовыми чеками, а исторические данные храним в графите.
Графана удобна тем, что у нас дежурные сидят и глазами в графики глядят — отклонения и странные тенденции видят лучше всяких анализаторов.
Ребята, а почему не подобное решение:
1. Фреймворк мониторинга а-ля Sensu.
2. Хранение истории чеков в Elastic
3. Сбор метрик коллектором с отправкой в Cassandra, допустим. И Spark для анализа данных, как движок для вычислений.
4. Push метрик, а не pull, потому что исключает необходимость наличия точки опроса (+1 к отказоустойчивости, -1 к сервисам на обслуживании). Правда SNMP тут уже не очень удобно будет, но это всего лишь протокол, благо тысячи их.

То есть, в принципе, получается, как и у вас, раздельный оперативный мониторинг и анализ исторических данных. Кстати, вот Influx обещают скоро таки допилить два в одном, но когда это будет…
Получается, ваша задача отлично сводится к «положить данные в жирное хранилище, которое можно читать чем нибудь для big data analyse», а дальше в принципе выбор есть. Но пара Cassandra+Spark пожалуй самая зрелая и распространенная, есть поддержка python (весьма распространенный язык среди админов), да и real-time опять же есть, можно часть алертов из мониторинга туда утащить, что как раз хорошо, потому что тогда можно stateless системы для оперативных алертов использовать, типа сбоя RAID или просто ухода машины в офлайн.
Тем более 300 гб данных в неделю с ЦОД — это не много. Если в сумме их 1ТБ, допустим, то это ~150Тб в год при репликации х3, или 4 storage-сервера максимум. В масштабах основной инфраструктуры — капля в море.
В Zabbix не все хорошо с историческими данными. А тут довольно много получается и надо регулярно их анализировать.
Даже в последнем, где предсказания добавлены как новая фича?
Даже в последнем всё ещё нет альтернативы MySQL для долговременного хранения данных, нет алтернативы встроенным функциям для триггеров и нет распределённого мониторинга без SPOF.
Пока модерировали, уже запостили гифку :(
А для метрик, которые больше связаны с не железом, а с приложениями (например количество запросов на какому-то URL, время ответа, количество 404 и т.п) — используете какое-то другое решение?
нет, в общем и целом это то же решение. только данные туда попадают чуть по другому.
А рассматривали возможность использования что-то вроде SignalFX, prometheus.io? Если да — то что не устроило, если не секрет?
Рассматривали, но оно должно быть способным заменить собой все имеющиеся у нас системы мониторинга (различные in-house и opensource решения). Требований было достаточно много, но ничего сверхестественного по сегодняшним меркам. Тем не менее ни одно решение не подошло настолько, что бы бросится его внедрять (а заменить хорошо настроенный мониторинг в компании никогда не бывает легко). Кроме того у нас уже есть очень мощная по своим возможностям и производительности система, которая работает с различными performance метриками приложений. Именно она и легла в основу будущей системы.
Почему у всех графиков ось значений начинаются с 0, а на графике кол-ва серверов с 6000?
Слышал что у вас нет отдельного нагрузочного тестирования. Как обходитесь без него?
Нагрузочное тестирование для новых технических решений проводим обязательно. И не только на синтетических тестах, а так же и на реальной нагрузке, включая систему в параллельном режиме.
важно, что не только в параллельном, но и асинхронном. То есть, лаги на тестируемой системе никак не аффектят продакшен.

Вы правду про кухню одноклассников написали?


Жесткие пороги и линейный прогноз — это из 90-х. Так сейчас работают в "Home Office".


Адаптивные бейслайны, нелинейный прогноз для временных рядов…
см., например, продукты Vmware чего-то там, ранее Integrien Alive.


А что делаете с кратковременными нарушениями? В промышленных системах мониторинга есть еще и "окно наблюдения" для снижения шумов.


Сервисный мониторинг, как в ServiceWatch глядели?


==================================
Весьма грустную картину описали.
Посмотрите сюда:"Introducing practical and robust anomaly detection in a time series" или сюда:"Anomaly Detection with Twitter in R", хотя бы.


И сюда: "Anomaly Detection Using Elasticsearch" тоже неплохо бы заглянуть.

Да, мы действительно описали кухню Одноклассников. Смотрите, в данном случаи нам не нужно детектить аномалии, нам нужно показывать тренды, а с этим хорошо справляется линейный прогноз. Да, это может выглядеть очень примитивно, но в данном случае нет смысла применять какой-то суперсложный алгоритм.

То, что вы советуете, у нас работает в другом месте — на оперативном мониторинге бизнес-логики портала (как будет время напишу про эту систему), там происходит анализ около 100 000 графиков в режиме реального времени.

т.е. вы говорите об автоматизации части процесса "Capacity Management"
Линейный прогноз, конечно, можно использовать на линейном участке, но осторожно.


В целом ИТ система нелинейна, а ряд ресурсов имеет ограничение сверху. При нагрузке выше среднего линейные прогнозы могут очень сильно подвести бизнес.


Упомянутая вторая часть про оперативный мониторинг гораздо интереснее с точки зрения сложности решаемой задачи. Было бы очень хорошо, если у Вас найдется время опубликовать.

Для абстрактной ИТ системы — возможно. Думаю тут сильно зависит от того, насколько линейно масштабируется система. В случае ок.ру — вполне себе линейно, поэтому линейного прогноза в принципе хватает.
Конечно, и такую систему можно довести нагрузкой до нелинейного деградирования, но этот самый описанный в статье capacity planning и призван своевременно увеличивать мощности, чтобы удержать систему на номинальной нагрузке и, как следствие, линейном участке. Собсно поэтому линейного прогноза вполне хватает.

Работать с загрузкой проца 20-40% ничего интересного. Когда деньги не считают, то можно накупать серверов пока электричества хватит. Когда деньги экономят, то пытаются повысить утилизацию существующего оборудования. И тут как раз и надо красиво выходить в приграничную и граничную области.

ок вполне считают деньги. Поэтому красотой приграничных областей и с интересом тратить время на сомнительную экономию при эксплуатации системы на режиме без запаса мощности — не занимаемся. Такой подход чреват потерей гораздо большего количества денег изза отказов, вызванных флюктуациями поведения пользователей и партнеров. Для нас более важна отказоустойчивость всей системы и ее доступность, чем экономия десятка серверов.

Все таки практика эксплуатации вполне предсказуемых расчетных задач и большой социальной сети, работающей с реальными людьми — разные вещи.

Над повышением утилизации тоже работаем, но естественно не так. Но это тема отдельной статьи.

тут сильно зависит от архитектуры. речь же не о двух серверах, а о > 10 тыс.
если у вас есть хорошие исторические данные, которые содержат и "флуктуации", грамотный механизм прогнозирования и механизм динамической балансировки, то на время ожидаемого всплеска вы можете ввести в экспуатацию +N виртуальных машин, а потом их загасить вместе с физическими. И нет никаких проблем. А в нормальное время повышать утилизацию активных машин.


Уже не раз сталкивался, когда возможности по расширению упирались в киловатты, которые физически можно подвести к ЦОД\зданию. Особенно в контуре Москвы.


а большой размер социальной сети как раз является плюсом, поскольку обеспечивает сглаживание флуктуаций. если только не будет флеш-моба какого.

вам, простите, слово latency знакомо? Вы знаете, что происходит с latency современных серверов при попытке нагрузить машину на 50% и выше?

Да ничего :) Знакомо и не это слово. И закон Амдала и закон Литтла и теория очередей и Марковские процессы и имитационное моделирование и прочее...


Например, у нас были машины, которые постоянно работали на 90% загрузке, таков был стационарный режим конвертации CDR/xDR. И много других кейсов.
Но поскольку ответ с сутевой части перешёл на личности, то дальше можно не продолжать. Ну сделали, ну устраивает, ну не волнуют заданные вопросы — имеете полное право.


Я видел другие решения, более интересные. Что-то реализовывали в проектах.


Поэтому и спросил. Как я сразу отметил, все сильно зависит от задачи и архитектуры решения.

Можно, например, поглядеть OSSblog Netflix. Красивую штуку собрали на опенсорсе. А ещё работы одного из идеологов — Brendan Gregg

Тот факт, что чьи-то машины работали на 90% нагрузки, ИМХО, говорит о том, что машин нужно было докупить. Или софт дооптимизировать. В общем, сделать что-нибудь, чтобы их разгрузить. Потому что 90% — это не норма, а хождение по тонкому льду.

Человека, который говорит, что 90% (80%, 70% загрузки машины) для распределенной отказоустойчивой системы — это норма, я бы выгнал ссаными тряпками за некомпетентность и фундаментальное непонимание проблемы.

Алексей, к чему так близко воспринимать альтернативные мнения, читать между строчек и терять человеческое лицо? Реальные ситуации гораздо многообразнее чем жесткий набор правил и догм.


Я полагал, что публикация на хабре является приглашением к дискуссии, а не площадкой корпоративного тщеславия. Формулировку про распределенную отказоустойчивую систему Вы уже сами додумали.


Тем не менее, чтобы не осталось непонимания.


  1. Как я неоднократно приписывал, особенности конкретного решения зависят от исходной бизнес-задачи, архитектуры и используемых инструментов. В разных случаях возможны разные режимы функционирования.


  2. В упомянутом мной кейсе про "90%" мы грамотно проанализировали бизнес задачу и допустимые режимы функционирования подсистемы, создали мат.модель, определили допустимые параметры и разработали подсистему конкретно под задачу конвертации CDR. Было это еще а ~2006-7 годах. В итоге, вместо закупки HP Superdome обошлись двумя SunFire 210 (или 240, точно уже не помню, давно было) в режиме Hot-Standy. Моментальный профит в разнице цен на железо! Ну и аптайм нашей подсистемы порядка 5 лет всех полностью устроил. Никого при этом нагрузка системы на 90% не беспокоила, все было промоделировано и рассчитано.


  3. Например, в классе вычислительных задач, недозагрузка отдельного сервера в распределенной отказоустойчивой системы является злом. Есть поток данных, есть распределенные вычислители. При больших N вместо N серверов, работающих на 20% правильно использовать N/4 работающих на 100% + в резерве +1(+2, +3, +N/10) дополнительных вычислителей, готовых принять поток данных на обработку по мере необходимости. А еще и GPU при этом неплохо бы загрузить, чего зря стоять. Умный балансировщик гоняет задания исходя из состояния вычислителей, а не карусельным принципом. Но это уже вопросы архитектуры. Износ оборудования, обогрев воздуха, затраты на электричество — на круг получается совсем не копейка.


  4. Хорошо, когда маржа в 100-300% позволяет покрывать любую неэффективность. Однако, переход к марже в 12-15% заставляет владельцев резко задуматься об оптимизации. Туалетную бумагу начинают под расписку выдавать. Мы все видим, что сейчас происходит на рынке и долгосрочные прогнозы не предсказывают возврата к прошлой модели потребления.


  5. "ИМХО" не подразумевает воинственной риторики. В переводе это означает in my humble opinion «по моему скромному мнению». Скромному человеку всегда интересно посмотреть опыт коллег, решающих масштабные задачи. Я не просто так упомянул NetFlix, Twitter, Facebook. Они вряд ли меньше ОК по своим масштабам, но делают очень интересные и красивые вещи, более того, делятся этим в открытую.


==========================================
Всем, кто интересуется вопросами производительности таких масштабных систем я бы посоветовал, кроме классической математики, почитать блог и книги Brendann Gregg. Труд, заслуживающий внимания и уважения:



А еще можно почитать и поиспользовать:


Я ни в коем случае не хотел вас оскорбить или задеть. Если вам мои слова показались не уместными — я приношу свои извинения.

Судя по всему, мы с вами говорим о совершенно разных продуктах и совершенно разных требованиях. Я с вами не знаком и поэтому ничего не могу сказать о вашей компетенции. И ни в коем случае ее не оцениваю.

Одноклассники, как я писал выше, — постоянно растущая система: нагрузка на сервера постоянно растет, трафик растет, количество сервисов растет. Насколько я понимаю, сервисы проектируются с тем расчетом, чтобы в час пик нагрузка на машины не превышала 60% (тут мои данные могли устареть — я давно парней не спрашивал про цифры). Соответственно, не-в-часы-пик нагрузка будет сильно ниже. В эти моменты можно проводить эксперименты, гонять тесты и утилизировать машины всяким другим полезным образом.

Учитывая постоянный рост многих подсистем, пиковая загрузка в 60% дает приемлемое время отклика и некоторый запас по железу.

За ссылки спасибо — кое-что из этого я читал или читаю, большинство — новые для меня вещи. Надеюсь, к новому году будет время что-то из вашего списка прочитать.
1. Хайлоад в его истинном смысле, как говорят сами участники той же конференции Highload++ — это для нищебродов.
2. Ну и куда вы лезете без ваших же пунктов 1 и 2 к ребятам, без анализа, расчета и всего такого, не зная реальную маржу и сколько от нее выходит стоимость железа, и тд и тп?
«Понимаю, звучит реально странно, но началось это с нескольких машин, и потом как-то неожиданно доросло до 5000 инстансов.»

Да что вы, ничего странного. У вас, походу, всё так. Мы привыкли.
а что вы имеете в виду?
Имею ввиду организацию рабочего процесса в мылору.
Представьте себе, что вы запускаете некоторый проект. Например, социальную сеть 10 лет назад. Этот проект начинает экспоненциально расти по количеству пользователей, а значит, и по нагрузке. Узким местом становится то одна подсистема, то вторая, то третья. Параллельно с этим вводятся в эксплуатацию новые и новые сервисы. Инструментов толком никаких нет (на дворе 2006ой год, напоминаю).

И вы утверждаете, что Мэйл.Ру (Одноклассники, Яндекс, LinkedIn, MySpace, Facebook, да кто угодно) некомпетентны в этой ситуации? Ахахаха!
Нет, я утверждаю, что все продукты, созданные внутри mail.ru (это важное уточнение, я не имею ввиду продукты, которые мылору купили), в своём бэкграунде традиционно имеют форменный бардак, что подтверждалось десятками историй от самих мылору, личных свидетельств непосредственных участников и вообще отношением мылору к собственным пользователям. Более того, на фоне конкурентов, продукты от мылору долгое время проигрывали по многим показателям, а по некоторым проигрывают до сих.

И да, я понимаю что ОК создавались вроде как не в мылору, но вписались они сюда весьма удачно, а так как запись находится в корпоративном блоге мылору, я и написал что мы тут к подобному подходу привыкли. Думаю мой первый комментарий был неверно истолкован.
Я не очень понял, что вы имеете в виду. Да, какие-то продукты проигрывают конкурентам Mail.Ru по одним показателям, а какие-то — выигрывают у конкурентов по другим показателям. Одни продукты растут, другие — наоборот падают. У Mail.Ru огромный портфель продуктов и направлений, так что это совершенно нормально. Это называется «деверсификация бизнеса».

При чем тут «форменный бардак»? Как это связано с постом? Зачем вы это все тут написали? :)
«Зачем вы это все тут написали?»

Вы знаете я вам могу ровно тот же вопрос задать. Специально для вас, повторим всё по шагам. В посту написали вот это:
«Понимаю, звучит реально странно, но началось это с нескольких машин, и потом как-то неожиданно доросло до 5000 инстансов.»

Я на эту фразу ответил, хотя возможно чуть перегнул с сарказмом. Однако комментарии существуют для того чтобы задавать вопросы и выражать своё мнение. Я думаю очевидно, что я выразил своё (и не только) мнение. Далее вам почему-то стало непонятно, что именно я имею ввиду. Я вам разжевал.

Не надеюсь, что вы в состоянии воспринять чужой взгляд на ситуацию, думаю на этом диалог можно закончить. Спасибо.

А как вы отслеживаете метрики java приложений? Они часто специфичны для приложения и их много.

Only those users with full accounts are able to leave comments. Log in, please.