Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Пролог

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

В нашей стране никто не застрахован от «кидалова» партнером по договору: заказчики не платят фрилансерам, соучредители выходят из проекта, а поставщики отказываются от выполнения контрактов. Хорошие закупщики за то и ценятся, что имеют хорошие базы и связи в налоговой и могут неофициально проверить любого контрагента. К счастью, непрозрачный российский рынок в последние годы проясняется: появилось сразу несколько бесплатных государственных сервисов для проверки контрагента на честность. О них и пойдет речь в статье.

На сегодняшний день процедура реализации «failover» в Postgresql является одной из самых простых и интуитивно понятных. Для ее реализации необходимо определиться со сценариями файловера — это залог успешной работы кластера, протестировать его работу. В двух словах — настраивается репликация, чаще всего асинхронная, и в случае отказа текущего мастера, другая нода(standby) становится текущем «мастером», другие ноды standby начинают следовать за новым мастером.

На сегодняшний день repmgr поддерживает сценарий автоматического Failover — autofailover, что позволяет поддерживать кластер в рабочем состоянии после выхода из строя ноды-мастера без мгновенного вмешательства сотрудника, что немаловажно, так как не происходит большого падения UPTIME. Для уведомлений используем telegram.

Появилась необходимость в связи с развитием внутренних сервисов реализовать систему хранения БД на Postgresql + репликация + балансировка + failover(отказоустойчивость). Как всегда в интернете вроде бы что то и есть, но всё оно устаревшее или на практике не реализуемое в том виде, в котором оно представлено. Было решено представить данное решение, чтобы в будущем у специалистов, решивших реализовать подобную схему было представление как это делается, и чтобы новичкам было легко это реализовать следуя данной инструкции. Постарались описать все как можно подробней, вникнуть во все нюансы и особенности.

Больше года я занимаю должность технического лидера в своей компании, и хочется поделиться наработками по теме. Имеет смысл уточнить: я веду отдел iOS-разработки из 10 человек в компании-аутсорсере. В моём случае должность подразумевает оптимизацию работы отдела, распределение задач между разработчиками и активности, связанные с программированием. Расскажу немного о своём опыте, наработках и умозаключениях. Статья может быть полезна прежде всего новичкам на аналогичной должности, либо тем, кто на неё метит. Какие-то практики и принципы могут быть переносимы на обычную разработку, на другие платформы или даже другие специальности.

В одном строительном гипермаркете есть 18 касс, и надо уметь делать так, чтобы кассиры открывали их вовремя, чтобы очередь не была больше 4 человек. Ну, и чтобы лишние кассы не простаивали открытыми. Это распознавание людей (подсчёт покупателей) с видео, аналитика по погоде и другим факторам и предсказание потока. Плюс много другой забавной статистики.


Пример очереди перед кассой — картинка обрезанная и замыленная по просьбе безопасников, по факту очередь мы видим длиннее, чем на фото.

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

Да, и тем, кто переживал за кота-терминатора из прошлого поста — его поймали. Детали в конце.

Антон Турецкий (Badoo)

Сегодня я приглашу вас на такую внутреннюю кухню Badoo расскажу о том, нужен ли Docker нам. Вы попробуете сделать выводы для себя, нужен ли он вам. Этой информации на просторах Интернета, соответственно, нет, потому что она вся вот такая – в нашем тесном узком кругу.



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

Для себя мы на эти вопросы ответили, без проблем у нас не было бы никакого внедрения. Какую-то часть проблем мы решаем. Я выделил основные из них, я расскажу вам о них и о том, как мы с ними справились. В конце я порекламирую нас, какие мы замечательные, как мы любим всякие-разные новые велосипеды, как мы их делаем, смотрим, изобретаем. Я вам их покажу, про них расскажу, вы составите какое-то свое мнение. Итак, поехали!

Даниил Подольский (Git in Sky)

Доклад мой называется «Бинарные, они же файловые, хранилища», но, на самом деле, мы имеем дело со страшной сказкой. Проблема в том (и это тезис моего доклада), что сейчас не существует не то что хорошей, а хотя бы приемлемой системы хранения файлов.

Что такое файл? Файл – это кусок данных с именем. Что важно? Почему файл – это не строка в базе данных?

Файл слишком большой, чтоб можно было обращаться с ним как с одним куском. Почему? Есть у вас сервис, раз у нас HighLoad конференция, у вас сервис, который держит одновременно 100 тыс. соединений. Это не так уж много, если по каждому из соединений мы отдаем файл в 1 Мбайт размером, но нам нужно примерно 100 Гбайт памяти для буферов под эти файлы.

В преддверии конференции HolyJS мы поговорили с Максом Штойбером (одним из организаторов React.js Vienna Meetup, создателем react-boilerplate, принимавшим участие и в создании Carte Blanche) и Сергеем Лапиным (членом программного комитета HolyJS) и обсудили, как выбрать state management решение.

Redux, MobX, Relay или другая реализация Flux? Практические рекомендации и лучшие практики.

Макс Штойбер

– Макс, привет! Для начала коротко представься и расскажи о себе.

– Привет! Меня зовут Макс Штойбер, я Open Source разработчик, работаю в компании Thinkmill. Мы делаем всякие прикольные штуки вроде KeystoneJS, разрабатываем веб- и мобильные приложения, вносим свой вклад в улучшение User Experience.

– Звучит круто! Расскажи, как давно ты всем этим занимаешься, когда открыл для себя React, и в каких проектах участвовал?

Константин Осипов ( kostja ), Алексей Рыбак ( fisher )

Константин Осипов: Доклад родился из следующего разговора. Я, как всегда, пытался убедить Алексея больше использовать Tarantool, а он сказал, что там до сих пор нет шардинга и, вообще, неинтересно. Тогда мы стали рассуждать о том, почему нет. Я стал рассказывать, что тут нет одного универсального решения, автоматика полная за вас работает, а вы только кофе на работе пьете и все…

Поэтому родился этот доклад — чтобы посмотреть на то, какой бывает шардинг, какие методы в каких системах используются, какие преимущества и недостатки, почему нельзя одной «серебряной пулей» все решить?

Помимо «чисел Joker 2016», перечисленных нами заранее, теперь можно назвать ещё одно: на конференции наши фотографы сделали более 5000 снимков. Неудивительно, что на обработку ушло ощутимое время, и на Хабре уже успел появиться отзыв глазами участника от dbelob — а теперь мы публикуем свой.

Резкие отличия Joker 2016 от предыдущих «Джокеров» бросались в глаза сразу. В чём они состояли, о чём рассказывали на конференции в этот раз, и какие доклады по зрительским оценкам оказались лучшими?

Год назад Google сваял платформу Cloud Vision API‎. Идея платформы — предоставить технологии Computer Vision, в которых Google является безусловным лидером, как сервис. Пару лет назад под каждую задачу существовала своя технология. Нельзя было взять что-то общее и добиться, чтобы алгоритм решал всё. Но Google замахнулся. Вот, прошёл уже год. А технология всё так же не на слуху. На хабре одна статья. Да и та ещё не про Cloud Vision api, а про Face api, которое было предшественником. Англоязычный интернет тоже не пестрит статьями. Разве что от самого Google. Это провал?



Мне было интересно посмотреть что это такое ещё весной. Но сил полноценно посидеть не хватало. Изредка что-то отдельное тестировал. Периодически приходили заказчики и спрашивали, почему нельзя применить Cloud Api. Приходилось отвечать. Или наоборот, отсылать с порога в этом направлении. И внезапно понял, что материала на статью уже достаточно. Поехали.

В последние два месяца лета в управлении хранилищ данных (Data Warehouse, DWH) Тинькофф Банка появилась новая тема для кухонных споров.

Всё это время мы проводили масштабное тестирование нескольких in-memory СУБД. Любой разговор с администраторами DWH в это время можно было начать с фразы «Ну как, кто лидирует?», и не прогадать. В ответ люди получали длинную и очень эмоциональную тираду о сложностях тестирования, премудростях общения с доселе неизвестными вендорами и недостатках отдельных испытуемых.

Подробности, результаты и некое подобие выводов из тестирования — под катом.

Олег Бартунов (zen), Александр Коротков (smagen), Федор Сигаев

Илья Космодемьянский: Сейчас будет самая животрепещущая тема по PostgreSQL. Все годы, что мы занимаемся консалтингом, первое, что спрашивают люди: «Как сделать мультимастер-репликацию, как добиться волшебства?». Много профессиональных волшебников будут рассказывать о том, как это сейчас хорошо и здорово реализовано в PostgreSQL — ребята из Postgres Professional в рамках этого доклада расскажут про кластер все. Название соответствующее — «Сага» — что-то эпическое и монументальное. Сейчас ребята из Postgres Professional начнут свою сагу, и это будет интересно и хорошо.

Итак, Олег Бартунов, Александр Коротков и Федор Сигаев.

Как-то раз я собирался в Грецию и решил узнать, будут ли с меня брать комиссию при оплате рублевой картой. Я не люблю звонить в банк, поэтому отправил свой вопрос на почту техподдержки. Через пару дней мне пришел вот такой ответ:



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

Давайте попробуем сделать лучше.

Целостность данных легко нарушить. Бывает так, что в поле price попадает значение 0 из-за ошибки в коде приложения (периодически всплывают новости, как в том или ином инет-магазине продавали товары по 0 долларов). Или бывает, что удалили юзера из таблицы, но какие-то данные о нем остались в других таблицах, и эти данные вылезли в каком-то интерфейсе.

PostgreSQL, как и любая другая СУБД, умеет делать некоторые проверки при вставке/изменении данных, и этим обязательно нужно уметь пользоваться. Давайте посмотрим, что мы можем проверять:

1. Кастомный подтип через ключевое слово DOMAIN

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Игорь Сысоев ( isysoev )

Меня зовут Игорь Сысоев, я автор nginx и сооснователь одноименной компании.

Мы продолжаем разработку open source. С момента основания компании темпы разработки существенно увеличились, поскольку над продуктом работает множество людей. В рамках open source мы оказываем платную поддержку.

Я буду говорить о масштабируемой конфигурации nginx, но это не о том, как обслужить с помощью nginx сотни тысяч одновременных соединений, потому что nginx для этого настраивать не надо. Нужно выставить адекватное число рабочих процессов или поставить его в режим «авто», поставить worker_connections в 100 000 соединений, после этого заниматься настройкой ядра — это гораздо более глобальная задача, чем просто настройка nginx. Поэтому я буду рассказывать о другой масштабируемости — о масштабируемости конфигурации nginx, т.е. о том, как обеспечить рост конфигурации от сотни строчек до нескольких тысяч и при этом тратить минимальное (желательно константное) время на сопровождение этой конфигурации.

Мне не нова магия Flexbox, но я не часто ее использую, и поэтому после паузы в использовании мне приходится открывать вот этот пост на CSS-Tricks чтобы освежить память.

Я решила создать краткую визуальную шпаргалку по Flexbox для тех случаев освежения памяти после паузы в будущем. Думаю, что у меня получилась шпаргалка, основанная на… шпаргалках.

Мы в Одноклассниках занимаемся поиском узких мест в инфраструктуре, состоящей более чем из 10 тысяч серверов. Когда мы слегка задолбались мониторить 5000 серверов вручную, нам понадобилось автоматизированное решение.

Точнее, не так. Когда в седой древности появился примерно 20-й сервер, стали использовать Big Brother — простейший мониторинг, который просто собирает статистику и показывает её в виде мелких картинок. Всё очень, очень просто. Ни приблизить, ни как-то ввести диапазоны допустимых изменений нельзя. Только смотреть картинки. Вот такие:


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

Поэтому мы сделали новую систему мониторинга — и сейчас на работу с 10 тысячами серверов тратим по 1-2 часа в неделю на обработку алертов. Расскажу, как это устроено.