この記事は1年以上編集されていないため、情報が古い可能性がございます。
ご注意ください。

このWordPress pluginを配布しています

art-zabbix
自分用のカンペです。

ある程度度のサービスにも必要となる監視アイテムは決まっていますので、テンプレートを用意しておくと監視の設定で楽ができます。

Linux

CentOS or Amazon Linuxを想定しています。

  • CPU使用率(%)
{Template OS Linux:system.cpu.util[,idle,avg1].count(#2, 15, "le")}=2
  • 1分平均のload average
{Template OS Linux:system.cpu.load[percpu,avg1].count(#2, 3, "ge")}=2

5分、15分のLoad Averageも同様です。
古いZabbixにはpercpuというアイテムがないので、閾値を上げて調整してください。

  • /のディスク空き(%)
{Template OS Linux:vfs.fs.size[{#FSNAME},pfree].count(#2, 15, "le")}=2
  • /のノード空き(%)
{Template OS Linux:vfs.fs.inode[{#FSNAME},pfree].count(#2, 15, "le")}=2
  • swap有無
{Template OS Linux:system.swap.size[,used].abschange(0)}=1

通常Swapが発生しない前提ですね。

  • bootした時間、boot発生を検知
{Template OS Linux:system.boottime.diff(0)}>0
  • パスワード、パスワードの変更を検知
{Template OS Linux:vfs.file.cksum[/etc/passwd].diff(0)}>0

WEBサーバ(nginx)

  • HTTP死活監視
{Template_Nginx:net.tcp.service[http,,80].count(#2,0)}=2

以下の手順が必要です。

  1. nginxでステータスを出力する
  2. Zabbix公式からnginxのテンプレートを入手する
  • ログ監視
{HOST_NAME:log[/var/log/messages,@messages].iregexp(@messages)})#0&({HOST_NAME:log[/var/log/messages,@messages].nodata(300)})=0

APサーバ(Servletコンテナ)

  • HTTP死活監視
{Template_Apserver:net.tcp.service[http,,8080].count(#2,0)}=2

テンプレートはTomcat等をカスタマイズ。

  • ログ監視

nginxと同等のトリガー設定です。

Database(RDS)

  • CPU使用率(%)
{rds:cloud_watch["--metric","CPUUtilization","--dimension_name","DBInstanceIdentifier","--dimension_value","instance-name","--statistics","Average","--service","RDS","--region","ap-northeast-1"].count(#2, 85, "ge")}=2
  • ディスク空き容量が15GB以下
{rds:cloud_watch["--metric","FreeStorageSpace","--dimension_name","DBInstanceIdentifier","--dimension_value","instance-name","--statistics","Average","--service","RDS","--region","ap-northeast-1"].count(#2, 15000000000, "le")}=2
  • swap有無
{rds:cloud_watch["--metric","SwapUsage","--dimension_name","DBInstanceIdentifier","--dimension_value","instance-name","--statistics","Average","--service","RDS","--region","ap-northeast-1"].count(#2, 1, "ge")}=2
  • スレーブ遅延
{rds-read-replica:cloud_watch["--metric","ReplicaLag","--dimension_name","DBInstanceIdentifier","--dimension_value","instance-name","--statistics","Average","--service","RDS","--region","ap-northeast-1"].count(#2, 3, "ge")}=2

先にCloud Watchと連携する必要がありますね。
instance-nameをうまく変数化できずに、テンプレートかできなていない状態です。

Web(コンテンツ)

  • 死活監視
{domain:web.test.fail[web_monitoring_name].count(#2,1)}=2
  • レスポンスタイム監視
{domain:web.test.time[web_monitoring_name,{$URL},resp].count(#10, 3, "gt")} >5

先にWEB監視を設定してください。
以下にまとめております。

[監視][Zabbix]Web監視(コンテンツ監視)の設定方法
Web監視を設定しているにもかかわらず、サービス障害時にアラート通知が発生せず対処が遅れるということがあり、Zabbixのウ...

その他

監視する環境について

「開発やステージング環境」もしっかり監視することで、例えば「ログの量が多すぎる」などの傾向を事前にキャッチすることができます。

しかしながら、「商用環境」と「その他、開発やステージング環境」の監視窓は分けるほうが良いですね。
理由は「商用環境の監視をしているときにステージングのアラートが入ってビックリする」からです。

アラートの数が多すぎると、大切なアラートを見落としがちになりなってしまいます。
まるで、オオカミ少年みたいな話ですね。

そうなると、本当に大変な状況に陥った時の初動が遅れてしまいますので、「何を通知するか」はしっかり検討してください。


トリガーはほとんど標準テンプレートのままのものばかりでしたね。。。

上の方々にアラートが飛ぶと過剰に反応してしまいますので、同じアイテムに対し複数のトリガーを立ててエラーレベルを分け、「全体アラートが出る前に、自分にアラートが入る」ようにしておくと、初動が早くなり先手を打つことができますよ。

この記事はtomita@atuwebがお届けしました。




2015年12月23日:Web監視など追記

スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存