Не соглашусь. «Подать руку помощи» предполагает активное участие и усилие, тогда как «отправить лифт вниз» практически не требует усилий и отправляющему особо не интересен результат. По моему, стоит переводить как есть и при необходимости сопроводить сноской.
А почему «печально известный»? Жил в своё удовольствие, деньгами не заморачивался, занимался любимым делом, путешествовал и славы особо не искал. Да и оставил не плохое наследие.
> Каких именно графиков вы добавите в дашборд?
Сводных графиков ключевых интерфейсов. А на дашборт пачку таких сводных графиков.
> Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов
При таком количестве картинки наблюдать не очень эффективно (по крайней мере у меня не получалось).
Лучше триггеров пораскидать с разными предельными значениями и уровнями угрозы.
А зачем именно такой экран, что на нём смотреть и зачем? (просто интересно).
Ну а заббиксом я, например, постоянно нагрузку не мониторю — достаточно триггеров с оповещением, если на каких-то интерфейсах нагрузка держится дольше заданного или меньше нужного.
А если хочется картинок, можно собрать сводный график или «дашборд» графиков, на которых будут нужные нагрузки на интерфейсах с потолком.
Конечно молодцы, что разобрались, но чего-то революционного и «креативного» нет — достаточно только внимательно почитать документацию и посмотреть логи.
У меня virtualbox точно так же в контейнере крутится.
И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.
Необходимо обрабатывать коды возврата вызываемых утилит.
А так же желательно слать отчёты о бекапах на почту, особенно, если что не так.
И полезно проверять размеры получившихся бекапов на адекватность.
* Необходимо добавить обработку кодов возврата иначе о том, что что-то пошло не так, узнаете внезапно.
* Желательно проверять размер получившегося бекапа на адекватность.
* Хорошо слать отчёт на почту, особенно если что-то не так.
* Можно добавить сжатие, лучше многопоточное, например через 7zip.
* А после этого добавить автоматическую очистку старых бекапов.
Для браузеров есть различные плагины, расширяющие возможности настроек прокси-серверов. Настраиваются прокси-сервера и в них заворачиваются только нужные домены.
Я дедубликацию через плагин throttle реализовывал.
Но в целом да, на более масштабных инсталляциях пожалуй будет удобнее использовать внешний независимый агрегатор.
Заказывал подобные игрушки на али, как раз в районе 5-ти баксов. Машинку, конструктор и тп. У них очень слабая солнечная батарея. Работает только на ярком свету, либо от лампы накаливания почти в притык. Поиграться можно, но и ожидается несколько другое.
При модуле split задаётся параметр по которому высчитывается хеш и от него разброс (например IP адрес). В таком раскладе, при правильных параметрах, клиента не должно кидать с сервера на сервер.
Но в нашем случае, этот вариант не был удобен, во первых из за параметров хеширования. А во вторых, из-за дальнейшей обработки сопоставленных переменных. Напрямую upstream не сопоставишь, нужно либо реврайт писать, либо на стороне бэкенда обрабатывать или ещё как.
А так получилась полная независимость от бэкенда и желаемое равномерное распределение, не зависимое от параметров клиента. Плюс к этому возможность в дальнейшем отфильтровать группы клиентов по каким-то признакам.
Затем, что контент на разных бэкендах разный, и если у пользователя в процессе работы вдруг поменяется форма странички, он несколько удивится. Реализовывался вариант A/B тестирования с настраиваемыми весами по разным критериям и запоминанием привязки.
Fonts for code from DJR & Font Bureau
Из-за мутации в X-хромосоме некоторые женщины различают в 100 раз больше цветов, чем обычные люди
Сводных графиков ключевых интерфейсов. А на дашборт пачку таких сводных графиков.
> Представьте, у вас 100+ аплинков от access-свитчей и 1000+ портов
При таком количестве картинки наблюдать не очень эффективно (по крайней мере у меня не получалось).
Лучше триггеров пораскидать с разными предельными значениями и уровнями угрозы.
А в целом — дело хозяйское, кому что удобнее.
Ну а заббиксом я, например, постоянно нагрузку не мониторю — достаточно триггеров с оповещением, если на каких-то интерфейсах нагрузка держится дольше заданного или меньше нужного.
А если хочется картинок, можно собрать сводный график или «дашборд» графиков, на которых будут нужные нагрузки на интерфейсах с потолком.
У меня virtualbox точно так же в контейнере крутится.
И не забудьте, что сперва все необходимые модули должны быть установлены и загружены в нулевом домене.
А так же желательно слать отчёты о бекапах на почту, особенно, если что не так.
И полезно проверять размеры получившихся бекапов на адекватность.
* Желательно проверять размер получившегося бекапа на адекватность.
* Хорошо слать отчёт на почту, особенно если что-то не так.
* Можно добавить сжатие, лучше многопоточное, например через 7zip.
* А после этого добавить автоматическую очистку старых бекапов.
И будет вполне себе велосипед.
Но в целом да, на более масштабных инсталляциях пожалуй будет удобнее использовать внешний независимый агрегатор.
;)
Но в нашем случае, этот вариант не был удобен, во первых из за параметров хеширования. А во вторых, из-за дальнейшей обработки сопоставленных переменных. Напрямую upstream не сопоставишь, нужно либо реврайт писать, либо на стороне бэкенда обрабатывать или ещё как.
А так получилась полная независимость от бэкенда и желаемое равномерное распределение, не зависимое от параметров клиента. Плюс к этому возможность в дальнейшем отфильтровать группы клиентов по каким-то признакам.