"Все смешалось, люди, кони" :). Почему между Graphite и logstash стоит _или_ ? Вроде как совсем разные шуки. Kibana и Sentry - разве можно как то из ES доставить в sentry нативным образом данные ? Да и зачем ?
Сергей Петриков Согласен, скорость скриптописания не сильно важна. Но мне кажется админам в будущем придется чуть больше кодить. Те же модули для puppet, если вы пишете собственных 'providers', требуют написания их на руби. Часто встречается инструментарий на том же гитхабе, который в сыром виде сложно применить, но можно интегрировать добавив некоторую прослойку. Со стороны начальства я не ощущаю недовольства скоростью реализации задач, это скорее требование к себе (недовольство собой если хотите), писать быстрее, проще, красивее, и так чтобы этим можно было делиться.
Сергей Петриков Мы с zabbix'ом дружим уже очень давно, но нет, не всегда решает, по крайней мере 2.2, до 2.4 не дойдут никак руки. То что я привел, стоит воспринимать не как отдельные требования а как комплексный набор условий. Я в курсе про эскалацию событий, и про сложные триггеры которые позволяют выявлять "тренды" по дням, и на основании этого делать оповещения или нет (избавление от срабатываний на регулярных спайках, но вылавление спайков выше обычных) и т д. Но заббикс много чего не умеет, наверняка же Вы радовались (как и я) когда позволили в 2.4 добавить на скрин прототип графика и сделали более человечным action condition ? Когда вам нужно для ряда триггеров, сделать специфичный шаблон оповещения, но при этом избежать дублирования алертов на почте, вам заббикс кажется очень удобным ? У кого то таких задач не стояло и они считали что заббикс подходит для всего.
И при этом, вы пытаетесь мне доказать что нет таких задач для которых еще нет инструмента ? Спорить не буду, хотя мне и кажется это слишком уж оптимистичным вариантом. Но так или иначе это не значит что всем может быть удобно использовать в данной инфраструктуре данный инструмент.
И изначальный вопрос не звучал как "мы пишем собственные костыли, как мне это делать быстрее", вы мне кажется это сами додумали, без обид :)
Доставка данных, обработка происходящих событий с сложными вариантами оповещений (изменение оповещний не просто от времени а от типа "триггеров", дней недели, частоты срабатывания, и "дестинейшона" оповещения, почта или смс к примеру), требует своих собственных костылей. Но это не что иное как автоматизация каких то действий, и это одна из первостепенных задач администраторов. Если все ездят на уницикле и говорят что им удобно, это не повод не изобретать мне мой собственный велосипед.
Не пойму чем помогут системы оркестровки когда нужен сбор данных из различных источников, их анализ и сведение для получение некоторой объективной информации о работе сервиса (к примеру). "Пороговый" мониторинг не всегда удобен.
На тему повторного использования кусков кода, абсолютно согласен это ускоряет написание, но я пока максиму 20-30% накидываю из готового.
На счет того что "неадминское это дело", пожалуй с Вами не соглашусь.
Привет кэп ! Именно про это я и написал, что есть некий "переходный" этап, когда задач становится больше, но еще недостаточно чтобы скилл начал прокачиваться.
Вячеслав Успенский как то Вы непостоянны, то у Вас "не может такого быть при продуманной архитектуре", то про "некристальные архитектуры" рассказываете.
Если "залить градиентом", это "способ", то можно много чего придумать :) Берем картинку, растягиваем по ширине, блюрим, поверх ложим исходное видео. Получаем приятный эффект. В ffmpeg не так сложно сделать такое :)
Вячеслав Успенский Это все прекрасно, но представлений этих может быть овер дохрена, и они могу диктоваться пользователями сервиса, а не Вами. Если это не очень динамичный продукт, с "релизным" подходом к разработке, то наверно с этим можно жить и все будет офигенно, во всех остальных случаях, мне кажется, будут трудности с таким подходом.
Причем здесь говнокод :) Есть уровень сырых данных, а есть уровень представления. Эти самые представления, необязательно реализовывать на уровне БД, есть замечательные быстрые кэши, которые позволяют это красиво организовать, и эффективно сжать при необходимости, сохранив скорость доступа.
Я просто подумал, если у вас города, то максмайндовские диапазоны будут не очень точными.
Но если они довольно точны, то конечно же проще geo заменить на geoip
geoip_city GeoCity.dat;
А в map вместо $country использовать $geoip_city, и соответсвующие названия городов из базы maxmind
Для этого вам нужен media server. Если говорить про rtmp то простым и работающим решением может выступить nginx с rtmp модулем - https://github.com/arut/nginx-rtmp-module.
Сами использовали в продакшене для ретрансляции потоков, довольны. Также в нескольких небольших проектах использовали для доставки контента конечному пользователю. На leaseweb дедике за 400$ выжимали 10гбит (2-5 парарлельно идущих популярных спортивных трансляций), с потоками по 2 МБита.
В чем проблема то ? Я никак не пойму. Поставить репы по зависимостям, зависимые пакетики, скачать тар , распаковать, уложить куда надо, насттроить nginx / fpm / mysql посаздовать пользователей, разместить конфиги CMS из шаблонов. запустить инсталятор CMS подсунув ему весь нужный ей конфиг. Каждый этап проверять на успешность.
yanchumak: а в чем сложности с отправлением по UDP ? Точно также и отправляете. Транспорт у Вас в обоих случаях IP, просто в ip пакет укладываете UDP и ставите в ip пакете в поле протокола UDP.
И при игре с ПАММ'ами лучше не вкладывать в одного управляющего, а составлять портфель из десятка. Этим можно существенно снизить риск, но и прибыль конечно.
Опять же, если следить за работой управляющих, можно эффективно скальпить, и свести до минимума потери на их просадках. Но это потребует серьезных затрат времени.
