The ability to store dates in nanosecond resolution required a significant refactoring within the Elasticsearch code base. Read this blog post for the why and how on our journey to be able to store dates in nanosecond resolution from Elasticsearch 7.0 onwards.
По-умолчанию грейлог отображает лог-сообщения с сортировкой по времени, порядок не важен. Только вот в эластике точность 3 знака, а если операция выполняется быстрее миллисекунд, то порядок отображения зависит от времени прихода, тут все начинают ломать асинхронные логгеры. К примеру, у нас есть 2 сообщения следующих таймстампов 1385053862.3072 и 1385053862.3074. Второе должно отобразиться выше. Однако при сохранении данных грейлог запишет у сообщений таймстамп 1385053862.307. Т.к логер асинхронный мы не можем гарантировать, что второе сообщение придет вторым. Вот и получается, что порядок сообщений нарушается. У нас пытались вводить сиквенсы и прочие костыли.
Из-за этого на продуктивных серверах все еще используем «старый формат» логирования, потому что порядок сохраняется. Заводил тикет, думал, что связано было с гонками в http, но проблема в том что время в текущем релизе грейлога, точнее эластика с которым он работает(6 вроде) ограничено мс.
Не встречались с проблемой, что грейлог в текущей реализации работает с эластиком в которой точность времени ограничена мс? Из-за этого логи почти любого приложения идут в хаотичном порядке(операции выполняются быстрее чем за мс). Есть ли какое-то решение для этого?
Советую к шаблону докрутить callback, который будет вызван при повторе/падении запроса.
Так метрики можно будет собирать не только на уровне API (только коды ответов и тд), но и этой обертки (сколько из этих запросов были повторены).
Реализовали у себя очень похожую штуку.