Мониторинг java-процессов по snmp
Материал из BiTel WiKi
(→Настройка в Cacti) |
|||
(7 промежуточных версий не показаны.) | |||
Строка 109: | Строка 109: | ||
</source> | </source> | ||
- | и | + | Устанавливаем права доступа к нему: |
+ | <source lang="bash"> | ||
+ | chmod 400 snmp.acl | ||
+ | </source> | ||
+ | Если права не задать, jvm будет ругаться и не запустится: | ||
+ | <source lang="text">Error: Password file read access must be restricted: ./data/snmp.acl</source> | ||
+ | |||
+ | Помещаем его копию в директории: | ||
<source lang="bash"> | <source lang="bash"> | ||
/usr/local/BGBillingServer/data/ | /usr/local/BGBillingServer/data/ | ||
Строка 138: | Строка 145: | ||
<p>Настроим мониторинг памяти</p> | <p>Настроим мониторинг памяти</p> | ||
+ | |||
+ | <p>Шаблон для графиков:[[Файл:java_memory.template.zip]]</p> | ||
<p>Получаем список параметров: | <p>Получаем список параметров: | ||
<source lang="bash"> | <source lang="bash"> | ||
- | snmpwalk -c public -v 2c -m ALL 192.168.1.101:10165 . | grep Memory | + | >snmpwalk -c public -v 2c -m ALL 192.168.1.101:10165 . | grep Memory |
JVM-MANAGEMENT-MIB::jvmMemoryPendingFinalCount.0 = Gauge32: 0 | JVM-MANAGEMENT-MIB::jvmMemoryPendingFinalCount.0 = Gauge32: 0 | ||
JVM-MANAGEMENT-MIB::jvmMemoryGCVerboseLevel.0 = INTEGER: silent(1) | JVM-MANAGEMENT-MIB::jvmMemoryGCVerboseLevel.0 = INTEGER: silent(1) | ||
Строка 164: | Строка 173: | ||
<li/>HeapMax - Максимальная планка выделяемой памяти для данных приложения. Устанавливается через параметр -Xmx при старте | <li/>HeapMax - Максимальная планка выделяемой памяти для данных приложения. Устанавливается через параметр -Xmx при старте | ||
- | <li/>NonHeap - то же | + | <li/>NonHeap... - то же, что и Heap..., только касаемо памяти, используемой самой jvm для собственнхы нужд. |
</ul> | </ul> | ||
</p> | </p> |
Текущая версия на 01:04, 16 февраля 2012
Содержание |
Описание
В стандартной поставке java есть пакет [1], позволяющий мониторить JVM по протоколу SNMP. В частности, можно следить за использованием памяти процессами биллинга с помощью систем мониторинга.
Например:
Настройка агента
В каждом процессе биллинга в jvm создаётся snmp-агент, слушающий определённый порт. Сам агент потребляет очень мало ресурсов - буквально пару MB виртуальной памяти.
Для настройки snmp-агента прописываем в строке запуска приложения несколько дополнительных параметров:
-Dcom.sun.management.snmp.port=<port> -Dcom.sun.management.snmp.acl.file=<путь_к_вашему_snmp.acl> -Dcom.sun.management.snmp.interface=<ip-адрес интерфейса, который будем слушать>
Дефолтный snmp.acl можно взять из JAVA_HOME/lib/management/snmp.acl
Рабочий пример - настраиваем агента для BGBilling, BGDataloader, BGScheduler, BGRadiusDialup, BGIPNNetflowCollector:
- BGBilling:
java \ -Dapp.name=BGBillingServer \ -Dnetworkaddress.cache.ttl=3600 \ -Dcom.sun.management.snmp.port=10165 \ -Dcom.sun.management.snmp.acl.file=./data/snmp.acl \ -Dcom.sun.management.snmp.interface=192.168.1.101 \ -Xmx2048m \ -cp .:./lib/* \ ru.bitel.common.bootstrap.Boot bitel.billing.server.Server start
- BGDataloader:
java \ -Dapp.name=BGDataLoader \ -Dnetworkaddress.cache.ttl=3600 \ -Dcom.sun.management.snmp.port=10161 \ -Dcom.sun.management.snmp.acl.file=./data/snmp.acl \ -Dcom.sun.management.snmp.interface=192.168.1.101 \ -Xmx1740m \ -cp .:./lib/* \ ru.bitel.common.bootstrap.Boot bitel.billing.server.DataLoader -estart
- BGScheduler:
java \ -Dapp.name=BGScheduler \ -Dcom.sun.management.snmp.port=10167 \ -Dcom.sun.management.snmp.acl.file=./data/snmp.acl \ -Dcom.sun.management.snmp.interface=192.168.1.201 \ -Xmx2560m \ -cp .:./lib/* \ ru.bitel.common.bootstrap.Boot bitel.billing.server.TaskExecuter -estart
- BGRadiusDialup:
java \ -Djava.net.preferIPv4Stack=true \ -Dapp.name=BGRadiusDialup \ -Dcom.sun.management.snmp.port=10163 \ -Dcom.sun.management.snmp.acl.file=./snmp.acl \ -Dcom.sun.management.snmp.interface=192.168.1.101 \ -Xmx768m \ -Dlog4j.configuration=log4j-radius.xml \ -Dlog.dir.path=log/ \ -cp .:./lib/* \ bitel.billing.server.radius.Radius start
- BGIPNNetflowCollector:
java \ -Dapp.name=BGIPNNetflowCollector \ -Dlog4j.configuration=log4j-collector.xml \ -Dlog.dir.path=log/ \ -Djava.awt.headless=true \ -Dfile.encoding=utf-8 \ -Dnetworkaddress.cache.ttl=3600 \ -Dcom.sun.management.snmp.port=10166 \ -Dcom.sun.management.snmp.acl.file=snmp.acl \ -Dcom.sun.management.snmp.interface=192.168.1.201 \ -Xmx512m \ bitel.billing.server.netflow.ipn.Collector start
Создаём файлик snmp.acl:
acl = { { communities = public, private access = read-only managers = localhost, 192.168.1.101, 192.168.1.151 } } #managers - список хостов, имеющих доступ к агенту в указанных community
Устанавливаем права доступа к нему:
chmod 400 snmp.acl
Если права не задать, jvm будет ругаться и не запустится:
Error: Password file read access must be restricted: ./data/snmp.acl
Помещаем его копию в директории:
/usr/local/BGBillingServer/data/ /usr/local/BGRadiusDialup/ /usr/local/BGIPNNetflowCollector/
Указанные порты должны быть незаняты и доступны с хоста системы мониторинга (в нашем случае - 192.168.1.151)
Пробуем запустить, убеждаемся, что всё работает.
Проверяем, заодно получаем список доступных для мониторинга и управления параметров:
snmpwalk -c public -v 2c -m ALL 192.168.1.101:10165 .
...и так далее для всех настроенных ранее портов.
Hint - для читабельного представления параметров нужно установить соответствующий MIB-файл ([2]):
cd /usr/share/snmp/mibs wget http://download.oracle.com/javase/1.5.0/docs/guide/management/JVM-MANAGEMENT-MIB.mib
Настройка в Cacti
Настроим мониторинг памяти
Шаблон для графиков:Файл:Java memory.template.zip
Получаем список параметров:
>snmpwalk -c public -v 2c -m ALL 192.168.1.101:10165 . | grep Memory JVM-MANAGEMENT-MIB::jvmMemoryPendingFinalCount.0 = Gauge32: 0 JVM-MANAGEMENT-MIB::jvmMemoryGCVerboseLevel.0 = INTEGER: silent(1) JVM-MANAGEMENT-MIB::jvmMemoryGCCall.0 = INTEGER: supported(2) JVM-MANAGEMENT-MIB::jvmMemoryHeapInitSize.0 = Counter64: 129598464 bytes JVM-MANAGEMENT-MIB::jvmMemoryHeapUsed.0 = Counter64: 803092336 bytes JVM-MANAGEMENT-MIB::jvmMemoryHeapCommitted.0 = Counter64: 1064042496 bytes JVM-MANAGEMENT-MIB::jvmMemoryHeapMaxSize.0 = Counter64: 1908932608 bytes JVM-MANAGEMENT-MIB::jvmMemoryNonHeapInitSize.0 = Counter64: 24313856 bytes JVM-MANAGEMENT-MIB::jvmMemoryNonHeapUsed.0 = Counter64: 103298512 bytes JVM-MANAGEMENT-MIB::jvmMemoryNonHeapCommitted.0 = Counter64: 108658688 bytes JVM-MANAGEMENT-MIB::jvmMemoryNonHeapMaxSize.0 = Counter64: 138412032 bytes
- HeapInit - изначально выделенная jvm память для приложения
- HeapUsed - Реально используемая приложением память (включая структуры, которые уже не нужны, но ещё не собраны сборщиком мусора)
- HeapCommitted - Запрошенная виртуальная память у ОС для данных приложения. Самый интересный параметр.
- HeapMax - Максимальная планка выделяемой памяти для данных приложения. Устанавливается через параметр -Xmx при старте
- NonHeap... - то же, что и Heap..., только касаемо памяти, используемой самой jvm для собственнхы нужд.
Получаем OID-ы для соответствующих параметров:
>snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryHeapInitSize.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.10.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryHeapUsed.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.11.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryHeapCommitted.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.12.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryHeapMaxSize.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.13.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryNonHeapInitSize.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.20.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryNonHeapUsed.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.21.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryNonHeapCommitted.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.22.0 >snmptranslate -On -m ALL JVM-MANAGEMENT-MIB::jvmMemoryNonHeapMaxSize.0 .1.3.6.1.4.1.42.2.145.3.163.1.1.2.23.0
Создаём соответствующие Data Template-ы в Cacti: По аналогии остальные:
Создаём device для каждого мониторящегося процесса:
Создаём Template Based график.
Смотрим и радуемся:
PS
Можно настроить и другие параметры, а также попробовать управлять jvm через snmp. Также можно настроить трапы (конфигурируются в snmp.acl). Но список доступных MIB-ов ограничен стандартными. Т.е. никакие специфичные для конкретного приложения данные (например, число коннектов к бд) вытащить по snmp не удастся.
Если придумаете что-то интересное, отпишитесь на форуме :)
--Cromeshnic 07:57, 11 января 2011 (UTC)