Комментарии 55
upd: нашел ниже, спасибо mihver1
Хотя Zabbix у нас используется для оперативного мониторинга, причем на срабатывания какого-либо триггера автоматически создаётся инцидент в JIRA.
Исходя из своего опыта общения с софтом IBM могу сказать, что время вы точно зря не потратите.
Просто у вас уже вырос из разряда «детских» и «юношеских», а инструменты решения задач остались на уровне стартаперских и самописных.
В целом, интересная статья, спасибо.
- интерфейс выглядит ужасно. С локализацией — вообще ад
- написано чуть ли не в девяностых
- стоит как космический корабль
- саппорт у этого тула наверняка такой же адский, как и у всего остального IBM
- попытки что-то погуглить не выдают горы ответов, поэтому, подозреваю, что в эксплуатации будет много трудностей
Впрочем, это все домыслы — с этим тулом я не работал. А вообще хочется что-то не очень дорогое, свежее и с большим коммьюнити.
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 — стоит попробовать. ;)
Я не знаю откуда у вас негативная информация.
У меня совсем другие впечатления. Тикет вам конечно заведут — но фикса вы можете ждать много месяцев — и когда дождетесь, получите совсем не то, чего хотели.
1. Неконсистентность. Ядро сделано нормальными инженерами, но плагины и отдельные фичи часто пишут на коленке где-то в Индии.
2. Любой продукт это «вещь в себе» и требует бородатого админа для обслуживания. Особенно забавно смотрятся вакансии интеграторов, где в требованиях перечисляют несколько малосвязанных продуктов или просто Tivoli.
3. Несмотря на формальное наличие всех нужных фичей, их реализация зачастую уступает конкурентам.
4. Отсутствует сообщество и мало информации в доступном виде. Есть курсы, но именно на них попался лектор с нулевой практикой, пересказывавший учебник вперемешку с рекламным булщитом.
А плюс IBM в неплохой поддержке,
Насчет ваших домыслов, то с какими-то из них соглашусь (продуктом пользовался). А насчет желания это да, всегда хочется дешево, быстро и качественно.
* Интерфейс и локализация, по сравнению с версией статьи 2013 года стала получше.
Я может сужу со своей колокольни, но читая переводы статей на сайте IBM, понимаешь что работали над ними, именно работали, а не гугл транслейт.
* То что написано чуть ли в не 90-ых есть свои плюсы, в статье более подробно.
* Горы ответов и вправду нет, всю документация только на сайте ibm, и не так такого сообщества как у Zabbix.
Спасибо за интересную статью, тема мониторинга думаю всегда будет интересна.
Графана удобна тем, что у нас дежурные сидят и глазами в графики глядят — отклонения и странные тенденции видят лучше всяких анализаторов.
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-сервера максимум. В масштабах основной инфраструктуры — капля в море.
Вы правду про кухню одноклассников написали?
Жесткие пороги и линейный прогноз — это из 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 виртуальных машин, а потом их загасить вместе с физическими. И нет никаких проблем. А в нормальное время повышать утилизацию активных машин.
Уже не раз сталкивался, когда возможности по расширению упирались в киловатты, которые физически можно подвести к ЦОД\зданию. Особенно в контуре Москвы.
а большой размер социальной сети как раз является плюсом, поскольку обеспечивает сглаживание флуктуаций. если только не будет флеш-моба какого.
Да ничего :) Знакомо и не это слово. И закон Амдала и закон Литтла и теория очередей и Марковские процессы и имитационное моделирование и прочее...
Например, у нас были машины, которые постоянно работали на 90% загрузке, таков был стационарный режим конвертации CDR/xDR. И много других кейсов.
Но поскольку ответ с сутевой части перешёл на личности, то дальше можно не продолжать. Ну сделали, ну устраивает, ну не волнуют заданные вопросы — имеете полное право.
Я видел другие решения, более интересные. Что-то реализовывали в проектах.
Поэтому и спросил. Как я сразу отметил, все сильно зависит от задачи и архитектуры решения.
Можно, например, поглядеть OSSblog Netflix. Красивую штуку собрали на опенсорсе. А ещё работы одного из идеологов — Brendan Gregg
Человека, который говорит, что 90% (80%, 70% загрузки машины) для распределенной отказоустойчивой системы — это норма, я бы выгнал ссаными тряпками за некомпетентность и фундаментальное непонимание проблемы.
Алексей, к чему так близко воспринимать альтернативные мнения, читать между строчек и терять человеческое лицо? Реальные ситуации гораздо многообразнее чем жесткий набор правил и догм.
Я полагал, что публикация на хабре является приглашением к дискуссии, а не площадкой корпоративного тщеславия. Формулировку про распределенную отказоустойчивую систему Вы уже сами додумали.
Тем не менее, чтобы не осталось непонимания.
Как я неоднократно приписывал, особенности конкретного решения зависят от исходной бизнес-задачи, архитектуры и используемых инструментов. В разных случаях возможны разные режимы функционирования.
В упомянутом мной кейсе про "90%" мы грамотно проанализировали бизнес задачу и допустимые режимы функционирования подсистемы, создали мат.модель, определили допустимые параметры и разработали подсистему конкретно под задачу конвертации CDR. Было это еще а ~2006-7 годах. В итоге, вместо закупки HP Superdome обошлись двумя SunFire 210 (или 240, точно уже не помню, давно было) в режиме Hot-Standy. Моментальный профит в разнице цен на железо! Ну и аптайм нашей подсистемы порядка 5 лет всех полностью устроил. Никого при этом нагрузка системы на 90% не беспокоила, все было промоделировано и рассчитано.
Например, в классе вычислительных задач, недозагрузка отдельного сервера в распределенной отказоустойчивой системы является злом. Есть поток данных, есть распределенные вычислители. При больших N вместо N серверов, работающих на 20% правильно использовать N/4 работающих на 100% + в резерве +1(+2, +3, +N/10) дополнительных вычислителей, готовых принять поток данных на обработку по мере необходимости. А еще и GPU при этом неплохо бы загрузить, чего зря стоять. Умный балансировщик гоняет задания исходя из состояния вычислителей, а не карусельным принципом. Но это уже вопросы архитектуры. Износ оборудования, обогрев воздуха, затраты на электричество — на круг получается совсем не копейка.
Хорошо, когда маржа в 100-300% позволяет покрывать любую неэффективность. Однако, переход к марже в 12-15% заставляет владельцев резко задуматься об оптимизации. Туалетную бумагу начинают под расписку выдавать. Мы все видим, что сейчас происходит на рынке и долгосрочные прогнозы не предсказывают возврата к прошлой модели потребления.
- "ИМХО" не подразумевает воинственной риторики. В переводе это означает in my humble opinion «по моему скромному мнению». Скромному человеку всегда интересно посмотреть опыт коллег, решающих масштабные задачи. Я не просто так упомянул NetFlix, Twitter, Facebook. Они вряд ли меньше ОК по своим масштабам, но делают очень интересные и красивые вещи, более того, делятся этим в открытую.
- The Netflix Tech Blog, в частности, по мониторингу взглянуть сюда:
- Facebook Engineering Blog
- The Twitter Engineering Blog
==========================================
Всем, кто интересуется вопросами производительности таких масштабных систем я бы посоветовал, кроме классической математики, почитать блог и книги Brendann Gregg. Труд, заслуживающий внимания и уважения:
- Brendan D. Gregg blog
- Книга Systems Performance: Enterprise and the Cloud
- Книга Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris
- Книга DTrace: Dynamic Tracing in Oracle Solaris, Mac OS X and FreeBSD
А еще можно почитать и поиспользовать:
Судя по всему, мы с вами говорим о совершенно разных продуктах и совершенно разных требованиях. Я с вами не знаком и поэтому ничего не могу сказать о вашей компетенции. И ни в коем случае ее не оцениваю.
Одноклассники, как я писал выше, — постоянно растущая система: нагрузка на сервера постоянно растет, трафик растет, количество сервисов растет. Насколько я понимаю, сервисы проектируются с тем расчетом, чтобы в час пик нагрузка на машины не превышала 60% (тут мои данные могли устареть — я давно парней не спрашивал про цифры). Соответственно, не-в-часы-пик нагрузка будет сильно ниже. В эти моменты можно проводить эксперименты, гонять тесты и утилизировать машины всяким другим полезным образом.
Учитывая постоянный рост многих подсистем, пиковая загрузка в 60% дает приемлемое время отклика и некоторый запас по железу.
За ссылки спасибо — кое-что из этого я читал или читаю, большинство — новые для меня вещи. Надеюсь, к новому году будет время что-то из вашего списка прочитать.
2. Ну и куда вы лезете без ваших же пунктов 1 и 2 к ребятам, без анализа, расчета и всего такого, не зная реальную маржу и сколько от нее выходит стоимость железа, и тд и тп?
Да что вы, ничего странного. У вас, походу, всё так. Мы привыкли.
И вы утверждаете, что Мэйл.Ру (Одноклассники, Яндекс, LinkedIn, MySpace, Facebook, да кто угодно) некомпетентны в этой ситуации? Ахахаха!
И да, я понимаю что ОК создавались вроде как не в мылору, но вписались они сюда весьма удачно, а так как запись находится в корпоративном блоге мылору, я и написал что мы тут к подобному подходу привыкли. Думаю мой первый комментарий был неверно истолкован.
При чем тут «форменный бардак»? Как это связано с постом? Зачем вы это все тут написали? :)
«Зачем вы это все тут написали?»
Вы знаете я вам могу ровно тот же вопрос задать. Специально для вас, повторим всё по шагам. В посту написали вот это:
«Понимаю, звучит реально странно, но началось это с нескольких машин, и потом как-то неожиданно доросло до 5000 инстансов.»
Я на эту фразу ответил, хотя возможно чуть перегнул с сарказмом. Однако комментарии существуют для того чтобы задавать вопросы и выражать своё мнение. Я думаю очевидно, что я выразил своё (и не только) мнение. Далее вам почему-то стало непонятно, что именно я имею ввиду. Я вам разжевал.
Не надеюсь, что вы в состоянии воспринять чужой взгляд на ситуацию, думаю на этом диалог можно закончить. Спасибо.
А как вы отслеживаете метрики java приложений? Они часто специфичны для приложения и их много.
Что случилось, когда мы устали смотреть на графики 5 000 серверов в мониторинге (и когда серверов стало более 10 000)