Да, согласен, работы при внедрении DevLake немало, можно и проще. Но при росте масштабов CI/CD простые уведомления о том, что пайп упал, часто ведут к быстрому устранению проблемы, например, рестарту джобы. Это, в общем то, решает проблему только в моменте.
Хотелось контролировать ситуацию целиком. Можно поставить цель в 85% success rate джоб и искать проблемы, которые регулярно всплывают и снижают этот success rate. В итоге после устранения этих проблем у нас заметен прогресс в стабильности CI/CD.
По поводу статистики MR по часам. Мысль была в том, чтобы выяснить, насколько success rate зависит от параллельно происходящих в инфраструктуре событий (по сути, от нагрузки).
Расскажите, пожалуйста, чем эффективнее? Если отсутствием длинной транзакции, то как я написал коллеге чуть ниже, миграция одной транзакцией позволяет легко откатить изменения при проблемах. Это такая архитектурная необходимость.
Я искал такую возможность в PgLoader, но не обнаружил. Оно и логично, т.к. миграция в одной транзакции позволяет легко откатить все изменения, если что-то пошло не так при миграции. У меня лично было много проблем на PgLoader 3.6.1. И без отката всех изменений было бы очень неудобно.
Верно, я не стал пытаться объять необъятное и включать в одну статью еще и причины выбора СУБД, и вопросы ее тюнинга. Миграция на PostgreSQL нужна была для того, чтобы в последующем применить TimescaleDB. О преимуществах TimescaleDB для Zabbix уже неоднократно писали в том числе здесь на Хабре. Базы данных временных рядов в целом больше подходят для систем мониторинга.
Например, одна из самых назойливых проблем при работе Zabbix на реляционной БД — медленный Housekeeper. Хотя бы для решения этой проблемы уже стоит мигрировать.
Нашел статью: habr.com/ru/company/oleg-bunin/blog/470902
Information
Rating
947-th
Location
Ханты-Мансийск, Тюменская обл. и Ханты-Мансийский АО, Россия
Да, согласен, работы при внедрении DevLake немало, можно и проще. Но при росте масштабов CI/CD простые уведомления о том, что пайп упал, часто ведут к быстрому устранению проблемы, например, рестарту джобы. Это, в общем то, решает проблему только в моменте.
Хотелось контролировать ситуацию целиком. Можно поставить цель в 85% success rate джоб и искать проблемы, которые регулярно всплывают и снижают этот success rate. В итоге после устранения этих проблем у нас заметен прогресс в стабильности CI/CD.
По поводу статистики MR по часам. Мысль была в том, чтобы выяснить, насколько success rate зависит от параллельно происходящих в инфраструктуре событий (по сути, от нагрузки).
После этой фразы я до конца статьи ждал проблему. Но не дождался. Интересно, спасибо.
Например, одна из самых назойливых проблем при работе Zabbix на реляционной БД — медленный Housekeeper. Хотя бы для решения этой проблемы уже стоит мигрировать.
Нашел статью:
habr.com/ru/company/oleg-bunin/blog/470902