Спасибо за интересный вопрос. Основной смысл в том, что хостинг-провайдеру нужно мониторить корректность конфигурации nginx. Иначе он может столкнуться с ситуацией:
— из-за ошибки в коде или из-за ручного вмешательства создаётся невалидная конфигурация nginx;
— пользователи пытаются создать сайт / привязать новый домен к сайту / сменить версию PHP на сайте и у них ничего не получается. Потому что nginx не загружает новую конфигурацию;
— пользователи звонят / пишут в техподдержку;
— от техподдержки администраторы рано или поздно узнают о проблемах и исправляют их.
Наличие триггера в Zabbix всё упрощает — можно оперативно устранять такие проблемы.
Привет, Георг!
Верно, имена заменены. Но лишь по той причине, что некоторые сотрудники сейчас не работают в команде. Их достижения мы ценим и всегда ждём в гости.
Замечание отличное. Однако на практике мы видим, что место чаще всего забивается разросшейся БД и файлами сайта — тут мы точно определяем факт заполнения диска. К примеру, mysql периодически вызывает системный вызов fsync(). Также какая-нибудь CMS клиента вызывает fsysc() при ресайзе картинок – а как только fsync() вызван, данные оседают на дисках ноды.
С qemu-guest-agent – с ним мы знакомы, на нём завязана система резервного копирования VDS. Через него можно получать статистику по дисковому пространству. Однако:
— там нет отдельного вызова для получения статистики. Разработчики qemu только-только (в июне) дописали вызовguest-get-fsinfo, чтобы он возвращал статистику и по занятости диска. Соответственно, в VDS в 16 и 18 Ubuntu, например, более старая версия агента и он не вернёт эту информацию;
— есть альтернатива: вызывать df через guest-exec, но опять же, guest-exec есть не на всех VDS;
Возможно, в будущем мы будем частично собирать информацию через qemu-guest-agent на некоторых VDS для ускорения работы.
Спасибо за идею. Мы рассматриваем вариант добавления мониторинга партиций, а также контроля не только за системным диском, но и за дополнительными дисками сервера.
Killy, благодарим за идею и ценные предложения по улучшению системы оповещений.
Пока что миграцию с виртуального хостинга на VDS можно выполнить в ручном режиме: наши технические специалисты перетащат сайты на виртуальный сервер с одной из поддерживаемых панелей, а коллеги из информационной поддержки помогут с переносом средств.
С поддержкой Python3 на виртуальном хостинге задержались. Но работаем, скоро внедрим.
У нас есть инструкция по использованию Node.js и npm. Если у вас есть нарекания по ней — пожалуйста, поделитесь с нашей поддержкой деталями, чтобы мы могли внести нужные изменения. Или просто разместите проект на VDS.
На момент вашего сообщения мы проводили кратковременные работы по панели, вскоре они были завершены. Но если вопрос актуален — сообщите логин, дадим комментарий по вашему аккаунту.
Илья, привет. Спасибо за такую высокую оценку. Отвечаем по порядку:
1. Сейчас у нас в работе есть задача по реализации корректной работы консоли VDS в мобильных приложениях. Ваше пожелание приняли и постараемся оценить в рамках текущей задачи, как быстро мы сможем внедрить поддержку сочетания клавиш в панель виртуальных серверов.
2. У нас хорошая новость: прямо сейчас мы работаем над внедрением новых тарифов для VDS с большим объемом SSD по действительно приятной стоимости. Мы обязательно расскажем подробнее о них в наших сообществах, как только случится релиз.
Как думаете, диск какого объема вам бы подошёл для комфортного размещения всех необходимых файлов на виртуальном сервере?
Раньше мы использовали ebtables и на создание правил для каждой VDS уходило очень много времени. Тем самым libvirt был недоступен около 40-60 минут, что не давало возможности взаимодействовать с VDS через панель хостинга.
Перезагрузку выполняли во время регламентных работ, таких как обновление ПО, ядра или при добавлении нового функционала.
Привет! Мы создавали Community с целью дать клиентам и посетителям сайта возможность обсуждать технологии, советоваться и помогать друг другу. Это не еще один канал общения со службой поддержки, поэтому она там не присутствует.
В Community, как правило, обсуждаются общие вопросы, касающиеся разработки и поддержки сайтов. А вопросы, связанные с нашими услугами, перенаправляются в службу поддержки пользователей, где на них отвечают наши специалисты (либо мы отвечаем письмом прямо на почту пользователей, чтобы было быстрее).
Конечно, мы стремимся, чтобы Community стал таким же популярным, как Хабр. Но пока активных пользователей там меньше, поэтому и обсуждения в вопросах не столь активны. Но все еще впереди!
Здравствуйте. Особо приятно видеть среди читателей блога давнего клиента и партнёра. Вы можете рассчитывать на наш квалифицированный, вежливый ответ по любому вопросу о хостинге и в дальнейшем в формате 24/7.
Забавно :) Прямо сейчас заглянули к дежурному инженеру: на одном мониторе традиционно открыт Zabbix для контроля за ситуацией на площадке. Его дополняет Grafana, с помощью которой мы анализируем работу ряда серверов, что по итогу должно привести к увеличению uptime на них.
Alex, спасибо за отзыв, такие слова действительно мотивируют нашу команду!
Мы знаем, насколько важно своевременно обновлять CMS для обеспечения безопасности сайта. Это касается и ситуации, когда проект только на стадии запуска. Как думаете, какую периодичность обновления текущих движков вы бы назвали достаточной и оптимальной?
— из-за ошибки в коде или из-за ручного вмешательства создаётся невалидная конфигурация nginx;
— пользователи пытаются создать сайт / привязать новый домен к сайту / сменить версию PHP на сайте и у них ничего не получается. Потому что nginx не загружает новую конфигурацию;
— пользователи звонят / пишут в техподдержку;
— от техподдержки администраторы рано или поздно узнают о проблемах и исправляют их.
Наличие триггера в Zabbix всё упрощает — можно оперативно устранять такие проблемы.
Верно, имена заменены. Но лишь по той причине, что некоторые сотрудники сейчас не работают в команде. Их достижения мы ценим и всегда ждём в гости.
С qemu-guest-agent – с ним мы знакомы, на нём завязана система резервного копирования VDS. Через него можно получать статистику по дисковому пространству. Однако:
— там нет отдельного вызова для получения статистики. Разработчики qemu только-только (в июне) дописали вызов guest-get-fsinfo, чтобы он возвращал статистику и по занятости диска. Соответственно, в VDS в 16 и 18 Ubuntu, например, более старая версия агента и он не вернёт эту информацию;
— есть альтернатива: вызывать df через guest-exec, но опять же, guest-exec есть не на всех VDS;
Возможно, в будущем мы будем частично собирать информацию через qemu-guest-agent на некоторых VDS для ускорения работы.
Благодарим вас за то, что помогаете нам стать лучше!
Спасибо за пожелание!
Вот ссылочка на модель кресла: клик
Пока что миграцию с виртуального хостинга на VDS можно выполнить в ручном режиме: наши технические специалисты перетащат сайты на виртуальный сервер с одной из поддерживаемых панелей, а коллеги из информационной поддержки помогут с переносом средств.
У нас есть инструкция по использованию Node.js и npm. Если у вас есть нарекания по ней — пожалуйста, поделитесь с нашей поддержкой деталями, чтобы мы могли внести нужные изменения. Или просто разместите проект на VDS.
На момент вашего сообщения мы проводили кратковременные работы по панели, вскоре они были завершены. Но если вопрос актуален — сообщите логин, дадим комментарий по вашему аккаунту.
1. Сейчас у нас в работе есть задача по реализации корректной работы консоли VDS в мобильных приложениях. Ваше пожелание приняли и постараемся оценить в рамках текущей задачи, как быстро мы сможем внедрить поддержку сочетания клавиш в панель виртуальных серверов.
2. У нас хорошая новость: прямо сейчас мы работаем над внедрением новых тарифов для VDS с большим объемом SSD по действительно приятной стоимости. Мы обязательно расскажем подробнее о них в наших сообществах, как только случится релиз.
Как думаете, диск какого объема вам бы подошёл для комфортного размещения всех необходимых файлов на виртуальном сервере?
Перезагрузку выполняли во время регламентных работ, таких как обновление ПО, ядра или при добавлении нового функционала.
В Community, как правило, обсуждаются общие вопросы, касающиеся разработки и поддержки сайтов. А вопросы, связанные с нашими услугами, перенаправляются в службу поддержки пользователей, где на них отвечают наши специалисты (либо мы отвечаем письмом прямо на почту пользователей, чтобы было быстрее).
Конечно, мы стремимся, чтобы Community стал таким же популярным, как Хабр. Но пока активных пользователей там меньше, поэтому и обсуждения в вопросах не столь активны. Но все еще впереди!
Надеемся на продолжение сотрудничества!
Мы знаем, насколько важно своевременно обновлять CMS для обеспечения безопасности сайта. Это касается и ситуации, когда проект только на стадии запуска. Как думаете, какую периодичность обновления текущих движков вы бы назвали достаточной и оптимальной?