Получил моральное удовлетворение от вашей публикации. Вы описали весь мой путь от и до. За исключением того:
через панику и ошибки последний тест я продебажил самостоятельно за 63 подхода.
на мои два письма о проблемах контеста мне никто не ответил
Полученный опыт заключается в большем скептицизме относительно подобных мероприятий. И да, времени жаль.
Собеседование было, на уровне пары общих вопросов. Отписка что вы не подходите тоже была.
В общем случае этот вопрос решили на уровне сервиса конфигурации параметром «частота сообщений». Устанавливается для каждой конкретной настройки уведомлений и есть дефолтное значение для всех.
Если говорить о конкретной реализации в VMmanager (уведомлять о пороговых значениях виртуальных машин и нод) в настройках есть следующие поля:
— значение ресурса (о превышении которого нужно сообщать)
— интервал (время в течении которого держится превышение)
— частота сообщений
Т.е. при CPU 80% peak 120s frequency 300s При условии что CPU зашкаливает постоянно первое письмо мы получим через 2мин и затем каждые 5мин.
Соблюдение этой логики сейчас целиком возложено на конечный алерт. И если администратор при настройке уведомлений выставит все ограничения на минимум уведомления будут сыпаться с максимальной скоростью, при условии что они постоянно генерируются. Все упрется в очередь сервиса отправки сообщений. Возможно стоит предусмотреть дополнительный фильтр и группировку, например во враппере, группировать, отправлять пачками. Спасибо за мысль.
По первому пункту. Не совсем так. Под Notifier, на самом деле, находится redis stream (изначально был Consul KV, что не подходит под такие задачи). Факт нотификации записывается в него. Сам же Notifier просто отслеживает стрим, раз в Nsec `XRANGE stream prevID +` полученные обновления сопоставляет с подписками, которые пришли на ws и совпадения выкидывает в нужное соединение. Что касается горизонтального масштабирования, могу сказать, что в рамках одного продукта не так много событий, поэтому один redis + notifier прекрасно справляются. Но простор для маневров есть. Redis можно кластеризовать, а Notifier, как его клиент, можно размножить в любом количестве. Останется только решить вопрос распределения клиентов между копиями Notifier.
По второму вопросу не совсем понял, о чем идет речь.
Вы правы, whitelist одна из важных настроек в данном случае. Я добавлю это в статью.
Почему сразу этого не сделал?
В примере контейнер с grafana (порт наружу не пробрасывается) находится в сети gnet, куда имеют доступ только proxy и сервис авторизации. Это относительно безопасно, если считать что во внутренней сети легитимны любые запросы, а из вне в grafana можно попасть только через прокси.
У себя в проекте мы используем собственный сервис авторизации, где регистрируются и авторизовываются пользователи. В графане мы хотим авторизовывать только пользователей нашего сервиса. Реализовывать в нем поддержу OAuth было бы гораздо дороже, чем просто проверять наличие валидной сесси, с которой пришел пользователь. С LDAP думаю все еще сложнее.
Спасибо за фитбек, весь коммент я передал продуктологу.
От себя могу ответить:
— iso, по нашей статистике, не пользовались особой популярностью. 90% его использования это rescuecd. Этот функционал (режим восстановления для VM) мы реализовываем в данный момент.
— в сторону резервного копирования мы выкатили создание образов без остановки VM в предыдущем релизе. Сейчас продумываем механизм монетизации и лимитирования со стороны провайдера.
— про bonding видел появлялась задача, думаю его поддержка вопрос времени
— про токены, не понял, что именно имеется в виду
По поводу требований к железу, думаю, вы правы, в статье указывать не стоило. Но на самом деле на такой вопрос отвечать приходится частенько, именно поэтому ответ на него попал в статью. Над реализацией резервного копирования мы сейчас активно думаем, т.к. существует множество точек зрения на этот вопрос и нужно найти компромисс, который устроит всех. В том или ином виде резервное копирование точно появится. Появление FreeBSD и ISO не за горами. Относительно функциональности, хотелось бы не делать полную копию пятерки, где было достаточно фич, которые использовали 2-3 человека. Мы постарались взять лучшее от vm5 и сделать работу c этим более простой и приятной. Но та функциональность, которая действительно необходима пользователям vm6, будет добавлена.
Согласен с вами, это неоспоримые преимущества. Я донесу эти доводы до нашего продуктолога.
От себя же хочу заметить, что разница 40р в месяц не так существенна, для небольшой vm. Хотя с ростом потребляемых ресурсов эта разница увеличивается.
Один из провайдеров:
— 1cpu 1G mem 30G HDD OVZ 159p KVM 199p
— 6 cpu 6G mem 1200G HDD OVZ 844p KVM 1079p
Сейчас данный вопрос активно обсуждается. В целом текущая архитектура предполагает использование кластеров с различной виртуализацией. Я думаю рынок виртуальных услуг по большей части состоит из решений на основе qemu, что более гибко в плане разделения ресурсов и используемых ОС. Интересно ваше мнение, для каких целей сейчас предпочтительнее использовать OVZ?
Получил моральное удовлетворение от вашей публикации. Вы описали весь мой путь от и до. За исключением того:
Полученный опыт заключается в большем скептицизме относительно подобных мероприятий. И да, времени жаль.
Собеседование было, на уровне пары общих вопросов. Отписка что вы не подходите тоже была.
Если говорить о конкретной реализации в VMmanager (уведомлять о пороговых значениях виртуальных машин и нод) в настройках есть следующие поля:
— значение ресурса (о превышении которого нужно сообщать)
— интервал (время в течении которого держится превышение)
— частота сообщений
Т.е. при CPU 80% peak 120s frequency 300s При условии что CPU зашкаливает постоянно первое письмо мы получим через 2мин и затем каждые 5мин.
Соблюдение этой логики сейчас целиком возложено на конечный алерт. И если администратор при настройке уведомлений выставит все ограничения на минимум уведомления будут сыпаться с максимальной скоростью, при условии что они постоянно генерируются. Все упрется в очередь сервиса отправки сообщений. Возможно стоит предусмотреть дополнительный фильтр и группировку, например во враппере, группировать, отправлять пачками. Спасибо за мысль.
По второму вопросу не совсем понял, о чем идет речь.
Почему сразу этого не сделал?
В примере контейнер с grafana (порт наружу не пробрасывается) находится в сети gnet, куда имеют доступ только proxy и сервис авторизации. Это относительно безопасно, если считать что во внутренней сети легитимны любые запросы, а из вне в grafana можно попасть только через прокси.
От себя могу ответить:
— iso, по нашей статистике, не пользовались особой популярностью. 90% его использования это rescuecd. Этот функционал (режим восстановления для VM) мы реализовываем в данный момент.
— в сторону резервного копирования мы выкатили создание образов без остановки VM в предыдущем релизе. Сейчас продумываем механизм монетизации и лимитирования со стороны провайдера.
— про bonding видел появлялась задача, думаю его поддержка вопрос времени
— про токены, не понял, что именно имеется в виду
От себя же хочу заметить, что разница 40р в месяц не так существенна, для небольшой vm. Хотя с ростом потребляемых ресурсов эта разница увеличивается.
Один из провайдеров:
— 1cpu 1G mem 30G HDD OVZ 159p KVM 199p
— 6 cpu 6G mem 1200G HDD OVZ 844p KVM 1079p