Zabbix 導入事例(Zabbix 1.8)

Zabbix snmptrap インストール・設定・構築手順

Zabbixでは、snmptrapを監視する為に、snmtrapdでsnmptrapを受信しZabbixへ送信する設定をする必要があります。OSの設定に詳しい方であれば、問題無いのですが、設定には少し知識が必要になります。

ここでは、Zabbix 1.8. , Redhat 6.2の環境で確認した手順、および設定を紹介します。
※OSおよびsnmp version等によって、少し設定が異なります。詳しくは、Onlineマニュアル等を参照してください

ここで紹介する内容は、受信したホスト毎にItemデータを送信する方式です。
Itemデータの送信に失敗した場合、DEFAULT_HOSTNAMEのホストにItemデータを送信します。
DEFAULT_HOSTNAMEのホストへItemデータの送信に失敗した場合、loggerを使用してmessageファイルにエラーを記録します。

snmptrapdインストールの確認

snmptrapdを利用する為には、net-snmpの本体が必要です。
lib,devel,utilsではありません。下記のコマンドを実行してインストールされている事を確認します。

# rpm -qa | grep snmp
net-snmp-5.5-37.el6.x86_64

net-snmp-"VERSION情報"がインストールされている事を確認します。インストールされてない場合は、net-snmpをOSのメディアからインストールします。

例

# rpm -ivh net-snmp-5.5-37.el6.x86_64.rpm
警告: net-snmp-5.5-37.el6.x86_64.rpm: ヘッダ V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
準備中...                ########################################### [100%]
1:net-snmp           ########################################### [100%]

snmptrapdの設定

インストールしただけでは何も設定されていないため、snmptrapd.confの設定をします。

# Example configuration file for snmptrapd
#
# No traps are handled by default, you must edit this file!
#
# authCommunity   log,execute,net public
# traphandle SNMPv2-MIB::coldStart    /usr/bin/bin/my_great_script cold

下記の設定を追加します。

authCommunity   log,execute,net public
traphandle default /tmp/snmptrap.sh

説明

authCommunity
log:ログ出力
execute:コマンドの実行
net:別のネットワークへの転送
public:snmptrapで入ってくるコミュニティ名を指定します。
traphandle
/tmp/snmptrap.sh：snmptrapdからZabbixへ受信したTrapデータを送信するShell Scriptを指定します。

snmptrapd.optionの設定

snmptrapd.options(通常は、/etc/sysconfig/snmptrapd.options)にあります。ログの出力先等を変更したい場合は、このファイルに記述します。

#vi /etc/sysconfig/snmptrapd
# OPTIONS="-Lsd -p /var/run/snmptrapd.pid"
OPTIONS="-Lsd -p /var/run/snmptrapd.pid -M /usr/share/snmp/mibs:/usr/share/snmp/venders -m all "

/etc/hostsの修正

/etc/hostsに記述されているsnmptrapの送信元ホストの名称とZabbixに登録しているホスト名称が同じになるように設定します。

これは、snmptrapdが認識できるホスト名称とZabbixに登録してるホスト名称を同じにするための設定です。

Enterprise mibの導入 設定

snmptrapでは、OIDでデータが送信されてきますが、人間が直ぐに理解できるコード体系ではありません。OIDの意味を、解釈するのにmibファイルが必要となります。
Enterprise以下のOIDは、各企業独自のものになるため、net-snmpに標準でmibファイルが入っていません。そこで、ベンダーごとに提供されているmibファイルを取り込む為の設定を追加します。

最初にmibファイルをダウンロードして、net-snmpとは異なる管理ディレクトリを作成し配置します。この時に、ベンダーごとにディレクトリを分離しておくと後の管理が楽になります。

ここでは、仮に/usr/share/snmp/vendersに配置することとします。
snmp.confファイルを修正します。snmp.confは、複数の配置方法があるので、マニュアルを参照してください。

下記のエントリを追加します。

mibdirs /usr/share/snmp/mibs:/usr/share/snmp/venders
mibs all

Network機器のMIBダウンロードサイトを参考までに掲載します。

• HP提供のMIBダウンロードサイト
• YAMAHA提供のMIBダウンロードサイト
• CISCO提供のMIBダウンロードサイト
• ArrayNetworks : ロードバランサの本体にmibファイルが入っています
• Juniper : 保守契約サイトに掲載されています

snmptrapdの起動(再起動)

下記のコマンドを実行して、snmptrapdの起動(再起動)を行います。stopは、エラーが出ても無視してください。

# /etc/init.d/snmptrapd stop
# /etc/init.d/snmptrapd start

拡張版snmptrap.sh

Redhat 6.2環境、snmp v2cで確認したScriptです。snmp v1では、転送データが異なる記憶がありますので確認中です。
snmptrapd.confのオンラインマニュアルには、”このデーモンは traphandle コマンドを実行するとブロックしてしまう ”とありますので、snmptrapdから呼び出すsnmptrap.shは、直ぐにsnmptrapdに制御を返す必要があります。

zabbix_senderは、非常に軽く作られていますので、通常はlocalhost内での通信になります。通常の場合は問題がおきる可能性は低いかと思います。

下記は、Zabbix提供のsnmptrap.shを複数OID受信に対応させたものです。

#!/bin/bash
ZABBIX_SENDER="/tmp/zabbix_sender"
ZABBIX_AGENT_CONFIG="/etc/zabbix/zabbix_agentd.conf"
KEY="snmptrap"
DEFAULT_HOSTNAME="localhost"
zabbix_send(){
    # $TrapAddress
    # $TrapCommunity
    # $TrapEnterprise
    i=0
    x=${#STACK[@]}
    while [ $i -lt $x ]
    do
        str="Hostname:$host IP:$ip ${STACK[$i]}"
        $ZABBIX_SENDER -c $ZABBIX_AGENT_CONFIG -s $host -k $KEY -o "$str"
        if [ $? -ne 0 ]
            $ZABBIX_SENDER -c $ZABBIX_AGENT_CONFIG -s $DEFAULT_HOSTNAME -k $KEY -o "$str"
            if [ $? -ne 0 ]
                logger -i -p local3.info -t "snmptrap_zabbix" "Can not send the snmptrap-message to Zabbix Server:$str"
            fi
        fi
        i=$(( i + 1 ))
    done
}
read host
read ip
read uptime
read trapOID
i=0
while read line
do
    # v1用マッチング文字列は、使用しているソフトに合わせる事
    if [[ "$line" =~ ^SNMP-COMMUNITY-MIB::snmpTrapAddress.* ]]
    then
        TrapAddress=$line
    elif [[ "$line" =~ ^SNMP-COMMUNITY-MIB::snmpTrapCommunity.* ]]
    then
        TrapCommunity=$line
    elif [[ "$line" =~ ^SNMPv2-MIB::snmpTrapEnterprise.* ]]
    then
        TrapEnterprise=$line
    else
        STACK[$i]="$line"
        i=$(( i + 1 ))
    fi
done
# zabbix_sendをバックグランドで起動
zabbix_send &

exit 0

ZABBIX_SENDER:zabbix_senderのフルパス
ZABBIX_AGENT_CONFIG:zabbix_agentのConfigurationファイル
KEY:登録したItem keyを指定
DEFAULT_HOSTNAME:zabbix_senderがエラーリターンした時に再送信するZabbixのホスト名

SSH VPN経由パトライト(PATLITE)接続

パトライト(PATLITE)接続

クリックで拡大

Data Centerとの接続がSSL-VPN経由の場合、基本的にOffice側のクライアント(使用者)側からConnectionを接続する必要があります。
SSL-VPNの実装には、リバースプロキシ、ポートフォワード、L2カプセルなどがありますが、一般的に、SSL-VPNで接続時にData CenterにあるVPN装置からIPが振られますので、Data CenterにあるZabbix ServerからOffice側のIPは判りません。

パトライトは、Office側のIPを設定しますので、SSL-VPNで使用するアドレスとは異なるアドレス体系になります。また、Securityを確保する為、Data Center側からのOut Boundは、Network的に禁止されている事が多いです。
以上から、クライアント(使用者)側のパトライトを鳴動させようと考えた時、ZabbixのActionからShellを呼び出してもパトライトに接続できないケースがあります。弊社にて、実際に行いました回避策を２つ御紹介します。

※PATLITE及びパトライトは株式会社パトライトの登録商標です。

SSHポートフォワーディング

クリックで拡大

SSL-VPNのネットワーク上に、SSHのコネクションを張り、Zabbix ServerにSSHでログインしたConnection上で、SSHポートフォワーディングするように動作する状態にして、Actionから呼び出したShellからパトライトを操作する方式です。SSHトンネルが常に確保されている事が前提の構成のため、SSHのセッションが切れた場合は速やかに検知できるようにしておく必要があります。
また、SSL-VPNが切断されている間は、パトライトに接続できませんので、Actionから起動したScriptは、リトライ処理が必要となります。リトライ処理中は、Actionが実行中(処理中)のままになります。実行中(処理中)にZabbix Serverが、Fail Over,Fail Backした場合はリトライ処理中のプロセスが無くなりますのでパトライトを鳴動させることはできません。※NetworkのSecurityホールを利用するような方式のため、管理責任者の方の了解を得ている必要があります。この方式は、最初にsshを利用してZabbix Serverへログインしますが、Zabbix Serverをクラスタ構成にしている場合、Fail Over,Fail Backすると保存しているhost keyと接続先のhost keyが異なり接続できなくなる場合がありますので注意が必要です。

弊社では、独自のsshコマンドを作成して、この問題を回避しています。

非同期ファイル経由方式

クリックで拡大

Actionから呼び出したShellで一度、パトライトを呼ぶ設定をファイルに保存する処理と、クライアント(使用者)側からZabbix Serverへsshでログインして、該当ファイルを取り出しパトライトを操作する非同期の２段階方式です。冗長構成を取っている場合は、保存ファイルをファイル共有できる所に格納する必要があります。
また、非同期方式ですので、パトライトを鳴動させるのが若干遅れますが、Actionは、直ぐに処理終了となり、Fail Over,Fail BackしてもNetworkが復旧すれば、パトライトを鳴動することができます。この方式では、最初にsshを利用してZabbix Serverへログインするため、Zabbix Serverをクラスタ構成にしている場合、Fail Over,Fail Backすると保存しているhost keyと接続先のhost keyが異なり接続できなくなる場合がありますので注意が必要です。

弊社では、独自のsshコマンドを作成して、この問題を回避しています。

Zabbix Redmine 導入/構築

インシデント管理ソフトウェアにRedmine、統合監視としてZabbixを導入/構築する事例です。
オープンソースのProject管理ソフトウェアとして有名なRedmineですが、柔軟な権限、制御ができる為、インシデント管理ソフトウェアとしても非常に便利です。
Action(アクション)経由で、障害として検知したITEM、トリガーのデータをRedmineに自動的に登録します。

Zabbix Redmine連携については、こちらをご参考ください。

Selenium導入/構築

Web監視用にオープンソース(OSS)のSeleniumを利用し、Zabbixから使用する導入/構築事例です。
Seleniumと接続する為にZabbix本体をカスタマイズしています。
既に御客様側でZabbixのソースを修正している場合でも、弊社にて修正可能です。

統合監視 Zabbix 監視項目の例

本資料は、オープンソース(OSS)統合監視ソフトウェア Zabbixを導入する際の「壁」を取り除いていただくことを目的とした資料です。
統合監視とは、全ての監視対象(サーバ、ネットワーク、各種アプリケーション)を集中(一元)監視することです。

※下記は、簡単に分類項目をカテゴリ分けした各監視項目の一例です。
※分類方法は色々な見方がありますので、必要に合わせた分類をしてください。

システムの複雑化、グローバル化、仮想OS等により、監視する対象は多岐にわたりサービスの監視などの、監視の方法も複雑になります。コスト削減が命題になっている事と思いますが、システムの運用も例外ではありません。

運用コストの削減で、直ぐに思いつくのがライセンス費用のかからないオープンソース(OSS)統合監視ソフトウェアの導入・切替による、運用人件費の削減、保守コストの削減です。大規模なシステム環境であれば、削減効果は大きなものになります。

※その分移行作業も大変になります。

OS監視

アプリケーション監視

Netowrk機器監視

サービス監視

オープンソース(OSS)導入の問題点まとめ

オープンソース(OSS)導入に関しての懸念点

本項はオープンソース(OSS)統合監視ソフトウェア Zabbixを導入する際の「壁」を取り除いていただくことを目的としたまとめです。

下記は弊社が統合監視ソフトウェア(ツール)Zabbixを各社に紹介した際、懸念点として伺いました内容を大まかに集約したものです。内容的には、コミュニティで公開されているオープンソース(OSS)を対象に気にされている点も多く、専門の会社(Zabbix SIA)が開発、保守、メンテナンスしている統合監視ソフトウェアをオープンソース(OSS)として公開しているものとは異なる部分もあります。Internetに情報として発信されているOSS導入の懸念点とは少々相違するかもしれません。

弊社では、安心して御利用頂ける様に自社開発ソフトウェアと同等レベルで各種サービスを提供するため、ソースレベルで独自に対応できる自社Engineerがサービスを提供しています。

オープンソース(OSS)の安心感 / 信頼性 / 信頼感

商用ソフトウェアでもオープンソース(OSS)でも、潜在的なバグ(ソフトウェアの不具合)は、必ず存在しますが、オープンソース(OSS)は、特にバグが原因で障害を引き起こす可能性が高いと認識されている傾向にあります。オープンソース(OSS)は、元々コミュニティ内で開発されていたソフトウェアが公開されてきているため、問題が発生した際に責任の所在が明確になっていない、との認識からきているようです。

問題の現象をコミュニティへ質問して回答を得ても、回答したEngineerには、回答に対して責任がありません。あくまで、善意で回答されているのが基本的なスタンスです。回答された内容を検証し、正しいと判断するのは質問したEngineerです。また、認知度が低く、利用者数が少ないオープンソース(OSS)では、開発およびメンテナンス継続が契約によって担保されていないのも信頼性、信頼感がかける要因となっています。

技術者不足(確保)

オープンソース(OSS)は、ソースコードが無償で公開されており、インターネットを通じて広くコミュニティが開かれていますので、オープンソース(OSS)を扱う技術者は多数います。※企業開発のオープンソース(OSS)は、コミュニティ版とエンタープライズ版を分けて、エンタープライズ版を公開していないソフトウェアもあります。

しかし、対応できる技術者が多いのは、認知度が高く、利用者数が多いオープンソース(OSS)です。認知度が低いオープンソース(OSS)では、実際に企業が基幹システム等で導入しようとした場合、導入するオープンソース(OSS)の技術者が不足している(確保できない)ため、導入を断念する場合があります。

これは、オープンソースを利用できる技術者は多数存在するが、ソースコードレベルでの十分な知識を持つ技術者が商用ソフトウェアと同様には存在しないこと、を意味しているものと推測されます。信頼性、信頼感にも繋がるのですが、コミュニティ等のEngineerを期待して導入するのはリスクを伴います。

機能不足

オープンソース(OSS)は元々、開発者の用途・要件を満たす目的でコミュニティ内で開発されています。そのため企業システムでの利用を前提に開発された商用ソフトウェアに比較して、機能面で不足している部分が多い傾向にあります。しかし認知度が高く、利用者が多いオープンソース(OSS)では、機能追加や不具合修正の頻度も高く、対応も早いようです。

Zabbixは、専門の会社がEnterprise(企業)が利用する事を目的として開発していますので、十分な機能を持っています。不足している機能はほとんどありませんが、商用ソフトウェアと同様に利用する側が期待する機能が全てあるわけではありません。商用ソフトウェアと異なり、ソースコードが公開されているので、利用する側で機能修正、追加をすることは可能ですが、十分な知識を持つ技術者を確保することが必須条件となります。

保守コスト

オープンソース(OSS)は、自己責任で利用する必要がありますので、企業で利用しようとする場合、保守は基本的に利用する会社で行う必要があります。しかし、基幹システムへ導入する為に自社でソースコードを熟知したEngineer(人材)を確保すると、利用する数にもよりますが一般的に保守(人件費)が高コストとなりコスト削減の為にオープンソース(OSS)を導入する意味が無くなります。

したがって、通常は保守サービスを提供している会社からサービスを受けるのが一般的ですが、小さいシステムでは商用製品の保守費用とオープンソース(OSS)の保守費用が変わらない、もしくは商用製品の保守費用の方が安くなる場合もあります。