2017年12月16日土曜日

プロセス監視スクリプト (Linux版)

サーバーのプロセス監視は、監視ソフトウェア(ZabbixやJP1など)を使えば当たり前のように実現できるが、ふと、スクリプトでも簡単に実装できるのでは?ということを思ったので、スクリプトを作成してみた。

実現方法

本スクリプトの設計概要を図示する。


このスクリプトは、psコマンドにて監視対象のプロセス数を取得し、設定ファイル(check-process.conf)に記載されたプロセス数との比較を行う。

プロセスダウンを検知した際は、/var/log/messagesにエラーメッセージを出力し、Zabbixのログ監視で検知させることにする。エラーメッセージ出力タイミングは、プロセスダウンの初回発生時のみとした。これにより、1分毎にエラー検知することを防止する。

以下に、本スクリプトで発生するメッセージを記載する。

 ・プロセス初回ダウン時 → [ERROR] Process XXX down
 ・プロセス継続ダウン時 → [INFO] Process XXX still down
 ・プロセス回復時    → [INFO] Process XXX up

この処理をcronで1分間隔で実行するよう登録し、定期的なプロセス監視を実現する。

スクリプト

以下にスクリプトのコードを記載する。

なお、本スクリプトはGitHubにも配置してみた(GitHub初心者なので、ただアップロードしただけ)。

https://github.com/TetsuOkamoto/check-process-linux

・スクリプトファイル名:check-process.sh

・設定ファイル名:check-process.conf

cronへの登録

スクリプトを/root/scriptディレクトリに配置した場合を例とする。この場合、cronには以下の通り設定を追加する。

# crontab -e
------------------------------
*/1 * * * * /root/script/check-process.sh
------------------------------

Zabbixを使った監視テスト結果

実際に本スクリプトを使って監視テストを実施してみた。Zabbixにて/var/log/messagesに「ERROR」の文字列あった場合に検知するトリガーを設定し、意図的にchronyd (時刻同期デーモン)を停止してみた。

問題なく設定できていれば、以下のようなプロセスダウンのメッセージ通知がされるようになる。

------------------------------
Trigger: messages
Trigger status: PROBLEM
Trigger severity: Average
Trigger URL:

Item values:

1. messages (t3023ce72:log[/var/log/messages,"@messages word",,,skip]): Dec 14 22:23:01 t3023ce72 root: [ERROR] Process "/usr/sbin/chronyd" down
2. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*
3. *UNKNOWN* (*UNKNOWN*:*UNKNOWN*): *UNKNOWN*

Original event ID: 3579

------------------------------

2017年12月11日月曜日

タスクスケジューラーを使って1分間隔で実行するタスクを作成する方法

とあるPowerShellのスクリプトを1分間隔で実行したかったので、タスクスケジューラーで繰り返し実行のタスクを作ることにした。しかし、「トリガー」タブの「繰り返し間隔」の選択項目を見ると、5分間より短い間隔の指定ができないように見える。


Linuxのcronであれば簡単に設定できることが、タスクスケジューラーではできないのかと困っていたのだが、実はこの「繰り返し間隔」は直接入力が可能である。

というわけで、試しに「5 分間」→「1 分間」に編集して保存してみる。


「詳細」欄を確認すると、「00:01:00 ごとに繰り返し」となっている。


実際にタスクを作成して、「次回の実行時刻」を確認すると、1分後が指定されていることが確認できた。


ちなみに、1分以下を指定できるか確認したところ、「繰り返し間隔は、1 分以上 31 日以下の値を指定する必要があります」というエラーメッセージではじかれた。Windowsのタスクスケジューラーの最少実行間隔は、1分のようだ。



2017年12月9日土曜日

rsyslog + logrotateでログ保管サーバーを構築する

ネットワーク機器などの障害調査を目的として、Syslogでログ転送を行いログを保管しておくという設計はよくある話ではある。有名な製品としては、Spulnk社のSplunk、インフォサイエンス社のLogstorage、OSSではGraylogやLogtashなど多数のソフトウェアが存在している。

とはいえ小規模な環境で有償のソフトウェアを導入することは、費用面や構築負荷といった面で割に合わないこともあるため、とりあえずログを保管するだけで詳細な分析は不要であれば、OSの標準機能で実装してしまう方が手っ取り早い。

今回はLinuxの標準機能であるrsyslogとlogrotateを組み合わせて、ログ保管サーバーの構築を行う。

環境

今回は仮想スイッチVyOSのログをSyslogにて受信し、5日分のログを保管できるように設定することにする。


参考までに、VyOSのSyslog設定を以下に記載する。

# show system syslog
------------------------------
 global {
     facility all {
         level notice
     }
     facility protocols {
         level debug
     }
 }
 host 192.168.33.22 {
     facility all {
         level debug
     }
 }
------------------------------

rsyslogの設定

UDP/514ポートを使ったSyslog受信設定を行ったうえで、送信元のIPアドレスをもとに出力ファイルを指定する。

設定は以下の通りとなる。

# cat /etc/rsyslog.conf | grep -v -e "^#" -e "^$"
------------------------------
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
$ModLoad imudp     ←UDPによるSyslogメッセージ入力を許可
$UDPServerRun 514   ←UDPの待ち受けポートを514に設定
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
:fromhost-ip, isequal, "192.168.33.31" -/var/log/t3031vy11.log
& ~
↑送信元IPアドレスに対して、出力先のログを指定。"& ~"を付けることで、直前の条件に一致したログを破棄する
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*
------------------------------

:fromhost-ipの行はプロパティベースのフィルターと呼ばれる。構文は以下の通りとなる。

:PROPERTY, [!]COMPARE_OPERATION, "STRING" LOGFILE

左から順に見ていこう。

①PROPERTY

今回はIPアドレスでフィルターするため、「fromhost-ip」で指定する。利用できるPROPERTYの値は以下を参照。

・rsyslog Properties
http://www.rsyslog.com/doc/master/configuration/properties.html

②[!]COMPARE_OPERATION, "STRING"

今回はIPアドレスで「一致」を条件とするため、「isequal, "192.168.33.31"」とする。isequalの前に!を付ければ否定となり「一致しないこと」が条件となる。その他比較処理については、以下表を参照すること。

  • contains:テキストを含む。大文字小文字を区別する
  • contains_i:テキストを含む。大文字小文字を区別しない
  • isequal:テキストと一致
  • regex: POSIX BRE (Basic Regular Expression)による比較
  • ereregex: POSIX ERE (Extended Regular Expression) 正規表現による比較
  • isempty:空かどうかを比較 (この際の”STRING"の記載方法が不明)

③LOGFILE

出力先のログファイルを指定する。ログファイル名の前に「-」を指定すると書き込みが非同期で行われ、パフォーマンスが向上するが、サーバー停止時に一部ログの欠損が発生する可能性がある。

logrotateの設定

以下の内容でファイルを新規作成する。今回は日次5世代のローテーション設定を行う。

# cat /etc/logrotate.d/remotelog
------------------------------
/var/log/t3031vy11.log {
    missingok      ←ログファイルが存在しない場合でもエラーとしない
    notifempty     ←ログファイルが空ならローテーションしない
    daily        ←日次で実行
    compress      ←圧縮。デフォルトではgzを圧縮コマンドとして利用
    rotate 5      ←5世代の過去ファイルを保管
    postrotate     ←ローテーション後コマンド(次行~endscriptまで)を実行
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript      ←コマンドの終わり
}
------------------------------

このファイルの作成ディレクトリである/etc/logrotate.dは、/etc/logrotate.confでインクルードされているため、ファイルを置くだけで設定を反映することができる。

なお、logrotateはただのコマンドとして提供されており、サービス化されていない。そのため、設定反映の際に、サービス再起動や設定ファイルの再読み込み作業は不要となる。

設定確認コマンドは以下の通りとなる。

# logrotate -d /etc/logrotate.conf
------------------------------
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file ConsoleKit
reading config info for /var/log/ConsoleKit/history

~(中略)~

reading config info for /var/log/t3031vy11.log

~(中略)~

rotating pattern: /var/log/t3031vy11.log  after 1 days (5 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/t3031vy11.log
  log does not need rotating
not running postrotate script, since no logs were rotated

~(以下略)~
------------------------------

logrotateの実行時間について

ここでlogrotateの実行時間についても記載しておく。logrotateはanacronで制御されており、日次、週次、月次の実行処理があらかじめ設定されている。

実際にanacronの実行制御の設定を見てみる。

# cat /etc/anacrontab
------------------------------
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
RANDOM_DELAY=45       ←各ジョブのdelay in minutes + 最大45分の遅延
START_HOURS_RANGE=3-22   ←3時-22時の間でジョブを実行(サーバー停止等がなければ3時開始)

#period in days delay in minutes job-identifier command
1       5       cron.daily       nice run-parts /etc/cron.daily  ←日次処理
7       25      cron.weekly      nice run-parts /etc/cron.weekly  ←週次処理
@monthly 45     cron.monthly     nice run-parts /etc/cron.monthly  ←月次処理
------------------------------

上記より、日次処理の場合、3:05~3:50の間でlogrotateが実行されることがわかる。

次に、日次処理の設定ファイルが配置されている/etc/cron.dailyディレクトリ内のlogrotateファイルの設定を確認する。logrotateコマンドを実行し、終了コードが0以外の際にloggerコマンドでエラーを吐くという、シンプルなスクリプトとなっている。

# cat /etc/cron.daily/logrotate
------------------------------
#!/bin/sh

/usr/sbin/logrotate /etc/logrotate.conf   ←logrotateコマンドを実行
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0
------------------------------

実際に作成されたログファイルを確認してみると、3:05~3:50の間でgz形式で圧縮されたファイルが5つ生成されていることがわかる。

# cd /var/log/
# ls -l t3031vy11.log*
------------------------------
-rw------- 1 root root 1233016 12月  4 10:06 2017 t3031vy11.log
-rw------- 1 root root  305117 11月 30 03:48 2017 t3031vy11.log-20171130.gz
-rw------- 1 root root  229191 12月  1 03:44 2017 t3031vy11.log-20171201.gz
-rw------- 1 root root  262123 12月  2 03:29 2017 t3031vy11.log-20171202.gz
-rw------- 1 root root  373297 12月  3 03:49 2017 t3031vy11.log-20171203.gz
-rw------- 1 root root  294881 12月  4 03:25 2017 t3031vy11.log-20171204.gz
------------------------------

参考

・rsyslog
http://www.rsyslog.com/

・20.2. RSYSLOG の基本設定
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/s1-basic_configuration_of_rsyslog

・第21章 システムタスクの自動化
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/deployment_guide/ch-automating_system_tasks

2017年12月5日火曜日

商用OSのEOSを調べてみた!2017年末版

顧客へシステム更改の提案をする際に、最低5年はサポート可能なOSの選定が必須となることが多く、念のためサポート期限(EOS : End Of Support)を調べることがよくある。

面倒になったので、本記事でいつでも参照できるようにまとめることにした。2018年にサポート期限を迎える製品については、赤字で強調表示した。

今回調査した商用OSは以下の通り。SUSEが無いとか、Solarisが無いとか、いろいろ意見があると思うが、私が個人的によく使うOSのみに絞らせてもらった。

  • Windows (PC用)
  • Windows Server
  • vSphere
  • Red Hat Enterprise Linux
  • AIX
  • HP-UX

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

2018年になっても即座にEOSとなるOSは無い。Windows 7に関しては、2020年まで延長サポートが続くこともあり、Windows 10に切り替える企業は2018年も少数であると想定される。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・ご存知ですか?OS にはサポート期限があります!
https://www.microsoft.com/ja-jp/atlife/article/windows10-portal/eos.aspx

・Windows 7 SP 1
延長サポート:2020/01/14 (SP1必須)

・Windows 8.1
メインストリームサポート:2018/01/09
延長サポート:2023/01/10

・Windows 10
メインストリームサポート:2020/10/13
延長サポート:2025/10/14


Windows Server

Windows Serverも2018年に即座にEOSとなる製品は無い。どちらかというと、HWやOS上のアプリケーションのEOSが先に来てしまい、更改するということが多いと思われる。2018年10月までであれば、そこからまだ5年の延長サポートがWindows Server 2012には残っており、Windows Server 2016を使うかどうか判断に悩むこともあるかもしれない。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・Windows Server 2008 R2 SP1
延長サポート:2020/01/14 (SP1必須)
※プレミアムアシュアランスによる6年の追加サポートが可能な模様
・Introducing Windows Server Premium Assurance and SQL Server Premium Assurance
https://cloudblogs.microsoft.com/hybridcloud/2016/12/08/introducing-windows-server-premium-assurance-and-sql-server-premium-assurance/

・Windows Server 2012 / Windows Server 2012 R2
メインストリームサポート:2018/10/09
延長サポート:2023/10/10

・Windows Server 2016
メインストリームサポート:2022/01/11
延長サポート:2027/01/11

vSphere

VMware製品のEOS情報は、以下URLにてPDFにまとめられており、大変わかりやすい。EOSは発売からきっかり7年と設定されている。2018年はESXi 5.0 / ESXi 5.1がEOSとなってしまうことが大きなイベントとなる。

・VMware Lifecycle Product Matrix
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

ESXi 5.0 / ESXi 5.1 / vCenter Server 5.0 / vCenter Server 5.1
END OF GENERAL SUPPORT:2016/08/24
END OF TECHNICAL GUIDANCE:2018/08/24

・ESXi 5.5 / vCenter Server 5.5
END OF GENERAL SUPPORT:2018/09/19
END OF TECHNICAL GUIDANCE:2020/09/19

・ESXi 6.0 / vCenter Server 6.0
END OF GENERAL SUPPORT:2020/03/12
END OF TECHNICAL GUIDANCE:2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT:2021/11/15
END OF TECHNICAL GUIDANCE:2023/11/15

Red Hat Enterprise Linux

Red Hat Enterprise Linuxはかなりサポート期間が長い。例えば、2007年3月に発表されたRed Hat Enterprise Linux 5であっても、2020年までサポートが可能となっている (ただし、延長ライフサイクルサポート(ELS)アドオンと呼ばれる有料サポートの契約が必要)。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 5
End of Extended Life-cycle Support:2020/11/30

・Red Hat Enterprise Linux 6
End of Production 3:2020/11/30
End of Extended Life-cycle Support:2024/06/30

・Red Hat Enterprise Linux 7
End of Production 3:2024/06/30
End of Extended Life-cycle Support:未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。

・AIX support lifecycle information
https://www-01.ibm.com/support/docview.wss?uid=isg3T1012517

・AIX 7.1 TL5
End of Service Pack Support :2022/04/30

・AIX 7.2 TL2
End of Service Pack Support :2020/10/31 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。

・長期間利用のための開発方針とサポートポリシー
https://h50146.www5.hpe.com/products/software/oe/hpux/topics/support/

・HP-UX 11i v2
サポート終了:2019/12月

・HP-UX 11i v3
サポート終了:未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html

2017年11月29日水曜日

Zabbix 3.0でSNMPTTを使ったSNMP Trap監視を実装する

以前、ZabbixにてSNMP Trap監視の実装手順を記載した。

・ZabbixでESXiのSNMP Trapを監視する設定
https://tech-mmmm.blogspot.jp/2016/05/zabbixesxisnmp-trap.html

この記事ではPerlスクリプト「zabbix_trap_receiver.pl」を利用してSNMP Trap監視を実現したが、SNMPTT (SNMP Trap Translator)を使う手法がZabbix推奨のようなので、今回はSNMPTTを使ったSNMP Trap監視を実装してみることにした。

なお、OSはCentOS 7.3、ZabbixはMIRACLE ZBX 3.0となる。

SNMPTTのインストール

SNMPTTには前提パッケージが多数あるため、OSのインストールメディアを/mediaにマウントしたうえで、以下順序でRPMのインストールを行う。

# cd /media/Packages/
# rpm -ivh perl-Digest-1.17-245.el7.noarch.rpm
# rpm -ivh perl-Digest-MD5-2.52-3.el7.x86_64.rpm
# rpm -ivh perl-Digest-SHA-5.85-3.el7.x86_64.rpm
# rpm -ivh perl-Digest-HMAC-1.03-5.el7.noarch.rpm
# rpm -ivh perl-Digest-SHA1-2.13-9.el7.x86_64.rpm
# rpm -ivh perl-Socket6-0.23-15.el7.x86_64.rpm
# rpm -ivh perl-List-MoreUtils-0.33-9.el7.x86_64.rpm
# rpm -ivh perl-IO-stringy-2.110-22.el7.noarch.rpm
# rpm -ivh perl-Sys-Syslog-0.33-3.el7.x86_64.rpm

snmptrapやsnmpwalkコマンドを使えるように、以下RPMを合わせてインストールしておく(SNMPTTの動作に必須ではない)。

# rpm -ivh net-snmp-utils-5.7.2-24.el7_2.1.x86_64.rpm

1つだけ不足するPerlのRPMファイルがあるため、以下からダウンロードし、/root/ZBXに配置しておく。

<ダウンロード先>
https://www.rpmfind.net/linux/rpm2html/search.php?query=perl-Crypt-DES

ftp://195.220.108.108/linux/centos/7.4.1708/os/x86_64/Packages/perl-Crypt-DES-2.05-20.el7.x86_64.rpm
※直リン

<ダウンロードファイル>
perl-Crypt-DES-2.05-20.el7.x86_64.rpm

次に、MIRACLE ZBX公式サイトからダウンロードしたRPMファイルを/root/ZBXに配置しする。

<ダウンロード先>
・Index of /zbx/3.0/7.x/x86_64/RPMS
http://ftp.miraclelinux.com/zbx/3.0/7.x/x86_64/RPMS/

<ダウンロードファイル>
perl-Config-IniFiles-2.79-1.el7.noarch.rpm
perl-Net-SNMP-6.0.1-7.el7.noarch.rpm
snmptt-1.4-0.9.beta2.el7.noarch.rpm

/root/ZBXの中の4つのRPMファイルをインストールする。

# cd /root/ZBX/# rpm -ivh perl-Crypt-DES-2.05-20.el7.x86_64.rpm
# rpm -ivh perl-Config-IniFiles-2.79-1.el7.noarch.rpm
# rpm -ivh perl-Net-SNMP-6.0.1-7.el7.noarch.rpm
# rpm -ivh snmptt-1.4-0.9.beta2.el7.noarch.rpm

以上でインストールは完了となる。

Zabbixの設定

ZabbixはSNMPTrapperを有効にする設定を行うだけでよい。

# cat /etc/zabbix/zabbix_server.conf | grep -v -e "^#" -e "^$"
------------------------------
LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=0
PidFile=/var/run/zabbix/zabbix_server.pid
DBName=zabbix
DBUser=zabbix
DBPassword=XXXXXX
DBPort=5432
StartVMwareCollectors=1
SNMPTrapperFile=/var/log/zabbix/zabbix_traps.tmp
StartSNMPTrapper=1
Timeout=4
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
LogSlowQueries=3000
------------------------------

設定反映のため、サービス再起動を行う。

# systemctl restart zabbix-server

なお、このときZabbixのログに以下エラーメッセージが出力されることがある。

# tail /var/log/zabbix/zabbix_server.log
------------------------------
 20695:20171118:091342.878 cannot stat SNMP trapper file "/var/log/zabbix/zabbix_traps.tmp": [2] No such file or directory
------------------------------

これは、SNMP Trap監視用のログファイルであるzabbix_traps.tmpが存在しないことにより出力されるエラーとなる。あらかじめ以下の通り空ファイルを作っておけばエラーは発生しない。

# touch /var/log/zabbix/zabbix_traps.tmp
# chown zabbix:zabbix /var/log/zabbix/zabbix_traps.tmp
# chmod 664 /var/log/zabbix/zabbix_traps.tmp
# ls -l /var/log/zabbix/
------------------------------
-rw-rw-r-- 1 zabbix zabbix     1281 11月 11 18:57 zabbix_agentd.log
-rw-rw-r-- 1 zabbix zabbix 14823059 11月 18 09:13 zabbix_server.log
-rw-rw-r-- 1 zabbix zabbix        0 11月 18 09:13 zabbix_traps.tmp
------------------------------

snmptrapdの設定

SNMP Trapを受信するsnmptrapdでは、2つのファイルの編集を行う。

1つ目はsnmptrapdの起動オプションの設定となる。-Onを付けることで、SNMP TrapのOIDがメッセージに変換されなくなる。後述するが、メッセージへの変換はSNMPTTが行う。

# cat /etc/sysconfig/snmptrapd | grep -v -e "^#" -e "^$"
------------------------------
OPTIONS="-On -Lsd -p /var/run/snmptrapd.pid -M /usr/share/snmp/mibs:/usr/share/snmp/venders -m all"
------------------------------

2つ目はSNMP Trap受信時にsnmptthandlerを実行する設定となる。

# cat /etc/snmp/snmptrapd.conf | grep -v -e "^#" -e "^$"
------------------------------
authCommunity   log,execute,net public
traphandle default /usr/sbin/snmptthandler
------------------------------

上記設定後、snmptrapdを起動させる。

# systemctl start snmptrapd
# systemctl enable snmptrapd

SNMPTTの設定

SNMPTTでは2つの設定ファイルの編集を行う。

snmptt.iniは、SNMPTTに関する様々な設定が記載されている。必要な箇所のみ変更する。

# vi /etc/snmp/snmptt.ini
------------------------------
mode = daemon
date_time_format = %H:%M:%S %Y/%m/%d
syslog_enable = 0
log_file = /var/log/zabbix/zabbix_traps.tmp
------------------------------

snmptt.confは、デフォルトでいくつか記載がされているが、シンプルに以下2行のみに変更する。このファイルは受信したSNMP Trapの変換処理に関する設定が記載される。

# cat /etc/snmp/snmptt.conf
------------------------------
EVENT general .* "General event" Normal
FORMAT ZBXTRAP $aA $* 
------------------------------

SNMPTTを起動させる。

# systemctl start snmptt
# systemctl enable snmptt

監視テスト①

この段階で一度監視テストとして、Zabbixサーバーにて以下コマンドを実行してみよう。

# snmptrap -v2c -c public 127.0.0.1 "" .1.3.6.1.6.3.1.1.5.1 coldStart s "Start"

snmptrapdのログが出力されていることを確認する。

# tail /var/log/messages
------------------------------
Nov 18 16:11:15 t3024ce73 snmptrapd[28050]: 2017-11-18 16:11:15 localhost [UDP: [127.0.0.1]:43300->[127.0.0.1]:162]:#012.1.3.6.1.2.1.1.3.0 = Timeticks: (75916108) 8 days, 18:52:41.08#011.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.6.3.1.1.5.1#011.1.3.6.1.6.3.1.1.5.1 = STRING: "Start"
------------------------------

SNMPTTのログが出力されていることを確認する。

# tail /var/log/zabbix/zabbix_traps.tmp
------------------------------
16:11:15 2017/11/18 .1.3.6.1.6.3.1.1.5.1 Normal "General event" localhost - ZBXTRAP 127.0.0.1 127.0.0.1
------------------------------

ログを見てわかる通り、これだけではSNMP Trapの内容の判別ができないため、SNMPTTにてMIBの登録を行い、OIDをメッセージに変換できるようにする。

MIB登録

MIBを保存するパスとして、snmpt.confファイルを新規作成する。

# cat /etc/snmp/snmp.conf
------------------------------
MIBDIRS /usr/share/snmp/mibs:/usr/share/snmp/venders
MIBS all
------------------------------

/usr/share/snmp/vendersに必要なMIBファイルを保存し、snmpttconvertmibにて変換を行う。今回は、ESXiのMIBを例にしている。

# cd /usr/share/snmp/venders
# ls -l
------------------------------
-r--r--r-- 1 root root  50968  7月 17  2015 BRIDGE-MIB.mib
-r--r--r-- 1 root root  59268  7月 17  2015 ENTITY-MIB.mib
-r--r--r-- 1 root root  52586  7月 17  2015 HOST-RESOURCES-MIB.mib

~(中略)~

-r--r--r-- 1 root root   8777  7月 17  2015 VMWARE-VC-EVENT-MIB.mib
-r--r--r-- 1 root root  38576  7月 17  2015 VMWARE-VCOPS-EVENT-MIB.mib
-r--r--r-- 1 root root  26952  7月 17  2015 VMWARE-VMINFO-MIB.mib
------------------------------

for分を使って、各MIBファイルの変換を行う。

# mkdir snmpttconf
# for i in `ls *.mib`; do snmpttconvertmib --in=$i --out=snmpttconf/$i.conf; done

catコマンドで1ファイルに結合する。

# cd snmpttconf
# cat *.conf > snmptt.conf.VMWARE

sedコマンドでZabbix検知に必要な文言を付与する。

# sed -i 's/FORMAT/FORMAT ZBXTRAP $aA $N/g' snmptt.conf.VMWARE

作成したconfファイルを所定のディレクトリにコピーし、snmptt.iniファイルのconfファイルのリストに追加する(今後snmptt.confファイルを追加する度に追記すること)。

# cp snmptt.conf.VMWARE /etc/snmp/
# vi /etc/snmp/snmptt.ini
------------------------------
snmptt_conf_files = <<END
/etc/snmp/snmptt.conf.VMWARE   ←★追加
/etc/snmp/snmptt.conf
END
------------------------------

設定反映のため、サービス再起動を行う。

# systemctl restart snmptt

監視テスト②

再度、監視テストを行う。

# snmptrap -v2c -c public 127.0.0.1 "" .1.3.6.1.6.3.1.1.5.1 coldStart s "Start"

先ほどと異なり、SNMP TrapのOIDだけでなくメッセージも表示されていることがわかる。

# tail /var/log/zabbix/zabbix_traps.tmp
------------------------------
20:05:28 2017/11/24 .1.3.6.1.6.3.1.1.5.1 Normal "Status Events" localhost - ZBXTRAP 127.0.0.1 coldStart A coldStart trap signifies that the SNMP entity, Start
------------------------------

Zabbixの受信設定

最後にZabbixのGUIにて、SNMP Trap受信の設定を行う。

テンプレートの作成

------------------------------
・テンプレート名:Template SNMP Trap
・グループ:Templates
------------------------------


アイテムの作成

------------------------------
・名前:SNMP Trap log
・タイプ:SNMP トラップ
・キー:snmptrap[]
・データ型:ログ
・ヒストリ保存期間(日):90
・ログの時間の形式:hh:mm:ss yyyy/MM/dd
・アプリケーションの作成:SNMP Trap
・有効:チェック
------------------------------


トリガーの作成

------------------------------
・名前:SNMP Trap
・条件式:{Template SNMP Trap:snmptrap[].strlen()}>0
・障害イベントを継続して生成:チェック
・深刻度:軽度の障害
・有効:チェック
------------------------------


以上で設定は完了となる。SNMP Trapを受信すると以下の通り障害検知ができるようになる。


参考

・Setup SNMP Trap monitoring for vCenter Server Appliance with Zabbix
https://gist.github.com/higebu/01c63b0057e3a17494e6

2017年11月21日火曜日

Linuxの設定ファイルを効率よくバックアップする関数

設定ファイルなどを変更する際にファイル名に日付などを入れてバックアップを取ることがよくある。例えば、hostsファイルを変更する場合は、以下のようにコピーコマンドを入力していた。

# cp -p /etc/hosts /etc/hosts_YYYYMMDD ※YYYYMMDDは日付

毎回このようにcpコマンドを打ち込むのが面倒に感じ始めたので、以下のような関数を作ってみた。

function cbk () { command cp -p ${1} ${1}_`date +"%Y%m%d_%H%M%S"`; ls -l ${1} ${1}_*; }

以下は/etc/hostsファイルをバックアップした例となる。

# function cbk () { command cp -p ${1} ${1}_`date +"%Y%m%d_%H%M%S"`; ls -l ${1} ${1}_*; }
# cbk /etc/hosts
------------------------------
-rw-r--r-- 1 root root 187 11月 10 22:22 /etc/hosts
-rw-r--r-- 1 root root 187 11月 10 22:22 /etc/hosts_20171119_064722
------------------------------

~/.bashrcに登録しておけば便利。

# cat ~/.bashrc
------------------------------
# .bashrc
# User specific aliases and functions
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

alias ccat="grep -v -e '^ *#' -e '^$'"
function cbk () { command cp -p ${1} ${1}_`date +"%Y%m%d_%H%M%S"`; ls -l ${1} ${1}_*; }

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi
------------------------------

再ログインすれば反映されてコマンドが使えるようになる。即座に使えるようにしたい場合は、以下コマンドで反映させればよい。

# source ~/.bashrc

2017年11月13日月曜日

Zabbix 3.0でGmailを使って障害通知を行う方法

別記事でZabbix 2.2環境のGmailを使ったメールによる障害通知方法を記載したが、今回はZabbix 3.0環境における設定方法について記載する。

Gmailでは、SMTPではなくSSL/TLSで暗号化を行うSMTPSを利用している。Zabbix 2.2では、SMTPSを用いたメール送信ができないため、別途SMTPSでメール送信するスクリプトを導入する必要があった。
※このあたりの手順については、以下別記事を参照。

・ZabbixでGmailを使って障害メールを送信する設定
https://tech-mmmm.blogspot.jp/2016/05/zabbixgmail.html

Zabbix 3.0ではSSL/TLSを使ったメール送信が実装されたため、前回のように外部スクリプトを利用する必要がなくなった。

設定概要

Zabbixの障害通知の設定は、設定箇所が複数あり、かつ、多くの独自用語が使われている。以下に障害検知からメール送信までの概要図を記載する。


設定箇所は以下の3つとなる。

 ①メディアタイプ  :通知手段(メール、スクリプト、SMSなど)を設定
 ②ユーザーのメディア:通知先メールアドレスと使用するメディアタイプを設定
 ③アクション    :障害検知時の通知条件と通知するユーザーを設定

設定は、「メディアタイプ」→「ユーザーのメディア」→「アクション」の順に実施する。

設定方法

1. メディアタイプを作成

メディアタイプとは通知手段の設定となるが、Gmail送信用のメディアタイプは設定されていないので、新規に作成する。「管理」→「メディアタイプ」を選択し、「メディアタイプの作成」ボタンを押下し、以下の通り作成する。

------------------------------
・名前:Gmail
・タイプ:メール
・SMTPサーバー:smtp.gmail.com
・SMTPサーバーポート番号:465
・SMTP helo:smtp.gmail.com
・送信元メールアドレス:<送信に用いるGmailアカウント>@gmail.com
・接続セキュリティ:SSL/TLS
・認証:Username and password
・ユーザー名:<送信に用いるGmailアカウント> ※「@gmail.com」は不要
・パスワード:<送信に用いるGmailアカウントのパスワード>
・有効:チェック
------------------------------


2. ユーザーのメディアを作成

作成したメディアタイプを使って、メディアを作成する。今回はAdminユーザーに対してメディアを作成することとした。

「管理→「ユーザー」を選択し、Adminを選択する。


「メディア」タブを選択し、「追加」を選択する。


以下の通りメディアの設定を行う。これは送信先メールアドレスに対して、24時間365日(月曜日-日曜日、00:00-24:00)で、すべての深刻度のメール送信を許可する設定となる。

------------------------------
・タイプ:Gmail
・送信先:<送信先のメールアドレス>
・有効な時間帯:1-7,00:00-24:00
・指定した深刻度のときに使用:すべてチェック
・有効:チェック
------------------------------


3. アクションを作成

最後にアクションを設定する。「設定」→「アクション」を選択し、「イベントソース」が「トリガー」であることを確認し、「アクションの作成」ボタンを押下し作成する。


「アクション」タブでは以下の通り設定する。メール件名にホスト名があると障害部位がすぐに判別できるので、件名に{HOST.NAME1}を追加している。また、障害検知時間がわかるように、メッセージの文頭に{EVENT.DATE} {EVENT.TIME}を追加した。

------------------------------
・名前:Send Gmail
・デフォルトの件名:{HOST.NAME1}:{TRIGGER.STATUS}: {TRIGGER.NAME}
・デフォルトのメッセージ:
{EVENT.DATE} {EVENT.TIME}

Trigger: {TRIGGER.NAME}
Trigger status: {TRIGGER.STATUS}
Trigger severity: {TRIGGER.SEVERITY}
Trigger URL: {TRIGGER.URL}

Item values:

1. {ITEM.NAME1} ({HOST.NAME1}:{ITEM.KEY1}): {ITEM.VALUE1}
2. {ITEM.NAME2} ({HOST.NAME2}:{ITEM.KEY2}): {ITEM.VALUE2}
3. {ITEM.NAME3} ({HOST.NAME3}:{ITEM.KEY3}): {ITEM.VALUE3}

Original event ID: {EVENT.ID}
------------------------------


「アクションの実行条件」タブでは以下の通り設定した。トリガーの深刻度の条件は、監視設計に応じて適切に設定すること。

------------------------------
・メンテナンスの状態 期間外 メンテナンス
・トリガーの値 = 障害
・トリガーの深刻度 >= 軽度の障害
------------------------------


「アクションの実行内容」タブでは、以下の通り設定する。実行条件が満たされた際に、AdminユーザーのGmail送信のメディアを使ってメール送信を行う設定となる。

------------------------------
・実行内容のタイプ:メッセージの送信
・ユーザーに送信:Admin
・次のメディアのみ使用:Gmail
------------------------------


以上で設定は完了となる。

メール送信テスト

試しにESXiのCPU使用率を上昇させ、トリガーにて障害検知させてみたところ、以下の通りGmailにメールが送信されることが確認できた。