NetXMS Support Forum

сейчас перепроверил:

прошло ~30 минут, а каунтеры

AverageDiskReadQueueLenght:"\PhysicalDisk(2 T:)\Avg. Disk Read Queue Length":60:A:INT:"Average Disk T: Read Queue Length"

и

AverageDiskWriteQueueLenght:"\PhysicalDisk(2 T:)\Avg. Disk Write Queue Length":60:A:INT:"Average Disk T: Write Queue Length"

по прежнему возвращают только "0". "Show history" показывает только "0".

А вот бы было здорово реализовать для мониторинга сервиса DNS что-то в таком роде:

Quote from: Victor Kirhenshtein on May 28, 2009, 10:55:07 AM
A kakie znachenija na samom dele u etih counterov?

вот, я сделал небольшую урезанную выборку штатными средствами perfmon'а.


"(PDH-CSV 4.0) (Russian Daylight Time)(-240)","\\MYSERVER\PhysicalDisk(2 T:)\Avg. Disk Read Queue Length","\\MYSERVER\PhysicalDisk(2 T:)\Avg. Disk Write Queue Length"
"05/28/2009 12:09:24.908"," "," "
"05/28/2009 12:11:07.347","0","0"
"05/28/2009 12:11:08.348","0","0"
"05/28/2009 12:11:09.363","0.022350340104239228","0"
"05/28/2009 12:11:10.379","0","0"
"05/28/2009 12:11:11.379","0","0"
"05/28/2009 12:14:04.960","0","0"
"05/28/2009 12:14:15.960","0","0"
"05/28/2009 12:14:16.961","0.010499798403870646","0"
"05/28/2009 12:14:17.961","0","0"
"05/28/2009 12:14:18.976","0","0"
"05/28/2009 12:14:19.976","0","0.078398494748900815"
"05/28/2009 12:14:20.976","0","0"
"05/28/2009 12:14:21.976","0","0"
"05/28/2009 12:14:22.976","0","0"
"05/28/2009 12:14:23.976","0","0"
"05/28/2009 12:14:24.976","0","0.029299437450800946"
"05/28/2009 12:14:25.976","0","0"
"05/28/2009 12:14:26.976","0","0"
"05/28/2009 12:14:27.976","0","0"
"05/28/2009 12:14:28.976","0","0"
"05/28/2009 12:14:29.976","0","0.061698815382744653"
"05/28/2009 12:14:30.976","0","0"
"05/28/2009 12:14:31.976","0","0"
"05/28/2009 12:15:11.180","0","0"
"05/28/2009 12:15:12.180","0","0"

может чтото нужно особым образом настраивать в DCI (например Average Delta?)

я кстати по наивности думал что при добавлении своего канутера на Агенте его имя будет светиться в общем списке при нажатии на кнопку "Select" при создании DCI.

=))

я уже попробовал =)

это отчасти помогает, но в целом ситуацию не улучшает: агент начинает загружаться без ошибок, но возвращаемое каунтерами (AverageDiskReadQueueLenght и AverageDiskWriteQueueLenght) значение всегда равно "0".

возникло небольшое непонимание, прошу разъяснить на будущее...

пытаюсь использовать вот такой каунтер (через конфиг Агента):

AverageDiskWriteQueueLenght:"\PhysicalDisk(2 T:)\Avg. Disk Write Queue Length":60:A:INT:Avgerage Disk T: Write Queue Length

и получаю вот такую ошибку при загрузке Агента

Unable to add counter from configuration file. Original configuration record: AverageDiskWriteQueueLenght:"\PhysicalDisk(2 T:)\Avg. Disk Write Queue Length":60:A:INT:Avgerage Disk T: Write Queue Length

не подскажете, в чём моя ошибка? просто эта ошибка ни о чём не говорит конкретно.. =(

PS: замена AverageDiskWriteQueueLenght на Avg. Disk Write Queue Lenght и соответственно AverageDiskReadQueueLenght на Avg. Disk Read Queue Lenght ничего не даёт =(

Unable to add counter from configuration file. Original configuration record: Avg. Disk Write Queue Length:"\PhysicalDisk(2 T:)\Avg. Disk Write Queue Length":60:A:INT:Avgerage Disk T: Write Queue Length

приветствую! =)

небольшой вопросец:

System.IO.DiskQueue - FLOAT - "Average disk queue length for last minute"

это

PDH.CounterValue("\PhysicalDisk(2 C:)\Avg. Disk Write Queue Length")

или

PDH.CounterValue("\PhysicalDisk(2 T:)\Avg. Disk Read Queue Length")

или это _Total?

Is it possible to use other multi-sample counters (like "\PhysicalDisk(_Total)\Disk Write Bytes/sec") via interface, not via client's config?

полностью согласен, абсолютно адекватное решение проблемы =)
а когда можно ориентировочно ожидать воплощения решения в жизнь?

напоминаю про наш предыдущий разговор (на всякий случай) и новая порция данных для размышления...

обнаружил странную вещь.

объект мониторинга: двухузловой актив-актив кластер с MSSQL. на его обеих нодах крутятся по одному SQL-инстансу, в случае обвала одной из нод оба инстанса начинают работать на одной ноде.

мы отслеживаем, что:

1) инстансы вообще живы.
2) оба инстанса не запущены на одной ноде одновременно, если так- слать аларм оператору.
3) состояние кластерных ресурсных групп в норме.

с 3) нет проблем, всё отслеживается отлично. получаю сообщения о переезде ресурсных групп с ноды на ноду.
с 2) возникает периодически проблема. я не знаю, почему оно так, но Condition, созданный для слежения за расположением инстансов, постоянно "залипает". т.е. реакция на нормальное расположение инстансов (один инстанс-одна нода) происходит либо с ооочень большим замедлением (могут сутки пройти, прежде чем монитр чухнется, что всё уже ок, что выполняется условие "один истанс-одна нода"), либо не происходит вообще. приходится руками передёргивать мониторинг.

вот скрипт используемый в Condition: (($1 == 0) && ($2 ==  0)) || (($3 == 0) && ($4 ==  0))

... где $1-$4 это:

на ноде NODE1

1 - System.ServiceState(MSSQL$INST1) - Associate with cluster resource "INST1 Cluster Group"
2 - System.ServiceState(MSSQL$INST2) - Associate with cluster resource "INST2 Cluster Group"

на ноде NODE2

3 - System.ServiceState(MSSQL$INST2) - Associate with cluster resource "INST2 Cluster Group"
4 - System.ServiceState(MSSQL$INST1) - Associate with cluster resource "INST1 Cluster Group"

может и я чтото напутал при создании DCI, но что-то как-то странно всё...

очень подозрительно выглядит вот что: при использовании в указанной ситуации двух DCI типа System.ServiceState(MSSQL$INST1) и System.ServiceState(MSSQL$INST2), когда оба MSSQL$INSTN приписаны каждый к своей кластерной группе (Asociate with cluster resource) на обих нодах нормально работает только по одному DCI.

на каждой ноде работает (регулярно опрашивает) только тот DCI, который связан с кластерной группой, которая, в свою очередь, в данный момент находится именно на ЭТОЙ ноде. второй же ... второй же может сутками, неделями и месяцами не проверяться (я не уловил закономерности). и это не смотря на то, что в случае перемещения инстанса со своей ноды на соседнюю, Condition помечает весь кластер как сбойный.

и получается что при ручном перемещении инстанса обратно на починеную ноду, повторного ПОЛНОГО переопроса кластера не производится. и статус Warning так и висит на Condition'е и кластере.

и вот ещё один вопрос: (по пункту 1)) - можно ли мониторить состояние кластерных ИМЕННО СЕРВИСОВ? и помечать СЕРВИСЫ типа ...

на ноде NODE1

1 - System.ServiceState(MSSQL$INST1) - Associate with cluster resource "INST1 Cluster Group"
2 - System.ServiceState(MSSQL$INST2) - Associate with cluster resource "INST2 Cluster Group"

на ноде NODE2

3 - System.ServiceState(MSSQL$INST2) - Associate with cluster resource "INST2 Cluster Group"
4 - System.ServiceState(MSSQL$INST1) - Associate with cluster resource "INST1 Cluster Group"

... сбойными, как любой стандартный DCI, через трешолды?

Иди это не возможно, потому что каждый такой сервис приписан в DCI к кластерной группе?


ЕСЛИ КОРОЧЕ =)

1. при использовании Condition, отслеживающего расположение инстансов так (($1 == 0) && ($2 ==  0)) || (($3 == 0) && ($4 ==  0)), для кластера с двумя нодами на каждой из которых запущено по одному инстансу, ЕСЛИ указанное условие перестаёт выполняться (расположение приходит в норму), Кластер может очень долго возвращаться в нормальное состояние, поскольку не происходит полного переопроса всех связанных с кластером DCI.

2. не удаётся мониторить состояние инстансов НАПРЯМУЮ, поскольку они могут находиться на любой из нод кластера. и соответственно, нельзя использовать прямой мониторинг через DCI с конкретным указанием на инстансы.

правильное положение:

(($1 == 0) && ($2 !==  0)) || (($3 == 0) && ($4 !==  0))

неправильное положение:

(($1 == 0) && ($2 ==  0)) || (($3 == 0) && ($4 ==  0))

но положение типа (($1 == 0) && ($2 ==  0)) || (($3 == 0) && ($4 ==  0)) хоть и считается не правильным для кластера, но оно может быть необходимо на время реанимации упавшей ноды. но при этом КАК в это время мониторить здоровье инстансов $1 и $2 или $3 и $4, когда они на одной ноде?

может эти DCI всё же можно вынести на уровень КЛАСТЕРА?

UP

тема всё ещё актуальна. как можно создать универсальный рестартер сервисов? что бы не прописывать имя сбойнувшего сервиса в скрипте рестарта в явном виде?

У меня сейчас так же возникла подобная надобность.. Feojazz, как-то решил проблему?
=)

Ситуация: есть удалённая windows-машина, на которой нужно следить за состоянием сервисов. Данная машина доступна только по SNMP, больше никак. На машине (2003) поднят SNMP, на сервер NXMS добавлен LanMgr-Mib-II-MIB.mib и базовый mib пересобран.

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


Проблема: при использовании SNMP для мониторинга windows-сервисов, OID сервиса доступен (присутствует в общем дереве OID'ов) только до тех пор, пока сам сервис запущен. Как только сервис останавливается, OID незамедлительно пропадает и DCI тут же переходит в состояние Not Supported.

Его конечно понять можно, ведь с точки зрения базовой логики поскольку объект отсутствует, то мониторить просто нечего. И введённый OID начинает считаться ошибочным =/.

Пример OID'а.

1. OID раздела сервисов: 1.3.6.1.4.1.77.1.2.3.1. = enterprises.lanmanger.lanmgr-2.server.svSvcEntry.svSvcTable

2. Таблицы с перечнями свойств сервисов

        .1 = svSvcName (.#char.dec-ascii chars, matches service name in service control panel including case)
        .2 = svSvcInstalledState (1-uninstalled,2-install-pending,3-uninstall-pending,4-installed)
        .3 = svSvcOperatingState (1-active, 2-continue-pending, 3-pause-pending, 4-paused)
        .4 = svSvcCanBeUninstalled (1-no, 2-yes)
        .5 = svSvcCanBePaused (1-no, 2-yes)

3. Соответственно, OID'ы сервисов строятся так (на примере Task Scheduler):

OID с названием сервиса: 1.3.6.1.4.1.77.1.2.3.1.1.14.84.97.115.107.32.83.99.104.101.100.117.108.101.114
выдаст "Task Scheduler"

OID с состоянием сервиса: 1.3.6.1.4.1.77.1.2.3.1.3.14.84.97.115.107.32.83.99.104.101.100.117.108.101.114
при запущенном сервисе выдаст "1"

Вопрос: как кто решал подобную проблему? Как через SNMP можно мониторить состояние сервисов если их OID'ы исчезают после остановки или падения сервисов а именно за этим и нужно следить?

Всё бы ничего, да при этом полностью отказывает DCI. И его можно реанимировать только ручками. Что для большого числа хостов и сервисов не приемлемо...

Прошу помочь...

2 Виктор: как в данном случае лучше поступить, что посоветуете? Нельзя ли в будущих релизах NXMS немного изменить подход к SNMP, например добавить при выборе агента "SNMP" специальную галочку, для того чтобы в случае если OID исчезает, мониторинг не считал это поводом просто перестать мониторить заданный OID, а поступал бы так же, как и в случае стандартного события? Вроде такого: OID есть- всё ок, OID'а нет- сгенерировать аларм.

а под каким логином входишь?

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

я про

- Added support for matching Windows event log records by event source,
  severity, and event code

если Вас не затруднит, не могли бы Вы дать несколько примеров по использованию этой новой возможности?