AP
Можно и снаружи, но зависит тогда от настроек больше, я по фотографии тут не смогу
Size: a a a
2020 May 24
AP
Надо давно было запилить простой лог пришедших пакетов, прям внутри пинбы.
AP
Артем, мастер пинбы собрать и проверить на нем сможете, если что?
AP
из мастера *
AV
я с мастера и собрал контейнер или речь - проверить после того как вы добавите лог пакетов?)
AP
а, хотя и сейчас есть возможность, забываю все время ;) ща
AP
идете консолью в mysql и там
AP
set global pinba_packet_debug=1; set global pinba_packet_debug_fraction=1;AP
и каждый пакет тогда будет писаться в mysqld.log (то есть логфайл mysql, в котором пинба сидит)
AP
нам тут важен только факт их прихода, на самом деле
AP
если пакетов нет - смотрим, что с сетью. если есть - посмотрим на отчеты
AV
Спасибо большое! Буду пробовать.
P
Можно в этом же контейнере запустить socat или nc на listen порта. Сразу будет видно, если прилетит пакет.
P
Ну и tcpdump тоже вариант. Не придётся пинбу гасить или другой порт настраивать.
docker exec и поехали.
docker exec и поехали.
2020 May 31
М
Ребят. Всем привет! Может кто помочь по микросерверной архитектуре? Сделал диаграмму https://cloud.mail.ru/public/C1eJ/gCfTECrH8
Не слишком ли я сильно разбил микросервисы? Например Contest, Participants, Discipline возможно стоит объединить в один.
Так как Contest это само управление конкурсами. Participants это управление участниками (регистрация, заявки) и дисциплины самого конкурса. Фактически больше нигде использоваться не будут.
Они тесно связаны, но при этом каждый из них может быть относительно самостоятельным, с легкой связью по ID. Кроме того это первая версия. И каждый из них будет развиваться по мере развития проекта. Поэтому решил, что Contest будет слишком «жирным». Или нормально? Не могу определиться с размером микросервиса.
Спасибо за помощь!)
Не слишком ли я сильно разбил микросервисы? Например Contest, Participants, Discipline возможно стоит объединить в один.
Так как Contest это само управление конкурсами. Participants это управление участниками (регистрация, заявки) и дисциплины самого конкурса. Фактически больше нигде использоваться не будут.
Они тесно связаны, но при этом каждый из них может быть относительно самостоятельным, с легкой связью по ID. Кроме того это первая версия. И каждый из них будет развиваться по мере развития проекта. Поэтому решил, что Contest будет слишком «жирным». Или нормально? Не могу определиться с размером микросервиса.
Спасибо за помощь!)
I
Ребят. Всем привет! Может кто помочь по микросерверной архитектуре? Сделал диаграмму https://cloud.mail.ru/public/C1eJ/gCfTECrH8
Не слишком ли я сильно разбил микросервисы? Например Contest, Participants, Discipline возможно стоит объединить в один.
Так как Contest это само управление конкурсами. Participants это управление участниками (регистрация, заявки) и дисциплины самого конкурса. Фактически больше нигде использоваться не будут.
Они тесно связаны, но при этом каждый из них может быть относительно самостоятельным, с легкой связью по ID. Кроме того это первая версия. И каждый из них будет развиваться по мере развития проекта. Поэтому решил, что Contest будет слишком «жирным». Или нормально? Не могу определиться с размером микросервиса.
Спасибо за помощь!)
Не слишком ли я сильно разбил микросервисы? Например Contest, Participants, Discipline возможно стоит объединить в один.
Так как Contest это само управление конкурсами. Participants это управление участниками (регистрация, заявки) и дисциплины самого конкурса. Фактически больше нигде использоваться не будут.
Они тесно связаны, но при этом каждый из них может быть относительно самостоятельным, с легкой связью по ID. Кроме того это первая версия. И каждый из них будет развиваться по мере развития проекта. Поэтому решил, что Contest будет слишком «жирным». Или нормально? Не могу определиться с размером микросервиса.
Спасибо за помощь!)
Привет, выглядит абсолютно адекватно
М
Привет, выглядит абсолютно адекватно
То есть не стоит объединять? Меня смущает тот факт, что дисциплины в словарях и они тесно связаны с конкурсами. Иногда слышал такое, что если микросервисы с друг другом тесно связаны - стоит их объединить. Вот и сбило с толку)
I
То есть не стоит объединять? Меня смущает тот факт, что дисциплины в словарях и они тесно связаны с конкурсами. Иногда слышал такое, что если микросервисы с друг другом тесно связаны - стоит их объединить. Вот и сбило с толку)
А собираешься ли выбирать дисциплины отдельно от конкурсов для аналитики и прочего?
М
А собираешься ли выбирать дисциплины отдельно от конкурсов для аналитики и прочего?
Сейчас у меня дисциплины используются в самих конкурсах (Contest) и регистрации (Participants). Возможно, что в будущем будет какой-то сервис рекомендаций или аналитики, который будет собирать статистику популярности дисциплин, например.
I
Думаю что тогда объединять их не актуально