Как отлаживать большое серверное распределенное Java-приложение

Question

Вот моя проблема: я пытаюсь отладить Apache Cassandra и понять, как работает приложение.Т.е. когда клиент отправляет запрос, скажем put (), какие методы вызываются и как система работает внутри.

Итак, вот что я думаю:

1. Напишите метод main в коде cassandra, который вызывает метод точки входа put (), ставит точки останова в eclipse и т. Д. И т. Д. ИЛИ
2. Не пишите метод main, просто используйте обычный клиент (который обращается к серверу черезTCP) и «отладка» (путем чтения файлов журнала и понимания кода) с помощью log4j-регистраторов (уже реализованных в cassandra).

Итак, мой вопрос, что является идеальным способом отладки такихраспределенное приложение?

Answer 1

Идеальный способ?И то, и другое.

Вы упомянули цели: «отладка» и «понять поток приложения» - хорошо, очень сложно отладить, прежде чем вы поймете поток, но понимание может быть самоцелью.

В реальном мире при работе с большими распределенными системами часто нельзя полагаться на отладчики, по крайней мере на начальном этапе, не в последнюю очередь потому, что некоторые проблемы появляются только тогда, когда система занята или после нескольких часов работы.Следовательно, хорошая трассировка отладки и детальный контроль над этой трассировкой в ​​коде приложения и инфраструктурном коде крайне важны.

Однако, если у вас есть возможность работать в отладчике, который может быть достаточно ярким.

Прежде всего, я думаю, вам нужно:

а).Изучите любую проектную документацию, которая может быть.

b).Просмотрите исходный код в хорошей IDE, например.Затмение.Просто следуйте за контролем.Хм, вот интересный момент, интересно, откуда это вызывается?Вызов этого метода в классе, что это делает?Когда вызывается этот конструктор?

С некоторыми из этих вещей в вашей голове следовать трассировке намного проще, и у вас есть лучшее представление о том, где поставить точки останова.

Answer 2

Использование журналов, при необходимости увеличьте уровни журналов и добавьте больше операторов журналов. в различных компонентах распределенной системы профилируйте различные компоненты, такие как база данных, сервер приложений, анализируйте трассировку стека, используйте инструменты отладки во встроенном веб-приложении внешнего браузера, а также в конечных точках останова

Answer 3

Использование регистрации в распределенном приложении - действительно один из лучших способов выяснить, что на самом деле происходит в более широком масштабе и как вещи взаимодействуют. Но в конечном итоге вы столкнетесь с проблемой с файлами журналов - распределенные системы могут генерировать их в разных форматах и ​​местах. Поэтому, если вы хотите использовать log4j (или аналогичные) для подобных вещей, вам следует объединить журналы в одном месте, а затем изучить их. Этот инструмент может помочь, - он позволяет не только постоянную агрегацию, но и мониторинг агрегированного потока журнала в реальном времени из различных источников. Например, вы можете сосредоточиться на слое данных с определенного хоста (или диапазона хостов) и наблюдать в реальном времени, что происходит. В качестве альтернативы вы можете получить журналы из определенного потока на определенном компьютере или использовать контекст MDC, как уже упоминалось в предыдущем постере. Я также согласен с мнением, что отладчик в распределенных приложениях в большинстве случаев бесполезен и совершенно бесполезен в производственных системах по очевидным причинам. Log4j, с другой стороны, невероятно гибок, широко используется и является одним из лучших инструментов (IMHO) для ведения журналов.

Answer 4

Как насчет использования log4j MDC , установки его непосредственно перед put() и последующей очистки после выхода из put()?Затем вы можете увидеть, что на самом деле там произошло, при условии, что у вас есть другие настройки ведения журналов в методах, которые выполняются внутри put().Если вы где-то в этом методе deep , время от времени регистрируйте трассировку стека, чтобы вы могли видеть, где вы находитесь в данный момент.

Отказ от ответственности: Мой список приоритетов отладки выглядит следующим образом:

1. проверка трассировки стека
2. проверка файлов журнала
3. использование отладчика

Итак, если 1. и 2. не даютмне ответ, я прибегну к отладчику.

В таком распределенном приложении использование отладчика звучит как последнее средство.