В чем разница между jolokia & jmxtrans? Когда выбирать один над другим?

Ответ 1

Я автор jmxtrans. Я рассматривал Jolokia, прежде чем я разработал jmxtrans. Я решил развиваться с помощью jmxtrans, потому что у меня был другой смысл.

Jolokia работает как война в Tomcat. Он похож на jmxtrans на то, что он позволяет запрашивать сервер JMX, но это касается того, где заканчивается сходство. Вам нужно будет реализовать остальные jmxtrans поверх Jolokia, чтобы иметь паритет характеристик.

С другой стороны, jmxtrans является автономным без каких-либо требований к Tomcat. Моя целевая аудитория - это роль netops/devops. Он сконфигурирован с относительно простой структурой на основе JSON, поэтому для его настройки и использования не требуется инженерная степень.

Мысль о том, что вы используете jmxtrans для непрерывного мониторинга служб, которые выставляют статистику через jmx. Вы используете jmxtrans для преобразования данных из jmx в любой желаемый формат вывода. Как правило, декомпиляторы хотят интегрировать свои JVM с каким-то мониторинжным решением, таким как Graphite/Ganglia, поэтому я предоставил записи для этих инструментов.

jmxtrans также очень хорошо разбирается в том, как он выполняет запросы с серверами jmx, и для этого есть немного оптимизации. Также есть много работы, чтобы позволить вам делать такие вещи, как распараллеливать запросы на многие серверы, чтобы вы могли масштабировать jmxtrans для непрерывного запроса сотен серверов с помощью одного экземпляра jmxtrans.

Я надеюсь, что это немного прояснит ситуацию. Если у вас есть какие-то конкретные вопросы, я рад ответить на них.

Ответ 2

Действительно, jmxtrans и Jolokia имеют другой фокус. Jmxtrans - это полное решение для мониторинга с планировщиком, который периодически запрашивает запрос JMX и отправляет результаты на бэкэнд, например графит или rrdtool. Он использует стандартную связь JSR-160 (RMI) для запросов к Java-серверам с поддержкой Java JMX

Jolokia, с другой стороны, это адаптер HTTP/JSON-JMX, который обеспечивает легкий доступ для не-Java-клиентов и добавляет некоторые уникальные функции, которые недоступны для чистой реализации JSR-160. Для интеграции в платформу мониторинга требуется еще одна часть программного обеспечения. Для Nagios существует Jmx4Perl, который предоставляет полнофункциональный плагин Nagios для запросов к агентам Jolokia.

Поскольку я автор Jolokia, позвольте мне подчеркнуть некоторые моменты Jolokia

• Многие запросы могут быть отправлены сразу в виде одиночных запросов. Это позволяет запрашивать сотни атрибутов с одним HTTP-обращением. Это действительно имеет огромное значение в больших средах.
• Из-за использования HTTP Jolokia позволяет легко запрашивать границы брандмауэра (что является кошмаром при использовании стандартных разъемов JMX).
• Тонкозернистая авторизация легко возможна с помощью простого файла политики XML
• Агенты доступны не только для Tomcat или любого другого контейнера Java EE, но также для любого приложения Java 6 (например, ActiveMQ или Camel).
• Хороший набор инструментов командной строки (например, оболочка JMX на основе readline с контекстно-зависимым завершением команды) поставляется с Jmx4Perl.
• Доступны библиотеки доступа из Perl, Javascript, Python,...
• .... Для получения дополнительной информации см. www.jolokia.org

Подводя итог, я думаю, вы должны использовать jmxtrans, когда вам нужно полное решение для мониторинга на основе удаленного JSR-160 (однако вы также можете использовать Nagios и check_jmx4perl) и Jolokia, когда вам нужно преодолеть ограничения JSR-160 или можете пользу от одной из ее уникальных особенностей. Можно даже представить, как интегрировать Jolokia в jmxtrans для связи с серверами для мониторинга, которые затем перейдут через JSON/HTTP вместо JSR-160 RMI (возможно, это также прояснит разницу фокуса и поддерживаемый вариант использования).

Ответ 3

позвольте мне добавить еще один проект на стол - https://github.com/dimovelev/metrics-sampler он запрашивает данные JMX, используя регулярные выражения и замену переменных, а также поддерживает запросы JDBC в качестве источников метрик (в основном для мониторинга наших данных о dac файлах) и mod_qos для материала apache mod_qos. Нам нужен графит только как вывод, и это единственный результат, который он в настоящее время поддерживает.

Кстати, IMHO порты JMX проблематичны с брандмауэрами только потому, что горячая точка выбирает случайный эфемерный порт при запуске. С помощью jrockit он может быть указан (в том же порту, что и в реестре) со стандартным вариантом jvm. Чтобы сделать это в точке доступа, вам нужно самому закодировать его (или повторно использовать код, например, из разъема tomcat jmx). Приятная часть состоит в том, что нормально устанавливать оба порта на одно и то же значение, поэтому требуется только одно правило брандмауэра.

Приветствия Димо