Довольно сложный легаси проект после мерджа крупной пачки новых фич стал сыпать багами: в БД MongoDB у некоторых учеток меняются свойства, которые меняться вообще недолжны никогда, по идее.
Воспроизвести это на дев и стейдже не удаётся: всё работает ожидаемо, тесты (вручную) проходят. Нормальными тестами проект не покрыт, разумеется.
Как бы поймать хотя бы запрос или крон-джоб или Doctrine ODM слушатель событий, который меняет неприкасаемые документы?
Вроде бы, при изменениях меняется и modificationDate у документов, т.е. изменения идут, скорее всего, через PHP с классом документа, где описана эта логика, менять дату.
Но точной корреляции времени изменения с записями в логах запросов нет – расхождения бывают. Менять базу ещё могут воркеры, сервисы, nodejs процесс, слушающий WebSocket. Куча народу и все не при делах :)
Сергей Соколов, расскажу байку, случившуюся со мной много лет назад
стали записи портиться на сервере. Проверюю код - нет такого поведения.
В конце концов оказалось, что для разовой коррекции данных я написал скрипт .
Он отработал и я не стал его удалять с сервера. Но ссылка на него попало в табло Хрома.
И с не понятной переочидностью хром желая обновить превьюшку на стартовой странице дергал этот скрипт.
И второе предположение. Ваше легаси работало правильно до этого из-за четного числа ошибок. Исправивив нечетное их количество - получили глюк
Сергей Соколов, а какие еще варианты в таком зоопарке? Будь только http обращения - можно было бы поймать по логу http сервера и modified time. Ну крон так поймать можно. А вот воркеры - хрен
боюсь, такое логирование уложит спать боевой проект. Хотя ненадолго можно попробовать.
Я про логирование запросов к Mongo..
Во первых все логировать не нужно. Можно тупо в коде доктрины апдейты только ловить и логировать, можно иначе извернуться, но вам нужны, очевидно, только апдейты. Которых сомневаюсь что мильён в секунду. Ну и во вторых - просто малореально что-то другое придумать...
Чудесных способов нет - или включить логгинг запросов, как посоветовал Дмитрий (наверняка лог можно послать на отдельный диск чтобы меньше повлияло на производительность). Или ловить сниффером все обращения к Монго.
Или перелопатить все изменения в коде из мержа.
Нашли опытным путём некоторые действия, которые 100% приводили к нежелательному изменению данных.
Перерыли весь их код – ничего.
Глубокой ночью решились временно включить на проде дебажный режим кернела Symfony.
И повторив запрос, в профайлере нашли причину: один из разработчиков накостылил изменения на проде в /vendor/ доктрин-бридже. Он ошибочно полагал, что это ни на что не повлияет и никак не связано с появившейся проблемой.
Средний
