Только надо включать этот планировщик аккуратно, потому что включение multiqueue API приводит к отключению non-multiqueue планировщиков (noop, cfq, deadline)
Это все здорово и прекрасно, но только после того как появится фича "Алерт 90% метрик не обновлялись более n-времени". Прикручивать к каждому итему триггер на nodata неразумно и не все итемы поддерживают данные тип.
Неприятно узнать что в проде мониторинг "как живой"
Ну мы наблюдали не только эту проблему, внутри самого сервера (или прокси) мог произойти сегфолт который намертво останавливал сбор остальных метрик (не IPMI)
Я правильно понимаю, что данный метод несовместим с ядрами которые защищены через kdump — он требует именно перемещаемое ядро:
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
of today, i386, x86_64, ppc64, ia64 and arm architectures support relocatable
kernel.
>К сожалению, системы на базе Celery сложно поддерживать в работоспособном состоянии, и когда что-то идёт не так, то найти проблему бывает весьма не просто.
А вы уверены, что говорите именно про проблемы продукта, а не очереди, поверх которой бежит Celery (rabbitmq/redis/mongo)
Спасибо за статью. Пара вопросов — я правильно понял, что логическая репликация в слейв будет работать начиная со времени подписки на мастер? И совмещать PITR и логическую репликацию нельзя?
Ну собственно вопроса два — если это опенсорс — где на него можно посмотреть? И по поводу гипервизора — я правильно понял, что на питоне только скрипты конфигурирования, а сам гипервизор на более другом языке. Насколько он портабельный (на другие mips-платы)?
Свагер это хорошо, хипстово, современно. Но жизнь чуточку сложнее — бывают сложные сценарии, когда нужно дергать последовательность ручек, вот отсюда из ответа надо взять ИД и передать сюда итд.
Да и стороннему заказчику такое не отдашь, все равно приходится писать текстовое описание.
Полезно: Если вы случайно потеряете или забудете пароль, то в этом диалоговом окне можно задать новый. Он и будет затем использоваться при восстановлении из файлов цепочки бэкапов (включая те, что были зашифрованы со старым паролем).
Значит ли это, что при задании нового пароля старые бекапы будут перешифрованы?
Можно посмотреть на все это в другом измерении, с точки зрения производителя оборудования. Очень важно пользоваться разными производителями оборудования, разными прошивками, разными драйверами.
Только надо включать этот планировщик аккуратно, потому что включение multiqueue API приводит к отключению non-multiqueue планировщиков (noop, cfq, deadline)
Это все здорово и прекрасно, но только после того как появится фича "Алерт 90% метрик не обновлялись более n-времени". Прикручивать к каждому итему триггер на nodata неразумно и не все итемы поддерживают данные тип.
Неприятно узнать что в проде мониторинг "как живой"
Ну мы наблюдали не только эту проблему, внутри самого сервера (или прокси) мог произойти сегфолт который намертво останавливал сбор остальных метрик (не IPMI)
Ммм, https://support.zabbix.com/browse/ZBX-10940
похоже что нет.
А есть кто может рассказать чем оно лучше/хуже Jira?
Я правильно понимаю, что данный метод несовместим с ядрами которые защищены через kdump — он требует именно перемещаемое ядро:
https://www.kernel.org/doc/Documentation/kdump/kdump.txt
А вы уверены, что говорите именно про проблемы продукта, а не очереди, поверх которой бежит Celery (rabbitmq/redis/mongo)
Спасибо за статью. Пара вопросов — я правильно понял, что логическая репликация в слейв будет работать начиная со времени подписки на мастер? И совмещать PITR и логическую репликацию нельзя?
Проблема как раз есть — право делится кодом и право делится своим правом это разные права.
Да и стороннему заказчику такое не отдашь, все равно приходится писать текстовое описание.
Значит ли это, что при задании нового пароля старые бекапы будут перешифрованы?
Судя по их архитектуре они не используют СХД.
Ну и автор прямо говорит: