Zabbix 導入事例

参考までに弊社の導入事例、監視項目の例について下記にまとめました。

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ダウンロードサイトを参考までに掲載します。

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のホスト名

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

パトライト(PATLITE)接続

image-1

クリックで拡大

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

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

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

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

image-1

クリックで拡大

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

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

非同期ファイル経由方式

image-1

クリックで拡大

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

分類 監視対象:例 非Agent 型の監視方法例 Agent型の監視方法例
死活監視 サーバ Icmp(ping)による死活監視 Icmp(ping)による死活監視
OS telnet,ssh等のサービスポートによる死活監視 Agentとの接続監視による死活監視
状態監視 各種プロセス telnet,ssh等でログインして、ps等コマンドを利用してプロセス稼動確認 Agentによるプロセス稼動確認
※通常、OSのI/Fを利用して状態確認
ポート Tcp等で、実際に Connection することによりポートの状態確認 Agentによるポートのオープン確認
※通常、OSのI/Fを利用して状態確認
エラー監視 ログファイル telnet,ssh等でログインして、ログを確認しますが、正確にはできない Agentによるログのエラー検知
イベントログ
SNMPTrap SNMPTrapを受信することで、エラー等を検知 SNMPTrapを受信することで、エラー等を検知
リソース監視 CPU telnet,ssh等でログインして、vmstat,sar,iostat,ps等のコマンドを利用して各リソースを確認 Agentによるポートのオープン確認
※通常、OSのI/Fを利用して状態確認
メモリ
ディスク
SNMP SNMP,IPMIの I/F を利用して情報を取得 SNMP,IPMIの I/F を利用して情報を取得
IPMI

アプリケーション監視

分類 監視対象:例 非Agent 型の監視方法例 Agent型の監視方法例
状態監視 プロセス telnet,ssh等でログインしてプロセス稼動確認 Agentによるプロセス稼動確認
ポート Tcp等で、実際に Connection することによりポートの状態確認 Agentによるポートのオープン確認
ファイル telnet,ssh等でログインして、ls等のコマンドを利用して確認 ※通常、OSのI/Fを利用して状態確認
リソース監視 CPU telnet,ssh等でログインして、vmstat,sar,iostat,ps等のコマンドを利用して各リソースを確認 Agentによる各リソース確認
※通常、システムコール、OSのI/Fを利用して状態確認
メモリ
ディスク
アプリケーションリソース
エラー監視 ログファイル telnet,ssh等でログインして、ログを確認しますが、正確にはできない Agentによるログのエラー検知
イベントログ
Database Database Connection ODBC,JDBC等経由で、実際に Database にログインして確認 同左
Databaseの各リソースを SQL を発行して確認

Netowrk機器監視

分類 監視対象:例 非Agent 型の監視方法例 Agent型の監視方法例
死活監視 Icmp(ping)による死活監視
Security上、Icmp(ping)を使用できない場合は、telnet,ssh等による死活監視
Network機器は、独自のAgentを組み込むことができないのでAgent型での監視方法はありません。
Agentから非Agent型と同様の方法で監視する方法になります。
Network機器からServerのsyslogへデータを転送して、ログ監視する方法もあります。
状態監視 SNMP SNMP,IPMIのI/F(command or ライブラリ)を利用して情報を取得
エラー監視 ログ Syslogサーバへ転送して、ログを監視
SNMPTrap NMPTrapを受信することで、エラー等を検知
リソース監視 SNMP SNMPのI/F(command or ライブラリ)を利用して情報を取得

サービス監視

分類 監視対象:例 非Agent 型の監視方法例 Agent型の監視方法例
WEB監視 Webページ参照
Webレスポンスタイム
ダウンロードタイム
Wget,libcurl等を利用して実際に対象のWebページをダウンロードして確認
複雑ページ遷移を確認する場合は、Seleniumなど他のツールを利用
同左
POP3監視 メール受信 実際にメールサーバが受信したメールを取り出して確認 同左
SMTP監視 メール配信 実際にメールを配信して、エラーが無いことを確認 同左

オープンソース(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)の保守費用が変わらない、もしくは商用製品の保守費用の方が安くなる場合もあります。