dimone73, еще раз хочу обратить внимание что AMI транслирует события как как о парковке и о взятии номера с парковки.
В 11 Астере все это уже должно было работать, так как ссылки на справку от 2005 года.
События можно послушать даже через обычный netcat
dimone73, тогда звучит так что стоит посмотреть в сторону ami, так как одна из его функций - предоставление возможности подписаться на поток событий генерируемых в Asterisk
Каждая система считает домен новым на свое усмотрение. Обычно новым считается домен "несколько недель", без определенных периодов, после создания или изменения записей о делегировании
bronzeev, если особых требований по аптайму, частоте поставок и нагрузке нет, да или вовсе вы один разработчик и ops в одном лице на проекте - композа хватит)
AdaMorgan, стало чуть понятнее. Если у вас используется стандартное логирование БД и требуется решить вопрос масштабирования, предложил бы такой вариант системы:
Postgresql пишет лог в json
Используя filebeat, логи пушить в топик (возможно, в топики в разрезе по пользователям или другим условиям) в Kafka. Ротацию устаревших логов так же можно выполнять с помощью filebeat
Потоки события из Kafka уже анализируются приложением
Если этот вариант не подходит и требуется лишь решить вопрос удаления старых файлов, то не совсем понял почему "Ситуация с прямым чтением и очисткой файла через Java сразу отпала". Она не столь удобна как чтение из Кафки, но возможна. Ваше приложение должно будет управлять ротацией логов. Операция должна будет следующей - выполняется logrotate (или аналогичными библиотеками для Java) для лога, затем необходимо закрыть и открыть снова файл лога в Java. Таким образов вы гарантированно дочитаете старый лог.
При других вариантах очистки или ротации, я опасаюсь, будет шанс потерять часть событий.
Ого. На первый взгляд даже не думал о применении Посгри в качестве шины данных событийной архитектуры. На ум сразу приходят Кафка или Стримы Rabbitmq, собственно, спроектированные для работы с потоками событий...
У Посгри конечно есть notify, который можно использовать совместно с триггерами таблиц, но это тоже что-то довольно самобытное.
Можете ли подробнее описать архитектуру решения, быть может я думаю о чем-то другом? Потому что пока никак не могу увязать в голове описанное в вопросе - БД, событийку и файловые логи
Даниил Сидоров, визуально не нашел отклонений. Есть ли посвежее логи с ингресса? Логируется ли что-то в поде при этом?
Что если прокинуть порт сервиса и открыть в браузере, работает так же как и при обращении на Pod? kubectl -n myapp port-forward svc/myapp-yii 80:80
и с соседней консоли curl -v localhost:80
Все ок при таком тесте?
Даниил Сидоров, имена сервисов, деплоймента, неймспейс у манифестов в вопросе не совпадают с тем что выводят запросы kubectl.
Исходные манифесты корректные, тогда как текущая конфигурация в кластере вероятно нет. Чтобы что-то подсказать мне нужна актуальная информация. Скорее всего в коныиге ингресса не указано полное имя сервиса, предположительно сейчас оно такое: "myapp-yii.myapp"
valera_efremov, погуглить и потестировать. Задача популярная, решения и примеры найдутся.
Можно попробоваться использовать --tee для того чтобы скопировать пакет в другое назначение и продолжить обработку текущего
RizoKadiev, это я уже видел в оригинальном вопросе, но зачем это так реализуется?
Зачем в имени очереди self.task_id, какая там логика роутинга по task_id? У тебя ведь каждый таск будет в отдельной очереди при таком раскладе.
Как подписка выглядит на эти очереди в консюмерах? Сколько консюмеров и какая архитектура сервиса?
Хочется понять цели такого решения чтобы что-то можно было посоветовать.
На вскидку - не задекларирован Exchange, только очереди.
Процесс декларирования выстроен не корректно - сервис-продюсер должен декларировать Exchange, а сервисы-консюмеры декларировать свои Queue и биндить их к exchange.
Затем, совершенно непонятно какая задача решается, а так же для каких целей плодится столько очередей. У вас будет по одному консюмеру на каждый task_id? Верится с трудом. Что-то здесь не так. Дополни вопрос комментарием о том чего пытаешься добиться такой структурой очередей. Возможно нужно другое решение.
