Як слідкувати за обсягами глюстеру


12

Glusterfs, будучи приємною розподіленою файловою системою, не забезпечує майже ніякого способу контролю за її цілісністю. Сервери можуть приїжджати та йти, цегла може застаріти або вийти з ладу, і я боюся знати про це, коли, мабуть, пізно.

Нещодавно у нас стався дивний збій, коли все, здавалося, працювало, але одна цегла випала з об’єму (виявлена ​​за чистим збігом обставин).

Чи є простий і надійний спосіб (сценарій cron?), Який дозволить мені знати про стан здоров’я мого тома GlusterFS 3.2 ?


Зараз ми використовуємо моніторинг на основі сценарію "брудна оболонка": check_gluster.sh
Arie Skliarouk

Погляньте на glfs-health.sh .
кванта

1
Я перевірив glfs-health.sh і, схоже, це для старих версій glusterfs, якими керував файл конфігурації. Я уточню моє питання, щоб представити glusterfs 3.2.
Arie Skliarouk

Відповіді:


3

Це вже деякий час є запитом до розробників GlusterFS, і ви не можете використати нічого нестандартного рішення. Однак з кількома сценаріями це неможливо.

В основному вся система Gluster керується однією командою gluster і, маючи кілька варіантів, ви можете написати сценарії моніторингу стану здоров'я. Тут ви знайдете інформацію про цеглу та томи - http://gluster.org/community/documentation/index.php/Gluster_3.2:_Displaying_Volume_Information

Щоб контролювати продуктивність, перегляньте це посилання - http://gluster.org/community/documentation/index.php/Gluster_3.2:_Monitoring_your_GlusterFS_Workload

ОНОВЛЕННЯ: Розгляньте можливість оновлення до http://gluster.org/community/documentation/index.php/ About_GlusterFS_3.3

Вам завжди краще працювати з останньою версією, оскільки, здається, вони мають більше виправлень помилок і добре підтримуються. Звичайно, запустіть власні тести, перш ніж перейти до новішої версії - http://vbellur.wordpress.com/2012/05/31/upgrading-to-glusterfs-3-3/ :)

Існує посібник адміністратора з певним розділом для моніторингу встановлення GlusterFS 3.3 у розділі 10 - http://www.gluster.org/wp-content/uploads/2012/05/Gluster_File_System-3.3.0-Administration_Guide-en-US .pdf

Дивіться тут ще один сценарій nagios - http://code.google.com/p/glusterfs-status/


Спасибі Чіда, я думаю, що мене затримало те, що деякі люди ( github.com/semiosis/puppet-gluster ) контролюють глюстер через таблицю proc ("- з цеглиною" тощо) та журнали (egrep "E" на помилку), а деякі користуються CLI, і я не маю уявлення, яке більш імовірно точно повідомити про стан глюстера.
r_2

Я рекомендую використовувати CLI, оскільки саме це рекомендує GlusterFS і має бути оновленим.
Чида


2

Перевірте доданий скрипт на веб- сайті https://www.gluster.org/pipermail/gluster-users/2012-June/010709.html на предмет gluster 3.3; це, ймовірно, легко адаптується до блиску 3.2.

#!/bin/bash

# This Nagios script was written against version 3.3 of Gluster.  Older
# versions will most likely not work at all with this monitoring script.
#
# Gluster currently requires elevated permissions to do anything.  In order to
# accommodate this, you need to allow your Nagios user some additional
# permissions via sudo.  The line you want to add will look something like the
# following in /etc/sudoers (or something equivalent):
#
# Defaults:nagios !requiretty
# nagios ALL=(root) NOPASSWD:/usr/sbin/gluster peer status,/usr/sbin/gluster volume list,/usr/sbin/gluster volume heal [[\:graph\:]]* info
#
# That should give us all the access we need to check the status of any
# currently defined peers and volumes.

# define some variables
ME=$(basename -- $0)
SUDO="/usr/bin/sudo"
PIDOF="/sbin/pidof"
GLUSTER="/usr/sbin/gluster"
PEERSTATUS="peer status"
VOLLIST="volume list"
VOLHEAL1="volume heal"
VOLHEAL2="info"
peererror=
volerror=

# check for commands
for cmd in $SUDO $PIDOF $GLUSTER; do
    if [ ! -x "$cmd" ]; then
        echo "$ME UNKNOWN - $cmd not found"
        exit 3
    fi
done

# check for glusterd (management daemon)
if ! $PIDOF glusterd &>/dev/null; then
    echo "$ME CRITICAL - glusterd management daemon not running"
    exit 2
fi

# check for glusterfsd (brick daemon)
if ! $PIDOF glusterfsd &>/dev/null; then
    echo "$ME CRITICAL - glusterfsd brick daemon not running"
    exit 2
fi

# get peer status
peerstatus="peers: "
for peer in $(sudo $GLUSTER $PEERSTATUS | grep '^Hostname: ' | awk '{print $2}'); do
    state=
    state=$(sudo $GLUSTER $PEERSTATUS | grep -A 2 "^Hostname: $peer$" | grep '^State: ' | sed -nre 's/.* \(([[:graph:]]+)\)$/\1/p')
    if [ "$state" != "Connected" ]; then
        peererror=1
    fi
    peerstatus+="$peer/$state "
done

# get volume status
volstatus="volumes: "
for vol in $(sudo $GLUSTER $VOLLIST); do
    thisvolerror=0
    entries=
    for entries in $(sudo $GLUSTER $VOLHEAL1 $vol $VOLHEAL2 | grep '^Number of entries: ' | awk '{print $4}'); do
        if [ "$entries" -gt 0 ]; then
            volerror=1
            let $((thisvolerror+=entries))
        fi
    done
    volstatus+="$vol/$thisvolerror unsynchronized entries "
done

# drop extra space
peerstatus=${peerstatus:0:${#peerstatus}-1}
volstatus=${volstatus:0:${#volstatus}-1}

# set status according to whether any errors occurred
if [ "$peererror" ] || [ "$volerror" ]; then
    status="CRITICAL"
else
    status="OK"
fi

# actual Nagios output
echo "$ME $status $peerstatus $volstatus"

# exit with appropriate value
if [ "$peererror" ] || [ "$volerror" ]; then
    exit 2
else
    exit 0
fi

1

Мені вдалося налаштувати моніторинг нагіосів для glusterfs, як зазначено нижче:

http://gopukrish.wordpress.com/2014/11/16/monitor-glusterfs-using-nagios-plugin/


1
Оскільки з часом посилання зникають, ми вважаємо за краще, якщо ви можете включити суть відповіді сюди на ServerFault.
Ладададада

1

@Arie Skliarouk, у вас check_gluster.shє друкарська помилка - на останньому рядку ви exitstзамість цього натискаєте exist. Я пішов вперед і переписав це, щоб бути трохи більш компактним, і видалити вимогу до тимчасового файлу.

#!/bin/bash

# Ensure that all peers are connected
gluster peer status | grep -q Disconnected && echo "Peer disconnected." && exit 1

# Ensure that all bricks have a running log file (i.e., are sending/receiving)
for vol in $(gluster volume list); do
  for brick in $(gluster volume info "$vol" | awk '/^Brick[0-9]*:/ {print $2}'); do
    gluster volume log locate "$vol" "$brick";
  done;
done |
 grep -qE "does not (exist|exitst)" &&
 echo "Log file missing - $vol/$brick ." &&
 exit 1

1
Друкарська помилка "exitst" - це те, що записано в журналах. Я не купую "компактну" перевагу - сценарій набагато складніше зрозуміти, коли рядки перевантажені. Тимчасовий файл - це дешева ціна, яку можна оплатити за зрозумілий код.
Arie Skliarouk

@ArieSkliarouk: оновлено, щоб охопити обидва випадки, але попередити, що відповідне повідомлення було видалено в листопаді 2011 року; див. git.gluster.org/… . Таким чином, це, швидше за все, не буде працювати над новішими Glusters. Якщо вам здається, що коротший код важче зрозуміти, це нормально, але він набагато надійніший, ніж використання тимчасового файлу, тому подумайте про рефакторинг його для читабельності, а не відхиляйте його за сприйнятий недолік цього атрибута.
BMDan

1
Анонімний редактор зазначив, що gluster volume info | awk ...його можна скоротити до gluster volume list.
Лекенштейн
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.