Zabbixによる監視(4) 第05回 19年07月 / 最終更新：2019.07.04
目次
前回はZabbixの内部監視について説明しました。今回は内部監視をどのように使うかについて説明しようと思います。
内部監視で必要なこと
内部監視はホワイトボックステストです。それが故に、監視の優先度が重要になります。
まずは以下のように監視の重要度を分けましょう。重要度のしたに記述した項目はただの例示で、サービス内容やSLAによって異なります。
- サービス停止の監視
- OSの停止
- 必要なプロセスの停止
- ネットワークの停止
- DNSルックアップ不能
- ストレージの停止
- 必要なファイルの削除
- 監視エージェントへの接続不可
- サービス品質の監視
- ブートした時間(短くなっている)
- CPU使用量が100％ 近くの状態が続く
- プロセス数が上限近くの状態
- メモリ使用量が100％ に近づく
- ストレージの使用量が上限に近づく
- ストレージのinode数
- TCPのトラフィック、エラー数上昇
- ログファイルのエラー数上昇
- サービス停止に繋がらない監視
- ホスト名、システム名
- ハードウェア情報
- ログインユーザ名
- 時刻
- CPU使用率
- メモリ使用率
- ディスクリード・ライト量
- インタフェースへの入出力トラフィック
- プロセス数
- ログファイル
- システム統計情報(主要サービスプロセス)
サービス停止につながる監視
サービス停止やネットワーク状況によって、監視しているサーバでサービスが出来ない状態です。
もちろん、複数サーバでサービスを形成している場合、プロセスが停止しても上位にあるロードバランサが以上を検出して振り分け先を変更する場合が多いでしょう。その場合のアクションは、サービス停止したサーバを切り離して破棄し、新しいサーバを立てるだけで済みます。それ以外の場合は、すぐに代替サービスに切り替えられる構成へ見直すべきでしょう。
また、一部分だけ動作した状態でサービスし続けるのは問題が発生します。条件を満たさない場合は該当サーバをサービスから切り離したほうが良いでしょう。
OS停止の場合、Zabbix Agentだけではネットワーク断、OS停止のどちらか判断が付きません。外部監視やクラウドプロバイダからの情報と連携して状況を確認する必要があります。クラウドプロバイダで監視や状態取得のAPIを用意していたりするので、その情報と連携することも必要です。ただし、サービスによってはネットワーク断を契機にサーバを増やすというアクションをとっても良いと思います。
発生頻度は低いものの、発生時の問題が多いのはストレージの停止です。いくら冗長性を高めたストレージでも壊れるときは壊れます。また、ネットワークストレージを使用している場合でも、一時的なネットワーク断によりストレージの見えない状況が続きます。事前に提供サービスのSLAに合った高可用ストレージを使用するなど、事前の対策が必要です。
ストレージが壊れた場合はクラウドプロバイダと連携してストレージの復旧を図る、もしくは事前のバックアップから新しいストレージを用意するなどの手段が考えられます。いずれにせよクラウドプロバイダの協議(SLA違反かなど)は必要になると思われます。
サービスエージェントが停止するようなことは殆どありません。しかし、監視出来ない状況でサービス継続するのは問題があるので、サービス停止と同じ対応をとったほうが良いでしょう。
サービス品質の監視
特定サーバのブートした時間が短くなっているというのは、OS再起動された可能性が高いです。そのままサービスが継続しているのであれば、何らかの高付加でサービス継続できなった可能性があります。
CPU、メモリ、ストレージ容量、inode数、TCPエラー率の上昇などはサービス品質に影響があります。この場合サービスのレスポンスの遅延など、サービス継続に問題ある場合がほとんどです。
高不可でサービス品質が落ちている可能性がある場合、サーバ数を増やして対応しましょう。
サービス停止に繋がらない監視
サービス停止に繋がらない監視は、トレンド監視に用いられます。Zabbix Server で得られたサーバ使用状況をElasticsearch+Kibanaなどの別システムでグラフィカルに表示することも可能です。
このトレンド解析により、どの程度サービス使用が増加しているか、増加している日付、曜日、時間帯などを検出できます。また、サービスサーバ、ネットワーク、ストレージの見直しの指標とすることが出来ます。
最後に
内部監視ではいろいろな監視ができる分、何を行い何を行わないかという取得選択が重要になります。クラウド環境では容易にサーバの増減が出来ます。サービスの可用性はサーバ増減で行い、不要なサーバは即時に捨てて作り直すというモデルに考え方を変えていきましょう。
内部監視と外部監視、およびクラウドプロバイダの監視APIをうまく使い合わせて監視すると良いでしょう。
では、次回をお楽しみにお待ち下さい。
サービス・ソリューション
