Чтобы сравнивать между собой результаты, нужно одинаковое облако использовать. В начале вообще думаю, Azure захардкодить. Потом сделать расширяемым
Читать полностью…да, именно так. тебе ж логи не для аудита нужны. если для аудита то это цена ведения бизнеса в регулируемой среде
Читать полностью…Чтобы провести нагрузку, нужно создать сервера. Для текущего проекта мы используем 4 штуки:
- DB Server для PostgreSQL
- App Server для SUT (System Under Test), OpenTelemetry Collector, Node Exporter (чтобы метрики сервера снимать)
- Telemetry Server для Elasticsearch, Kibana, Prometheus, Grafana
- K6 Server для K6
Приложение (плюс OTel Collector в нужных кейсах) изолировано на отдельном сервере, чтобы другие компоненты ему не мешали и можно было без искажений понять потребление ЦПУ и памяти.
Сейчас для развёртывания всего этого железа и софта мы используем Terraform. Одна конфигурация разворачивает сервера и все нужные ресурсы в Azure. И потом для каждого сервера есть своя Terraform конфигурация, которую нужно применить локально на сервере. Это достаточно муторно всё.
Перед каждым прогоном нагрузки нужно почистить окружение - удалить записи из БД, Elasticsearch, ребутнуть приложение. Это сейчас руками делаем.
Для каждого прогона нужно донастраивать окружение - менять переменные окружения, запускать/останавливать OTel Collector и т.д.
В конце нужно удалить все ресурсы Azure, чтобы они деньги не ели.
По задумке, оператор нужен для автоматизации всех этих движений. Ты просто описываешь в виде CRD сценарий нагрузки, всё остальное выполнит оператор. Сценарий это набор прогонов. Сейчас у нас это "без логгирования", "с прямой записью в ES", "с записью на диск и сбором OTel Collector".
В итоге в CRD нужно будет прописать операции очистки окружения, конфигурацию k6 и сценарий. Это всё будет один файл. Кормишь его оператору и тот сам создаст сервера, установит нужный софт, будет чистить окружения между прогонами, в конце экспортирует результаты, потом удалит все ресурсы.
Потом этот CRD можно опубликовать и любой желающий сможет его взять, установить оператор и в точности вопроизвести нагрузку. Может там версии менять, например. Чтобы под свою ситуацию адаптировать. Тем самым проведение сравнительного нагрузочного тестирования кардинально упростится. И станет намного чаще использоваться в индустрии для валидации тех или иных решений.
А в чем отличие кастомного решения от того же k6 будет с точки зрения проведения нагрузочного тестирования?
Читать полностью…создавай общий чат на обе задачи что бы люди с разными навыками могли поучаствовать
Читать полностью…Насчёт второй задачи - AI для анализа. Да, она может видоизмениться и не факт, что получится добиться успеха. Но во время её реализации можно получить хорошие знания и опыт работы с AI и LLM
Читать полностью…Ну тут надо cloud agnostic решение, в целом же должно быть без разницы? Даже хоть bare
Читать полностью…Тачки это стандартные инстансы Azure. Они имеют одинаковую конфигурацию и производительность. В теории. Для того, чтобы это корректировать, нужно несколько раз сценарий прогонять
Читать полностью…Как понять объективные цифры, тачки разные могут быть
Ты же делаешь абстракцию - верно?
обычно не все логи идут, а какой-то процент. в целом это достаточно прагматичный подход, и статистически он тебе все те же самые результаты дает.
Читать полностью…k6 этого всего делать не умеет, насколько я понимаю. locust не изучал. Он может всё это делать?
Читать полностью…Да, согласен. Это по сути два этапа одного проекта. Репу я уже пару недель назад создал - drimbench. Сперва оператор кубернетеса, потом добавить модуль LLM. Если увидим, что тесно в одном чате - поделим на два
Читать полностью…По тематике твоего канала вижу, что ты занимаешься AI. Канал интересный, подписался
Читать полностью…