Я с вам не согласен. У вас корректное описание интеграционных тестов, но некорректный вывод, что для интеграционных тестов не нужны все сервисы. Почему не нужны? Интеграционные тесты так же проводятся на все сервисы. У них и название такое «интеграционные» — проверятся интеграция между сервисами.
Отличие интеграционных и e2e в том, что у e2e нет mock внешних сервисов, а у интеграционных — есть.
Возможно, мы с вами друг друга не понимаем ещё и потому, что интеграционные тесты можно проводить не только для какой-то подсистемы с набором микросервисов, но и интеграционные высшего уровня — интеграция между этими подсистемами.
И интеграционные — это не дорого. Как раз Catcher их упрощает. Дорого интеграционные писать на используемом ЯП.
И вот если в Catcher добавить сервер, получающий ответы — то это его превратит в отличную систему и для интеграционных тестов, где адрес этого сервера будет служить для моков.
На мой взгляд, вы в п.5 ошиблись насчёт интеграционных тестов (вероятно, имелись в виду юнит-тесты). e2e тесты и интеграционные — суть одно и то же, только e2e ближе к пользователю, а интеграционные — к бекенду. Интеграционные они так и называются, что тестируют интеграцию компонентов, а не один компонент с моками.
Да я же джва года такую штуку ждал!
Её вполне себе можно и для интеграционных тестов применять.
Самое близкое по идеологии что есть, на мой взгляд — только Postman.
Ещё в стандартные модули нужен модуль «сервер», который поднимает сервер, ждёт какую-либо нотификацию и её проверяет.
Балансировка — типа Traefik, но свой велосипед. Когда всё это делалось Traefik только появился и чем-то не устроил, чего-то не хватало.
Там ничего необычного. Обычный nginx, с конфигом, формируемым consul-template. Список сервисов берётся из Consul по тегам + дополнительная конфигурация по сервисам — из Consul KV. Конфиг формируется, там все локейшены/апстримы и при изменениях nginx перечитывает конфиг. Апстримы сервисов добавляются/удаляются из апстримов nginx, соответственно.
Сервисы nginx прибиты к конкретным серверам с ролью "балансер". В DNS у сайтов прописаны все эти адреса. Это "домашний" кластер.
В рабочем примерно так же, но там ещё AS поверх DNS.
RabbitMQ при больших нагрузках — это боль. Точнее, для достижения нормального RPS нужно уж больно много ресурсов/нод/CPU.
Перешли на Redis Cluster Streams и счастливы.
Поздно postgresql, поздно. OLAP+SQL=ClickHouse.
У нас у самих до сир пор осталось пяток самописных агрегаций в постгресе. Характеристика одним словом — неудобно.
Спасибо. Да, логов у вас достаточно большой объём. Вероятно, фронтент логхауса что-то не то делает при выборках — из-за этого нам пришлось перейти с дневных партиций на почасовые.
1. Loghouse и просто в виде контейнера запускается.
2. То есть, у вас в строках, в полях message/content — json? И скорость работы поиска в таком случае устраивает?
3. Я больше спрашивал про дневной объём логов в гигабайтах, если не секрет (в сжатом виде в папке КХ)?
И мне кажется, что у вас не так много логов, если вы не натыкались на:
1. Нехватку памяти при работе с одной таблицей. У loghouse отдельные именно таблицы подневные/почасовые.
2. Медленным поиском по строкам. У loghouse кривоватый подход, но иначе в КХ и не получится. И в итоге данные можно заливать в уже структурированном виде. И поиск будет получше.
1. Почему не loghouse?
2. Как ищите по логам без ключевых полей (ip/id пользователя/что-то ещё)?
3. Какой объём данных в день и количество шардов, если не закрытая информация?
4. Если используете rsyslog, то почему не его протокол для приёма логов?
Когда маркетолог говорит «облако» — это набор серверов его компании, который он хочет всем продать.
Когда я говорю «облако» — это набор ресурсов по всему миру, не зависящий от одной компании.
Зависит от хост-ноды. Если соседи «спокойные», то всё нормально. Если «буйные», то достаточно завести новую виртуалку и понаблюдать, старую удалить.
Из 6 таких микро-виртуалок приходилось так пересоздавать одну.
У арубы оверселлинг терпимый, не то, что у наших некоторых хостеров.
Нет, для таких маленьких виртуалок со скоростью там терпимо.
Хотел ещё себе в кластер виртуалок в ДЦ, отличном от aruba. У самого aruba несколько ДЦ, но доступен для одно-евровых только один (IT-1). А сейчас они ещё и убрали возможность посмотреть, в каком ДЦ будет создана новая виртуалка.
Отличие интеграционных и e2e в том, что у e2e нет mock внешних сервисов, а у интеграционных — есть.
Возможно, мы с вами друг друга не понимаем ещё и потому, что интеграционные тесты можно проводить не только для какой-то подсистемы с набором микросервисов, но и интеграционные высшего уровня — интеграция между этими подсистемами.
И интеграционные — это не дорого. Как раз Catcher их упрощает. Дорого интеграционные писать на используемом ЯП.
И вот если в Catcher добавить сервер, получающий ответы — то это его превратит в отличную систему и для интеграционных тестов, где адрес этого сервера будет служить для моков.
Её вполне себе можно и для интеграционных тестов применять.
Самое близкое по идеологии что есть, на мой взгляд — только Postman.
Ещё в стандартные модули нужен модуль «сервер», который поднимает сервер, ждёт какую-либо нотификацию и её проверяет.
Да, сервисы в Consul, на них healthcheck'и.
Балансировка — типа Traefik, но свой велосипед. Когда всё это делалось Traefik только появился и чем-то не устроил, чего-то не хватало.
Там ничего необычного. Обычный nginx, с конфигом, формируемым consul-template. Список сервисов берётся из Consul по тегам + дополнительная конфигурация по сервисам — из Consul KV. Конфиг формируется, там все локейшены/апстримы и при изменениях nginx перечитывает конфиг. Апстримы сервисов добавляются/удаляются из апстримов nginx, соответственно.
Сервисы nginx прибиты к конкретным серверам с ролью "балансер". В DNS у сайтов прописаны все эти адреса. Это "домашний" кластер.
В рабочем примерно так же, но там ещё AS поверх DNS.
Перешли на Redis Cluster Streams и счастливы.
У нас у самих до сир пор осталось пяток самописных агрегаций в постгресе. Характеристика одним словом — неудобно.
2. То есть, у вас в строках, в полях message/content — json? И скорость работы поиска в таком случае устраивает?
3. Я больше спрашивал про дневной объём логов в гигабайтах, если не секрет (в сжатом виде в папке КХ)?
И мне кажется, что у вас не так много логов, если вы не натыкались на:
1. Нехватку памяти при работе с одной таблицей. У loghouse отдельные именно таблицы подневные/почасовые.
2. Медленным поиском по строкам. У loghouse кривоватый подход, но иначе в КХ и не получится. И в итоге данные можно заливать в уже структурированном виде. И поиск будет получше.
2. Как ищите по логам без ключевых полей (ip/id пользователя/что-то ещё)?
3. Какой объём данных в день и количество шардов, если не закрытая информация?
4. Если используете rsyslog, то почему не его протокол для приёма логов?
Когда я говорю «облако» — это набор ресурсов по всему миру, не зависящий от одной компании.
Из 6 таких микро-виртуалок приходилось так пересоздавать одну.
У арубы оверселлинг терпимый, не то, что у наших некоторых хостеров.
Хотел ещё себе в кластер виртуалок в ДЦ, отличном от aruba. У самого aruba несколько ДЦ, но доступен для одно-евровых только один (IT-1). А сейчас они ещё и убрали возможность посмотреть, в каком ДЦ будет создана новая виртуалка.
Это он сейчас так говорит, чтобы поддержать своё реноме. Но мы-то помним всю правду :)
apt в обычной версии (не в server) автоматически запрашивает sudo. Так что, можно и так
Какая настройка за это отвечает — не смотрел.