В последний выпуск был включен ужасный баг. Было потеряно много ценной пользовательской информации. С Кибаной мы все восстановили.
Шаг 1) 😎 Разверните новую замечательную функцию
Шаг 2) 😱 Паника через 4 дня, когда кто-то сообщает вам, что новый код повлиял на другую часть приложения, что привело к переопределению с нулями нескольких полей в таблица пользователей
Шаг 4) 💾 Восстановить некоторые данные из предыдущего дампа базы данных
Шаг 5) 😱 Паникуйте СНОВА, когда вы заметите, что в строке пользователя 6k все еще отсутствуют данные
Шаг 6) 🔎 обнаружил, что с помощью Kibana, к счастью, вы можете вручную восстановить информацию о пользователе, записанную в журнале
Шаг 7) 😱 Паникуйте БОЛЬШЕ, когда вы думаете, что вам нужно выполнить эту операцию вручную, шесть тысяч раз
Шаг 8) 💻 Реализуйте пакет на Java, реплицируя поток HTTP-вызовов, выполняемых вручную из Kibana U.I.
Шаг 9) 🎉 Прибыль
В этой статье рассматривается только шаг 8 нынешних эмоциональных американских горок в надежде, что он может быть полезен кому-то другому.
Kibana - это программное обеспечение пользовательского интерфейса приборной панели, которое дает пользователю простое взаимодействие с данными, предоставленными и проиндексированными с помощью эластичного поиска. В нашем случае мы использовали Kibana для отображения и агрегирования журналов, которые в нашем случае распределены по нескольким микросервисам и, конечно же, недоступны в одной файловой системе.
Поэтому, когда мы обнаружили, что информация о пользователе может быть получена из журналов из пользовательского интерфейса Kibana, мы увидели, что отправленный объект особенно сложен, даже если остальной вызов, который получает результат, всего один, а именно «search / es» :
Самое сложное при вызове внешнего API в Java - это создание классов POJO для десериализации и сериализации; и учитывая, что мы были в спешке, у нас не было времени на поиск уже созданных классов, и нам не удалось автоматически сгенерировать хорошо выполненные POJOS, начиная с этих сложных объектов JSON.
Итак, вот и оптимизация: избегайте создания POJO и действуйте непосредственно со строками, настраивая HTTP-вызовы, заменяя заполнители в теле объекта, выполняя необходимую сериализацию с помощью Jackson:
Эта операция сэкономила нам время на создание структуры и на повышение ее ценности.
Более структурированный способ должен заключаться в том, чтобы следовать документации Kibana APIS и создавать POJO, но, как вы можете видеть из приведенной ниже ссылки, структура немного сложна:
И, конечно же, проще воспроизвести поиск, выполняемый в веб-клиенте.
В любом случае, мы проделали ту же оптимизацию NO POJO для ответа, когда без демаршалинга объекта мы искали текст, который является префиксом нужного нам результата:
Конечно, остальные вызовы для поиска, как в нашем случае, могут быть более чем одним объединенными: например, используя «resultYouNeed» в приведенном выше фрагменте, вы можете снова выполнить поиск в Kibana, чтобы получить необходимое Информация. В нашем случае у нас была цепочка вызовов для получения сначала «идентификатора корреляции» (строка, которая передается от одного микросервиса к другому для облегчения устранения неполадок журнала), а затем данных, записанных в другом месте журнала.
Остальная часть пакета тривиальна, начиная с объекта List, который содержал строки, идентифицирующие различных пользователей для поиска (мы использовали непосредственно список в классе, содержащий 6000+ идентификаторов, вместо чтения списка из файла) и записывая результат в текстовый файл на каждые 100 итераций:
Как вы понимаете, этот пакет очень быстро реализовать, но результаты не выдаются на 100%, поскольку мы не анализируем ввод и вывод. Тем не менее, нам, к счастью, удалось таким способом восстановить более 95% потерянных данных.
Спасибо за чтение.
