AuroraのPreviewを使う機会があったのでベンチマークをとってみました。
やり方の問題だと思いますが、MySQLよりも遅い結果になってしまいました。
5倍の速度を出すためのチューニングノウハウが必要なのでしょうか・・・
t2.microのサーバからsysbenchを使って計測しました。
RDSのdb.r2.largeのタイプでMySQLとAuroraそれぞれに対して行いました。
MySQL： 211.09 transaction per sec
Aurora ： 139.22 transaction per sec
何かの参考にしてください。
2015年2月16日月曜日
2015年2月13日金曜日
ZABBIXサーバのsshdを監視しよう
今回はsshdを監視するテンプレートを作ります。
sshdが起動していないとログインに困ります。もし停止してしまったら再起動させるアクションも加えます。
ZABBIXの公式ページで公開されていますが、これに/var/log/secureを取得するアイテムを加えます。
http://www.zabbix.jp/documents/template
Template_App_sshdもインポートするとエラーが出てしまうため1つ1つ作成します。
やり方は前回と同じです。
アプリケーション
アイテム
トリガー
次にアイテムを１つ追加します。不正アクセスなどされるとログを消されてしまうこともあるため定期的にZabbix serverで取得しておきます。
名前： Log of $1
タイプ： Zabbixエージェント（アクティブ）
キー： log[/var/log/secure]
データ型： ログ
更新間隔： 300
ヒストリ保存期間： 90
アプリケーション： SSH
以上で完了です。
Zabbix serverにTemplate App sshdを適用しておきましょう。
最後にアクションとしてsshdの障害のときにsshdを再起動するようにします。
今回も作成したテンプレートのxmlファイルを公開しておきますので、うまくいってない方がいらっしゃればお使いください。
Template_App_sshd
今回はここまで。
sshdが起動していないとログインに困ります。もし停止してしまったら再起動させるアクションも加えます。
ZABBIXの公式ページで公開されていますが、これに/var/log/secureを取得するアイテムを加えます。
http://www.zabbix.jp/documents/template
Template_App_sshdもインポートするとエラーが出てしまうため1つ1つ作成します。
やり方は前回と同じです。
アプリケーション
アイテム
トリガー
次にアイテムを１つ追加します。不正アクセスなどされるとログを消されてしまうこともあるため定期的にZabbix serverで取得しておきます。
名前： Log of $1
タイプ： Zabbixエージェント（アクティブ）
キー： log[/var/log/secure]
データ型： ログ
更新間隔： 300
ヒストリ保存期間： 90
アプリケーション： SSH
以上で完了です。
Zabbix serverにTemplate App sshdを適用しておきましょう。
最後にアクションとしてsshdの障害のときにsshdを再起動するようにします。
今回も作成したテンプレートのxmlファイルを公開しておきますので、うまくいってない方がいらっしゃればお使いください。
Template_App_sshd
今回はここまで。
2015年2月12日木曜日
ZABBIXサーバのアイテムについて理解しよう
今回はアイテムのキーについて少し説明します。
ZABBIXを使うにあたって、このキーが非常に重要になります。
ZABBIXはアイテムを使って取得した値に対してトリガーを設定し、その後のアクションにつなげます。
アイテムはキーで指定したものを値として取得しています。ですので、キーを用いて取得できるものなら、監視が可能ということになります。
そのためキーの種類は非常にたくさんあります。たくさんあるので、今回は一部の解説のみになりますが、今後利用していく際に少しずつ解説を入れていければなぁと思います。
ところでアイテム作成の際にタイプというのがありますが、キーとタイプは対になっていて、タイプによって使えるキーが変わってきます。
アイテム作成の際にキーの右側の選択を押すと一覧が出ますので確認してください。
それでは、いくつか解説します。
タイプ：シンプルチェック
ZABBIXを使うにあたって、このキーが非常に重要になります。
ZABBIXはアイテムを使って取得した値に対してトリガーを設定し、その後のアクションにつなげます。
アイテムはキーで指定したものを値として取得しています。ですので、キーを用いて取得できるものなら、監視が可能ということになります。
そのためキーの種類は非常にたくさんあります。たくさんあるので、今回は一部の解説のみになりますが、今後利用していく際に少しずつ解説を入れていければなぁと思います。
ところでアイテム作成の際にタイプというのがありますが、キーとタイプは対になっていて、タイプによって使えるキーが変わってきます。
アイテム作成の際にキーの右側の選択を押すと一覧が出ますので確認してください。
それでは、いくつか解説します。
タイプ：シンプルチェック
icmpping[target]
監視対象（target）にpingを行って、応答があれば1、なければ0を取得します。
トリガー条件で「アイテム<1」としておけばアクションを起こせます。
これに対して応答時間を見るのがicmppingsecです。
icmppingsec[target]
監視対象（target）にpingを行って、応答時間を取得します。単位は秒です。
トリガー条件で「アイテム>0.1」としておけば100msを超えたらアクションを起こせます。
net.tcp.service[service]
サービスが動作しているか確認し、動作していれば1、してなければ0を取得します。
トリガー条件で「アイテム<1」としておけばアクションを起こせます。
serviceに記述できるのは次のとおりです。
ssh ntp ldap smtp ftp http pop nntp imap tcp https telnet
ICMP同様、応答時間をみるには、net.tcp.service.perfを使います。
net.tcp.service.perf[service]
サービスへの接続にかかった時間を取得します。停止していれば0です。単位は秒です。
トリガー条件で「アイテム>1」としておけば1sを超えたらアクションを起こせます。
serviceに記述できるのは、net.tcp.serviceと同じです。
タイプ：Zabbixエージェント
net.dns[<ip>,zone] <ip>は省略可
zoneの名前引きができれば1、できなければ0を取得します。
トリガー条件で「アイテム<1」としておけばDNSが利用できなくなったらアクションを起こせます。
net.tcp.listen[port]
portがLISTEN状態か確認し、LISTENであれば1、なければ0を取得します。
トリガー条件で「アイテム<1」としておけばアクションを起こせます。
net.tcp.port[<ip>,port] <ip>は省略可
portに対してTCPコネクションが作成できるか確認し、できれば1、できなければ0を取得します。
トリガー条件で「アイテム<1」としておけばアクションを起こせます。
listenだけでは不安な場合はこちらも使うと良いです。
net.udp.listen[port]
portがLISTEN状態か確認し、LISTENであれば1、なければ0を取得します。
トリガー条件で「アイテム<1」としておけばアクションを起こせます。
proc.mem[name]
プロセス名がnameの利用メモリ量を取得します。
proc.num[name]
プロセス名がnameの数を取得します。
vfs.file.cksum[file]
fileのチェックサムを計算し取得します。チェックサムに変更があればfileは変更されたことになるので、改ざん検知に使えます。
タイプ：Zabbixエージェント（アクティブ）
log[file,<pattern>]
fileにpatternがあれば取得します。
/var/log/mssageにerrorが吐かれたら取得というように使えます。
トリガー条件に「アイテム.diff(0)>0」としておけば、アクションが起こせます。
他にもたくさんありますが、よく使いそうなものを挙げてみました。
SNMPv2エージェントも説明したかったのですが、まだ理解が浅く作成時にエラーが出てしまうので、理解が深まったときに説明します。
次回以降に、これらを使ってさまざまなアイテム、トリガーを作ります。
今回はここまで。
2015年2月11日水曜日
ZABBIXサーバのhttpdを監視しよう
今回から各種ミドルウェアの監視を設定していきます。
まずは、ZABBIXサーバのApacheの監視をして、異常があったら再起動するように設定します。
Apacheが動いてないとZABBIXが使えませんから。
独立したテンプレートを作成するので、ZABBIXサーバ以外で稼働させるウェブサーバも、今回のテンプレートを適用するだけで監視ができ、異常があったら再起動してくれるようになります。
ZABBIXをインストールした時点でテンプレートとしてTemplate App HTTP Serviceができています。ただしこれはアイテムとして80番ポートのLISTENを見るだけの監視になっています。
そのため、今回はこれは使わないことにします。
そして実は基本的な監視のテンプレートは、ZABBIXの公式ページにも公開されています。
http://www.zabbix.jp/documents/template
ところが、今回使いたいTemplate_App_httpdは残念ながら古いバージョンのZABBIX用のテンプレートになっているようで、利用しようとするとエラーが出てしまい使えません。
そのため、これと同じ内容のアイテム、トリガーを１つ１つ作っていきます。
作っていくにあたって先に公開されているTemplate_App_httpdを読み解いておきます。
ダウンロードしてメモ帳などで開いてみてください。
4行目にテンプレート名が書かれています。「Template App httpd」です。
11行目に所属グループが書かれています。「Templates」です。
13〜367行目にアイテムついて書かれています。次のとおりです。
15行目の<description>がアイテムの名前です。「Log of $1」です。
$1は後に出るキーの[ ]内にある最初の文字列になります。このアイテムの場合は、/var/log/httpd/access_logになります。
14行目のtypeがアイテムのタイプです。「ZABBIXエージェント（アクティブ）」です。
ちなみに今回出てくる0と7はそれぞれ次のようになります。
同じく14行目のvalue typeがデータ型です。「ログ」です。
ちなみに今回出てくる2と3はそれぞれ次のようになります。
18行目の<history>がヒストリ保存期間（日）です。「90」です。
19行目の<trends>がトレンド保存期間（日）です。「365」です。
20行目の<status>が1ですので、「有効」になります。
38行目の<application>がアプリケーションです。「HTTP」です。
同じ要領でこれ以降のアイテムも読み解いてください。
続いて368〜432行目にトリガーについて書かれています。次のとおりです。
370行目の<description>がトリガーの名前です。「/etc/httpd/conf/httpd.conf has been changed on {HOSTNAME}」です。
372行目の<expression>が条件式です。「{{HOSTNAME}:vfs.file.cksum[/etc/httpd/conf/httpd.conf].diff(0)>0」です。
371行目の<type>が障害イベントを継続して生成です。0なので無効です。
374行目の<status>が0ですので「無効」ですが、テンプレート作成時に有効にします。
375行目の<priority>が深刻度です。「情報」です。
ちなみに今回出てくる1と3はそれぞれ次のようになります。
433行目以降のグラフについては割愛します。
それでは上記に従ってテンプレートの内容を新規に作ります。
テンプレートを作ります。
アプリケーションを作ります。
アイテムを作ります。
まずは、ZABBIXサーバのApacheの監視をして、異常があったら再起動するように設定します。
Apacheが動いてないとZABBIXが使えませんから。
独立したテンプレートを作成するので、ZABBIXサーバ以外で稼働させるウェブサーバも、今回のテンプレートを適用するだけで監視ができ、異常があったら再起動してくれるようになります。
ZABBIXをインストールした時点でテンプレートとしてTemplate App HTTP Serviceができています。ただしこれはアイテムとして80番ポートのLISTENを見るだけの監視になっています。
そのため、今回はこれは使わないことにします。
そして実は基本的な監視のテンプレートは、ZABBIXの公式ページにも公開されています。
http://www.zabbix.jp/documents/template
ところが、今回使いたいTemplate_App_httpdは残念ながら古いバージョンのZABBIX用のテンプレートになっているようで、利用しようとするとエラーが出てしまい使えません。
そのため、これと同じ内容のアイテム、トリガーを１つ１つ作っていきます。
作っていくにあたって先に公開されているTemplate_App_httpdを読み解いておきます。
ダウンロードしてメモ帳などで開いてみてください。
4行目にテンプレート名が書かれています。「Template App httpd」です。
11行目に所属グループが書かれています。「Templates」です。
13〜367行目にアイテムついて書かれています。次のとおりです。
15行目の<description>がアイテムの名前です。「Log of $1」です。
$1は後に出るキーの[ ]内にある最初の文字列になります。このアイテムの場合は、/var/log/httpd/access_logになります。
14行目のtypeがアイテムのタイプです。「ZABBIXエージェント（アクティブ）」です。
ちなみに今回出てくる0と7はそれぞれ次のようになります。
0 - ZABBIXエージェント同じく14行目のkeyがアイテムのキーです。「log[/var/log/httpd/access_log]」です。
7 - ZABBIXエージェント（アクティブ）
同じく14行目のvalue typeがデータ型です。「ログ」です。
ちなみに今回出てくる2と3はそれぞれ次のようになります。
2 - ログ17行目の<delay>が更新間隔（秒）です。「300」です。
3 - 数値（整数）
18行目の<history>がヒストリ保存期間（日）です。「90」です。
19行目の<trends>がトレンド保存期間（日）です。「365」です。
20行目の<status>が1ですので、「有効」になります。
38行目の<application>がアプリケーションです。「HTTP」です。
同じ要領でこれ以降のアイテムも読み解いてください。
続いて368〜432行目にトリガーについて書かれています。次のとおりです。
370行目の<description>がトリガーの名前です。「/etc/httpd/conf/httpd.conf has been changed on {HOSTNAME}」です。
372行目の<expression>が条件式です。「{{HOSTNAME}:vfs.file.cksum[/etc/httpd/conf/httpd.conf].diff(0)>0」です。
371行目の<type>が障害イベントを継続して生成です。0なので無効です。
374行目の<status>が0ですので「無効」ですが、テンプレート作成時に有効にします。
375行目の<priority>が深刻度です。「情報」です。
ちなみに今回出てくる1と3はそれぞれ次のようになります。
1 - 情報同じ要領でこれ以降のトリガーも読み解いてください。
3 - 軽度の障害
433行目以降のグラフについては割愛します。
それでは上記に従ってテンプレートの内容を新規に作ります。
テンプレートを作ります。
アプリケーションを作ります。
アイテムを作ります。
トリガーを作ります。
アイテム一覧、トリガー一覧がこのようになります。
続いてApacheの障害を検知した際に再起動するようにアクションを設定します。
前回のブログと同じ要領で作成します。
ただし、アクションの実行条件が少し複雑です。
ここまでできたら、Template App httpdをZabbix serverに適用します。
設定メニューのホストを選びます。
Zabbix serverの文字をクリックします。
テンプレートを選びます。
新規テンプレートをリンクに「Template App httpd」と入力し、枠内の追加を押します。
更新ボタンを押したら完了です。
httpdの監視ができました。Apacheのログは/etc/httpdのパーミッションを755にすると取得できます。
ためしにApacheを停止してみますが、数分後には自動的に起動しています。
※監視の間隔が5分なので数分待ちます。
最後に、今回作成したテンプレートのxmlファイルを公開しておきますので、うまくいってない方がいらっしゃればお使いください。
今回はここまで。
2015年2月9日月曜日
ZABBIXサーバでswap領域を作ってしまおう
今回はトリガーとアクションを追加して、前回まで出ている警告を対処する解説です。
概要としては、「swap領域が無かったら、swapファイルを作成してswap領域としてマウントする」になります。
Template_OS_LinuxにはすでにアイテムとしてTotal swap spaceというアイテムがあります。
swapの総容量を確認するアイテムです。
このアイテムに対して0だったらというトリガーを作ります。
Template_OS_Linuxの行のトリガーの文字をクリックします。
右上にあるトリガーの作成を押します。
名前を適当に入力します。（例： Trigger_No_Swap）
条件式の右にある追加を押します。
アイテムの右にある選択を押します。
右上のホストでTemplate_OS_Linuxを選びます。
関数には「前回の値=N」を選びます。
Nは0のままとします。
障害イベントを継続して生成にチェックを付けます。
深刻度に警告を選び、追加を押します。
以上で、追加を押します。
トリガーの一覧画面にTrigger_No_Swapが追加されました。
しばらくするとダッシュボードにTrigger_No_Swapに対しての警告が現れます。
Total swap spaceの監視間隔が3600秒になっているため、最大で1時間待つことになります。
続いてアクションを追加します。
設定メニューのアクションを押します。
右上にあるアクションの作成を押します。
名前を適当に入力します。（例： Action_No_Swap）
アクションの実行条件を押します。
新規条件でトリガー名となっている箇所をトリガーに変更します。
新規条件の右の選択の文字をクリックします。
右上のホストをTemplate_OS_Linuxにします。
Trigger_No_Swapの文字をクリックします。
新規条件の枠内にある追加の文字をクリックします。
アクションの実行内容を押します。
アクションの実行内容の枠内にある新規の文字をクリックします。
実行内容のタイプをリモートコマンドに変更します。
ターゲットリストの枠内にある新規の文字をクリックします。
ターゲットが現在のホストになっている状態で、枠内にある追加の文字をクリックします。
コマンドに次のように入力します。
[ ! -f /swapfile ] && sudo dd if=/dev/zero of=/swapfile bs=1M count=512;
sudo chmod 600 /swapfile;
sudo mkswap /swapfile;
sudo swapon /swapfile;
実行内容の詳細の枠内にある追加の文字をクリックします。
最後に追加を押します。
アクションが追加されました。
しばらくするとAction_No_Swapが実行され、swap領域が作成されます。
それにより警告が解消します。
Total swap spaceの監視間隔が3600秒になっているため、最大で1時間待つことになります。
swap領域が作成され、警告が解消されました。
今後作成したサーバにTemplate_OS_Linuxを適用するだけで、swapの総容量が確認され、もし0byteだった場合には、swap領域が自動で作られ、警告が無くなります。
とても便利だと思います。
今回はここまでです。
概要としては、「swap領域が無かったら、swapファイルを作成してswap領域としてマウントする」になります。
Template_OS_LinuxにはすでにアイテムとしてTotal swap spaceというアイテムがあります。
swapの総容量を確認するアイテムです。
このアイテムに対して0だったらというトリガーを作ります。
Template_OS_Linuxの行のトリガーの文字をクリックします。
右上にあるトリガーの作成を押します。
名前を適当に入力します。（例： Trigger_No_Swap）
条件式の右にある追加を押します。
アイテムの右にある選択を押します。
右上のホストでTemplate_OS_Linuxを選びます。
一覧からTotal swap spaceを選びます。
関数には「前回の値=N」を選びます。
Nは0のままとします。
障害イベントを継続して生成にチェックを付けます。
深刻度に警告を選び、追加を押します。
以上で、追加を押します。
トリガーの一覧画面にTrigger_No_Swapが追加されました。
しばらくするとダッシュボードにTrigger_No_Swapに対しての警告が現れます。
Total swap spaceの監視間隔が3600秒になっているため、最大で1時間待つことになります。
続いてアクションを追加します。
設定メニューのアクションを押します。
右上にあるアクションの作成を押します。
名前を適当に入力します。（例： Action_No_Swap）
新規条件でトリガー名となっている箇所をトリガーに変更します。
新規条件の右の選択の文字をクリックします。
右上のホストをTemplate_OS_Linuxにします。
Trigger_No_Swapの文字をクリックします。
新規条件の枠内にある追加の文字をクリックします。
アクションの実行内容を押します。
アクションの実行内容の枠内にある新規の文字をクリックします。
実行内容のタイプをリモートコマンドに変更します。
ターゲットリストの枠内にある新規の文字をクリックします。
ターゲットが現在のホストになっている状態で、枠内にある追加の文字をクリックします。
コマンドに次のように入力します。
[ ! -f /swapfile ] && sudo dd if=/dev/zero of=/swapfile bs=1M count=512;
sudo chmod 600 /swapfile;
sudo mkswap /swapfile;
sudo swapon /swapfile;
実行内容の詳細の枠内にある追加の文字をクリックします。
最後に追加を押します。
アクションが追加されました。
しばらくするとAction_No_Swapが実行され、swap領域が作成されます。
それにより警告が解消します。
Total swap spaceの監視間隔が3600秒になっているため、最大で1時間待つことになります。
swap領域が作成され、警告が解消されました。
今後作成したサーバにTemplate_OS_Linuxを適用するだけで、swapの総容量が確認され、もし0byteだった場合には、swap領域が自動で作られ、警告が無くなります。
とても便利だと思います。
今回はここまでです。
登録:
投稿 (Atom)