• InfluxDB, Prometheus, OpenTSDB. Что выбрать для хранения и анализа метрик?

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

    OpenTSDB:
    * работает поверх HBase/Hadoop, для тестов можно запустить в standalone режиме, но будет работать _крайне_ медленно
    * timeseries вида timestamp, metricname=val, (tag=val)+ , может хранить только числа (есть batch mode, если нужно несколько пачкой писать)
    * объем данных хорошо масштабируется за счет HBase
    * сообщество сообщает о тормозах при очень большом количестве (десятки тысяч+) идентификаторов серий -- это имя серии + сочетание тегов
    * скорость записи и выборки хорошая: в HBase данные партицируются почасово и читаются только те серии за те периоды, которые нужны
    * для масштабирования ставим доп.ноды OpenTSDB за прокси (если упираемся в агрегации), либо ноды HBase (если упираемся в IO)
    * процессинг метрик только самый базовый -- downsample, вычисление rate из счетчиков (т.е. производная), аггрегация по тегам (например, среднее "os.cpu" для всех метрик, у которых тег "role=webserver")
    * сам язык запросов немного вырвиглазный
    * недавно появился https://bosun.org/, который садится перед OpenTSDB и позволяет еще какие-то операции делать
    * апстрим разработку ведет довольно неторопливо

    InfluxDB:
    * ставится в тестовом режиме очень легко (один бинарник)
    * пока нестабилен -- за последний год сменилось 2 HTTP API и штук пять вариантов бинарного формата на диске -- это моя самая большая претензия к нему
    * timeseries вида db, timestamp, metricname=val, (tag=val)+, т.е. можно логически группировать разные данные. Кажется, можно было хранить текстовые значения.
    * язык запросов SQL-подобный
    * ребята из Coub говорили, что на запись он качает хорошо, а на чтение тормозит (не знаю, впрочем про какую из версий)
    * у них много коннекторов к разным входным форматам (графит, opentsdb, collectd и т.п.)
    * довольно динамично развивается

    Из известных TSDB есть еще Graphite:
    * старый хорошо известный вариант
    * питон с модулями, поэтому сложнее в установке, чем influxdb, но проще чем хадуп
    * база RRD, т.е. может хранить только данные "за последний год, за последний месяц и за последний час" со своей точностью для каждого периода
    * за счет этого данные занимают хорошо предсказуемое и постоянное место на диске
    * гигантское количество документации и всяких обвязок в интернете
    * серии вида timestamp, metric=val -- тегов и т.п. нет. поэтому группировать, например, одинаковые серии для разных хостов придется под разными именами
    * довольно большое (по сравнению с OpenTSDB) количество функций при выборке -- насколько помню, были всякие перцентили, forecastы и т.д.
    * с дефолтным хранилищем при большом количестве серий начинает упираться в диск
    * масштабируется неважно (подробностей не знаю)
    * периодически из сообщества появляются разнообразные хранилища, которые улучшают ситуацию со скоростью и масштабированием

    Prometheus не видел.
    Еще что-то слышал про druid.io, но тоже ничего о нем не знаю.
    Ответ написан
    1 комментарий
  • Какию реализации RPC и Message Bus стоит рассмотреть для микросервисной архитектуры?

    yellow79
    @yellow79
    Senior Software Engineer
    На мой взгляд у вас RabbitMQ является самым узким местом, мало того, что он сам по себе медленный, так он у вас ещё и избыточно перегружен. Необходимо максимально избавиться от него.

    Для выполнения удалённых процедур уже давно придуман RPC или более продвинутый его аналог GRPC, который гоняет данные в бинарном формате, что сокращает размеры запросов и увеличивает скорость передачи, что так же может пригодиться вам для реализации запроса за данными. Думается если вы первые два пункта уберёте, кролику станет значительно легче и возможно на этом можно будет остановиться, если нет, то возможно стоит отказаться от него в пользу Nats, посмотрите, он может вас сильно порадовать производительностью. Ну или можно посмотреть в сторону Redis, он так же превосходит кролика в реализации очередей и на мой взгляд отлично подходит для реализации событийно-ориентированной архитектуры.
    Ответ написан
    Комментировать
  • Как лучше организовать структуру сервера на aws с docker контейнерами?

    deksden
    @deksden
    Enterpreneur
    Имхо - для начала каждую сущность оборачиваем в контейнер, заставляем уметь работать или в единственном экземпляре, или в режиме нескольких инстансов. То есть, к API должен быть какой-то load balancer, веб сервер тоже с несколькими воркерами надо дружить, база тоже по мануалам масштабируется при появлении нескольких контейнеров.

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

    Как то так.
    Ответ написан
    Комментировать
  • Как windows администратору использовать на практике контейнеры?

    А то складывается ощущение, что все только и делают что деплоят приложения для смартфонов каждый день и работают в высокотехнологичных ИТ компаниях, типа гугла)
    Ты не поверишь, есть масса компаний, которые херачат их куда следует и в основном куда не следует совсем, объясняя это безопасностью, которую якобы даёт контейнер. Также это модный тренд, поэтому некоторые пичкают контейнеры куда не попадя, а потом рассказывают какое у них модное крутое и инновационное приложение, ибо докер.
    В W2016 довольно неплохо подошли к контейнерезации. Можно использовать по прямому назначению - микросервисы. Когда твоё монолитное приложение, разбивается на несколько микросервисов, выполняющих одну задачу.
    Ответ написан
    Комментировать
  • Как правильно сделать связку в Docker: php + cron?

    OrlovEvgenii
    @OrlovEvgenii
    golang developer / DevOps
    Никак.
    У тебя 2 контейнера, оба изолированы друг от друга. Соответственно php ничего не знает о контейнере cron и наоборот. Короче говоря - в контейнере cron просто нет установленого php.
    Через links ты просто на сетевом уровне привязываешь php контейнер к cron контейнеру, по сути это тоже самое что сделать в контейнере cron вот такую запись
    echo "php x.x.x.x" >> /etc/hosts
    разумеется с некоторыми нюансами.

    Что можно сделать.
    1. Забыть про идею крона внутри контейнера потому что это плохо.
    2. Если очень хочется, то собрать Dockerfile c php-cli, тогда все заработает.

    и еще пара советов по Dockerfile
    не делай много объявлений RUN без крайней необходимости, старайся записывать все инсталлы в строку с разделителем &&\.
    и делай образ на основе alpine
    Ответ написан
    3 комментария
  • Есть ли способ получить server_name внутри Docker контейнера?

    Kinozol
    @Kinozol
    Тёплый LAMPовый вебдев :)
    Прокси это как раз стандартное решение, как я понял, разбирался в соседнем топике.
    Для множества vhost используют проект nginx-proxy.
    Ответ написан
    Комментировать
  • Почему контейнер с MySQL не хочет подхватывать enviroment переменные из docker-compose.yml?

    Root пароль устанавливается только при "первом запуске" контейнера. Если файлы с данным mysql уже существуют (в вашем случае тут - "./database"), то эта переменная будет игнорироваться.

    Соответственно решением будет изменение пароля вручную либо удаление существующих файлов mysql (с последующим запуском контейнера с нужным вам паролем в MYSQL_ROOT_PASSWORD).

    Удаление контейнеров и образов бесполезно, т.к. директория с данными бд монтируется в контейнер с хост машины.
    Ответ написан
    1 комментарий
  • Как правильно следить за Docker?

    @rustler2000
    погромист сикраш
    Очевидно имеется ввиду docker restart policy https://docs.docker.com/engine/reference/run/#rest...
    или https://docs.docker.com/compose/compose-file/compo... если композер.
    Ну или вообще - https://kubernetes.io/docs/concepts/workloads/pods...
    Ответ написан
    Комментировать
  • Стоит ли использовать Docker на продакшене?

    @de1m
    У нас пять серверов в hetzner и несколько больших во внутреней сети, на них на всех крутяться контейнеры для разных вещей(mysql, mssql, bind, openvpn, etc). Начали со всем этим, где-то года три назад. Проблемы были, но небольшие и они уже исправлены, последние где-то месяцев 10 я ничего не вспомню.
    Если вы хотите CI/CD, то смотрите в сторону kubernetes. Его главный плюс, что можно всем управлять через API. Мы к этой идеи тоже пришли и я буквально неделю назад закончил установку kubernetes'а на трех серверах у hetzner и начал туда переводить наши сервисы.
    У докера я вижу два главных преимушества:
    1. Очень чёткое разделение между данными и системой. Выводишь нужные данные на volumes и делаешь с них бэкапы. Если сервер сгорел, заливаешь образы для docker'а и накатываешь данные и готово.
    2. Повторяемость окружения.
    Ответ написан
    1 комментарий
  • Инет на винде есть - на линухе нет... Магия?

    @liks
    Похоже на высокий MTU
    Подберите правильный MTU такой командой:
    ping -c 4 -M do -s 1500 ya.ru
    Вам нужно будет менять цифру "1500" на более низкие значения, пока не перестанет отображаться что-то вроде
    Frag needed and DF set
    или
    ping: local error: Message too long, mtu=1500

    и станут идти нормальные пинги, после чего зайдите в Ваш network-manager и впишите туда значение которое Вы подобрали

    вот значения, которые Вы должны перебирать по очереди, сверху вниз:
    Значения
    1500 The biggest-sized IP packet that can normally traverse the Internet without getting fragmented. Typical MTU for non-PPPoE, non-VPN connections.

    1492 The maximum MTU recommended for Internet PPPoE implementations.

    1472 The maximum ping data payload before fragmentation errors are received on non-PPPoE, non-VPN connections.

    1460 TCP Data size (MSS) when MTU is 1500 and not using PPPoE.

    1464 The maximum ping data payload before fragmentation errors are received when using a PPPoE-connected machine.

    1452 TCP Data size (MSS) when MTU is 1492 and using PPPoE.

    576 Typically recommended as the MTU for dial-up type applications, leaving 536 bytes of TCP data.

    48 The sum of IP, TCP and PPPoE headers.
    40 The sum of IP and TCP headers.
    28 The sum of IP and ICMP headers.
    Ответ написан
    3 комментария
  • Windows-сервер перезагружается из-за ошибки BugCheck, что делать?

    devspec
    @devspec Автор вопроса
    Помогло? Отметь решением
    В общем, это жесть какая-то...
    Сегодня получил левел-ап в администрировании Windows )
    Скачал Windows Drivers Kit, с помощью WinDbg и набора символов проанализировал последний дамп.
    Оказалось, что сервер падает из-за открытых портов SMB. Это какая-то новая уязвимость Windows, под которую по-моему еще даже обновление не вышло (или вышло, но мне не пришло). Закрыл порты и удалил SMB1 из набора компонентов Windows - полдня полёт нормальный.
    Подробнее, если кому нужно, можно почитать здесь или здесь. Ситуация довольно нетривиальная (лично для меня), поэтому решил здесь опубликовать результат её решения.
    Ответ написан
    2 комментария
  • Знания Junior php разработчика?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что должен знать идеальный джуниор (мое личное мнение):

    - Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
    - GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
    - Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
    - PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
    - Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
    - Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
    - Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
    - Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
    - Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
    - Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
    - Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
    - Уметь дебажить. xdebug, blackfire и тд.

    В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

    p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

    Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.
    Ответ написан
    12 комментариев
  • Готовые примеры приложений на Angular?

    mgvmax
    @mgvmax
    Хочу быть Senior Frontend Developer
    Очень много плохого и хорошего в Ангуляре всплывает при попытке создать полноценный сайт, например тот-же каталог фильмов (с переходами в магазин где продается этот фильм, со статьями, модальными окнами в виде всплывающей карточки фильма).
    При решении проблем с гуглАналитиксом и SEO, получение данных из api.
    OAuth, Авторизация и аутентификация, например если у пользователя протух access token, в таком случае при обращении к методу в api получаем ошибку, которую перехватим в интерцепторе, используя refresh token получим новый access token опять обратимся к методу в api получим ответ и подменим им предыдущий "ошибочный", и пользователь не расстроится.

    Реализуя все эти задачи все глубже и глубже погружаешься в ангуляр, а еще иногда долго ругаешься плохими словами:)
    Ответ написан
    1 комментарий
  • Как отправить сообщение к конкретным пользователям?

    Aliansys
    @Aliansys
    Из документации socket.io (отправка сообщений)
    // отправить текущему сокету сформировавшему запрос (туда откуда пришла)
    socket.emit('message', "this is a test");
    
    // отправить всем пользователям, включая отправителя
    io.sockets.emit('message', "this is a test");
    
    // отправить всем, кроме отправителя
    socket.broadcast.emit('message', "this is a test");
    
    // отправить всем клиентам в комнате (канале) 'game', кроме отправителя
    socket.broadcast.to('game').emit('message', 'nice game');
    
    // отправить всем клиентам в комнате (канале) 'game', включая отправителя
    io.sockets.in('game').emit('message', 'cool game');
    
    // отправить конкретному сокету, по socketid
    io.sockets.socket(socketid).emit('message', 'for your eyes only');
    Ответ написан
    19 комментариев