Сергей Петриков Согласен, скорость скриптописания не сильно важна. Но мне кажется админам в будущем придется чуть больше кодить. Те же модули для 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.
И при игре с ПАММ'ами лучше не вкладывать в одного управляющего, а составлять портфель из десятка. Этим можно существенно снизить риск, но и прибыль конечно.
Опять же, если следить за работой управляющих, можно эффективно скальпить, и свести до минимума потери на их просадках. Но это потребует серьезных затрат времени.
Как сказали выше можно сделать другое имя пакета. Или использовать пиннинг при помощи модуля apt.
При добавлении репозитория при помощи apt::source указать приоритет для каждого.
