МЖ
дык я видел, как каспер изначально в пт сием был нормализован
Size: a a a
2020 September 06
МЖ
я не уверен, что с kics это было - но почти уверен, что как раз в нормализованном событии лежал Json
МЖ
странная фраза получилась, но ладно :)
e
Просто я одно время топил за такую модель событий.
Не совсем JSON, но модель, имеющую возможность некоторой вложенности.
e
Максим Жевнерев
я не уверен, что с kics это было - но почти уверен, что как раз в нормализованном событии лежал Json
JSON, только в строковом поле =)
К
Такое может быть в, основном, у самописного приклада. Крупные вендоры таким не промышляют.
ну как бы нет. либо некоторые абсины и сзи надо признать самописным прикладом
NA
если отечественные, то да, тут такой разврат творится чаще чем в зарубежных.
К
вообще я не очень понимаю это прекрасное разделение, на самом деле. тут у нас самописный приклад, мы его нормализовывать не будем, а тут - события от каспера/фортика/цфт - вот ими мы и займёмся
RS
Незакрытые тэги в xml были в не очень самописном Oracle
К
невалидный XML - вообще любимый прикол
К
кто пытался что-то интегрировать в Splunk с ним хорошо знаком)
К
то есть чтобы кто-то ходил через апи в спланк за данными
e
Такое может быть в, основном, у самописного приклада. Крупные вендоры таким не промышляют.
Нашел, где последний раз встречался JSON - так и есть самописный приклад (но, правда, полезный).
2020 September 07
e
Коллеги, подскажите, пожалуйста, куда смотреть, если очередь "incidentReadModel_IncidentConsumer" крайне медленно разгребается? В MS SQL Express?
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
BB
Коллеги, подскажите, пожалуйста, куда смотреть, если очередь "incidentReadModel_IncidentConsumer" крайне медленно разгребается? В MS SQL Express?
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
Если у вас на виртуалках, то мб лимит IOPS поднять
e
Если у вас на виртуалках, то мб лимит IOPS поднять
Это следствие, пока не понятно следствие чего именно.
RS
Всплеска срабатываний нет? Событий типа incident
Z
Коллеги, подскажите, пожалуйста, куда смотреть, если очередь "incidentReadModel_IncidentConsumer" крайне медленно разгребается? В MS SQL Express?
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
Всё "зелёное", consumer у очереди есть. R22.3280
UPD:
Утилизация слишком диска большая => в журнале службы ошибки RMQ и PostgreSQL.
Если недавно встречалось что-то похожее - отпишитесь, пожалуйста.
дяденька знаю что у вас сломалось
e
Всплеска срабатываний нет? Событий типа incident
Не, но MS SQL Express действительно забился. Чистится. Почему это стало так аффектить на диск - кто ж его знает (может жОсткая ротация + аудит файловых операций).
e
Не, но MS SQL Express действительно забился. Чистится. Почему это стало так аффектить на диск - кто ж его знает (может жОсткая ротация + аудит файловых операций).
Через UI не удаляет инциденты, вручную из БД как-то не хочется удалять (наверное, там много зависимостей). БД не сжимается.
Лучше обратиться в техподдержку?
Лучше обратиться в техподдержку?