Zabbix - мониторинг кластера. Вопрос

[sadman]

Вроде сделал, но при запросе данных возвращается Get value error: cannot resolve [zabbix_service_clustered]

Полагаю, что вы не скопировали у меня пример dns-записи ресурса кластера, а свой подставляете. Излишне имя подрезается до опр. длины - архаика WINS-технологий.

ping -a <то, что написано в Listen IP>
или
Диспетчер отказоустойчивости -> Службы и приложения -> <кластерный сервис заббикса>. В нижней части будет "Имя клиента для доступа". По нему и надо ходить zabbix_get-ом. Или прямо по IP ресурса.

C:\Zabbix_agent\zabbix_agentd.exe -c C:\Zabbix_agent\zabbix_agentd_NODE1.conf -i
C:\Zabbix_agent\zabbix_agentd.exe -c C:\Zabbix_agent\zabbix_agentd.conf -s

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

[svyaznoy]

Попробую добить этот вопрос.
Если вручную запустить службу Zabbix_agent (Cluster), то выдается сообщение об ошибке, служба соответственно не запускается.
Error 1053 The srvice did not respond to the start or control request in a timely fashion


У вас эта служба работает? Считаю, что косяк в этом.

[svyaznoy]

Вроде получилось. Службы запускаются

[svyaznoy]

Какой триггер можно создать, чтобы он срабатывал при смене активной ноды?
Посмотрел все возможные ключи, подходящего не определил.

[pzabortsev]

А что у вас в итоге получилось? Что мониторится?

[svyaznoy]

В итоге у меня мониторится активная нода в кластере. Если активная нода по каким-либо причинам меняется, то срабатывает триггер.
Что ещё можно мониторить, пока на ум не приходит(именно из кластерных сервисов). Все основные параметры состояния системы прикручены к конкретным нодам.

[sadman]

Что ещё можно мониторить, пока на ум не приходит(именно из кластерных сервисов). Все основные параметры состояния системы прикручены к конкретным нодам.

Вот это тоже меня интересует - что вы в кластере хотели мониторить... Я тоже ничего не мог придумать существенного.

Тут интересней с кластера брать ноды, пробегаться по ним и брать агрегированные показатели по памяти, частотам процессора, дискам. Как в Veeam One сделано.

[sadman]

Воскресим немножко труп.

В ходе перечитывания документации Zabbix-a я наткнулся на ключ -m, который понимает Zabbix agent для Microsoft Windows:

You can run a single instance of Zabbix agent or multiple instances of the agent on a Microsoft Windows host. A single instance can use the default configuration file C:\zabbix_agentd.conf or a configuration file specified in the command line. In case of multiple instances each agent instance must have its own configuration file (one of the instances can use the default configuration file).

Таким образом, с его помощью можно избежать применения sc.exe с ее монстрообразным синтаксисом и интеграцию обычного агента с кластерным произвести следующим образом:

zabbix_agentd.exe -c c:\zabbix\zabbix_agentd.conf  -i -m
zabbix_agentd.exe -c c:\zabbix\zabbix_agentd.conf  -s -m
zabbix_agentd.exe -c c:\zabbix\zabbix_agentd_cluster.conf  -i -m

Быстро, просто, без ошибок. Сервисы, естественно, устанавливать на каждом узле кластера.

Перезапуск/удаление некластерного агента следует производить так же, с -m. Кластерный агент запускается автоматически при переходе создаваемого впоследствии ресурса Универсальная служба в оперативный режим. Специально стартовать его не надо.

В zabbix_agentd.conf особых изменений вносить не требуется.

В zabbix_agentd_cluster.conf на всех узлах кластера должны совпадать все критичные параметры (в идеале - он один и тот же для всех узлов), исключение можно сделать для UserParameter, который позволит понять, кто текущий владелец службы (для целей отладки). IP-адрес (так же одинаковый для всех экземпляров кластерного агента) следует указать такой, какой позднее будет указан при настройке ресурса Универсальная служба в Диспетчере отказоустойчивости - необходимо определиться с ним заранее.

Далее учите PowerShell и извлекайте нужные вам метрики: https://technet.microsoft.com/en-us/.../ee461009.aspx

[pzabortsev]

Отличный ключик, спасибо! ))

Однако мне до сих пор не ясен способ мониторинга несущего узла кластера (или активной ноды - без разницы).

Вот пример:
Предположим, адрес кластера у нас 10.0.0.10.
В кластере несколько узлов: 10.0.0.1, 10.0.0.2, 10.0.0.3 и т.д.
Кластерную службу агента zabbix не удается повесить на адрес кластера. Ок, вешаем ее на адрес 10.0.0.11.

Предположим, что сейчас несущий узел с адресом 10.0.0.10 - первый из перечисленных. Таким образом на первом узле висят два адреса - 10.0.0.1 и 10.0.0.10.
Служба кластерного агента zabbix с адресом 10.0.0.11 тоже висит на первом.

Агент Zabbix отвечает с адреса 10.0.0.1 (это некластерный агент) и с адреса 10.0.0.11 - этот мониторит ресурсы несущего узла (например, параметры CSV). Все хорошо.

Дальше что-то случается с первым узлом (для простоты предположим что он тупо упал). Несущим узлом становится второй узел с адресом 10.0.0.2. Но служба кластерного агента zabbix переезжает на третий узел (никто же ей не запрещает, она никак не связана с адресом несущего узла). И теперь уже по адресу 10.0.0.11 мы мониторим нифига не несущий узел (он у нас на втором узле, и адрес у него 10.0.0.10).

Как сделать, чтобы служба кластерного агента zabbix гарантированно запускалась на несущем узле?

[sadman]

Отличный ключик, спасибо! ))

Однако мне до сих пор не ясен способ мониторинга несущего узла кластера (или активной ноды - без разницы).
...
Как сделать, чтобы служба кластерного агента zabbix гарантированно запускалась на несущем узле?

Я, конечно, сильно отказоустойчивый кластер не ковырял, может поэтому не могу понять что дает zabbix_agent запущенный именно на узле, обозначенном, как текущий несущий сервер.
У меня три ноды (00, 01, 02) в кластере, VM-ки размазаны по всем трем. На данный момент владелец диска с кворумом - 01, владелец одного CSV - 00, другого CSV - 02. Что мне дает отказоустойчивая служба zabbix - понимаю - возможность получить метрику кластера в любом раскладе, пока он жив. Что дает привязка службы к несущему серверу - не понимаю.

[pzabortsev]

Видимо мое желание привязать zabbix agent именно к несущему узлу вытекает из непонимания работы кластера. Если так разобраться, вовсе не важно, на каком из узлов кластера работает кластерная служба zabbix agent, лишь бы она выдавала информацию, касающуюся именно сластерных служб, а не конкретного хоста.
Например, что меня волнует сейчас больше всего, данные о состоянии CSV можно получать именно с кластерного zabbix agent (сейчас у меня все узлы кластера дискаверят CSV и передают пять одинаковых наборов данных на zabbix server).
Спасибо, вроде все становится на свои места ))

[pzabortsev]

btw:
Вот небольшая инструкция, по которой мы создаем кластерные службы:
1.Создать отдельный конфиг-файл zabbix_agentd_CLUSTER.conf. Изменить следующие параметры:

    LogFile=C:\Program Files\Zabbix Agent\zabbix_agentd_CLUSTER.log
    ListenIP=10.XXX.XXX.XXX     <---- IP адрес кластерной службы zabbix agent
    Hostname=CHV01              <---- Имя кластера

2.Создать службу для мониторинг кластера:

    PS> New-Service -Name "Zabbix Agent (Cluster)" -BinaryPathName '"C:\Program Files\Zabbix Agent\zabbix_agentd.exe" --config "C:\Program Files\Zabbix Agent\zabbix_agentd_CLUSTER.conf"' -StartupType Manual -DisplayName "Zabbix Agent (Cluster)" -Description "Provides cluster monitoring"

3.Повторить пп.1 и 2 на всех узлах кластера

По-моему, на powershell выглядит установка проще

[sadman]

А что и как мониторите в кластере? Я вот пока только накидал такое для CSV

# Name: getpartitioninfo.ps1
# Use: getpartitioninfo.ps1 -CSVName "Name of volume" -ClusterName "Name of cluster" -Metric Metric
# Some metrics: 
#      FreeSpace   - Free Space on CSV
#      PercentFree - Free Space on CSV in %
#      Size        - Size of CSV
#      UsedSpace   - Used Space on CSV
#

Param (
[string]$CSVName,             # f.king windows and rus codepages. need to play with cp866/1251 in command line
[string]$ClusterName,
[string]$Metric
)

# Import the cmdlets
Import-Module failoverclusters

$objCluster=Get-Cluster -Name $ClusterName

$CSV = $objCluster | Get-ClusterSharedVolume -Name $CSVName
$Partition = $CSV | select -Expand SharedVolumeInfo | select -Expand Partition 
$Partition.$Metric

# Uncomment below string to see all metrics
# $Partition

[pzabortsev]

Пока самое полезное - это конечно же мониторинг CSV.
У меня работает такой скрипт:

param(
    [Parameter(Mandatory=$False)]
    [string]$QueryName,
    [string]$FSName
)

if ($QueryName -eq '') {
   
    $colItems = gwmi win32_volume | select Name,FileSystem

    write-host "{"
    write-host " `"data`":["

    foreach ($objItem in $colItems) {
        if ($objItem.FileSystem -eq 'CSVFS') {
            $objItem.Name = $objItem.Name -replace "\\","/"
            $line = " { `"{#FSNAME}`":`"" + $objItem.Name + "`", `"{#FSTYPE}`":`"" + $objItem.FileSystem + "`" },"
            write-host $line
        }
    }

    write-host " ]"
    write-host "}"
}

else {
    $FSName = $FSName -replace "/","\\"
    
    switch ($QueryName) {
        ('Capacity')  { $Results = gwmi win32_volume -Filter "name = '$FSName'" | select Capacity | Format-Table -HideTableHeaders -AutoSize }
        ('FreeSpace') { $Results = gwmi win32_volume -Filter "name = '$FSName'" | select FreeSpace | Format-Table -HideTableHeaders -AutoSize }
        default       { $Results = "Incorrect Command: '" + $QueryName + "'" }
        }
    $Results = $Results | Out-String
    $Results = $Results.trim()
    Write-Host $Results

}

Ну и пара параметров настроена:

UserParameter=CSVFS.discover,powershell.exe -file "C:\Program Files\Zabbix Agent\scripts\CSVFS_Status.ps1"              
UserParameter=CSVFS.check[*],powershell.exe -file "C:\Program Files\Zabbix Agent\scripts\CSVFS_Status.ps1" $1 $2

Параметр CSVFS.discover используется для дискаверинга CSV.
В прототипы берутся два параметра:

CSVFS.check["Capacity", "{#FSNAME}"]
CSVFS.check["FreeSpace", "{#FSNAME}"]

Остальное (pfree, pused, used) - вычисляемые параметры считает zabbix server по этим двум.

[Navoyenok]

Доброго времени суток.

Не могу не внести "своих трех копеек".

Что касается мониторинга кластера, то у нас сделано так:

1. Все данные поделены на две категории: данные узла и данные кластера
2. На каждом узле запущены два экземпляра zabbix-агента: один для получения данных узла, другой - для получения данных кластера
3. Экземпляр zabbix-агента для получения данных кластера работает как служба кластера.

К кластерным данным относится все что является кластерным ресурсом: ip-адрес, дисковые ресурсы (в том числе и кворумные) и нет смысла искать какой узел активный.

Такое разделение позволило избежать построения каких-то там сложных триггеров и существенно упростило внедрение мониторинга кластеров Windows.

С уважением, Navoyenok