*

改善していける監視を目指して 第二回

公開日: : クラウド, ネットワーク

ネットワークG 平(ひら)です。

第一回では、主にクラウドサービスの状態監視(イベント監視)に関
するポリシーを二つご紹介いたしました。第二回では、そのポリシー
のうち『わかりやすい』について、取り組んでいる内容をこの場を借
りて書いていきたいと考えています。

サマリ

今回の記事のサマリとして、マインドマップで可視化した私が考える
監視についてを掲載させて頂きます。この画像を見てくださいました
ら、およそこの記事を俯瞰できるようになっています。

『わかりやすい』と『つかいやすい』は両翼になりますので、今後また
ブログの寄稿とともにこの図の左側にも私の考えを記載して参ります。

number2-mindmap

わかりやすいとは

前の記事で掲げた『わかりやすい』というポリシーは以下の通りです。
このポリシーをどう分類して、監視に組み込んでいるか(あるいは、
組み込もうとしているか)を書いていきます。

  • 作業による誤報等が少ない。
  • サービス名やフロア(ロケーション)情報が見やすい。
  • 既知のアラートと新規のアラートが明確に分離される。
  • 監視インフラはシングルで、壊れた時の対応(急いで直す)も明確。

誤報の削減

監視においていつも悩まされているのが、作業による誤報となります。
例えば、NW運用担当からすると、自らの作業時の誤報(VersionUP後、
SNMP Trapが追加で飛ぶようになってしまった等)の他、サーバ担当の
作業によるリンク状態変更等も誤報となります。私自身NW運用担当で
あるため、そういったアラートには良く対応していました。

経験上、作業による誤報を減らすためには、以下の取り組みが有効で
あると考えております。

  • 監視抑止が漏れないよう、ルールが明確な監視を設計する。
  • 監視設計において、作業手順化し作業者が守りやすいルールを心がける。
  • 監視抑止のインターフェースを一元化し、複数の抑止設定がないようにする。
  • イベント監視型のアラート通知は、必要なものだけに絞る。

これらの取り組みのうち、大きな改善としては『アラート通知を必要
なものだけに絞る』が最も有効と考えています。サーバエッジスイッチ
のイベント監視を例に挙げると、エッジスイッチのリンク状態を監視
することよりも、サーバそのものの監視で異常に気付く方が、大事な
場合が多くあります。そのため、こういったイベント監視については、
傾向を見るだけに留めるよう逐次運用を変更しています。

その他、必要な監視は残っていきますが、それらの監視について監視
抑止がしやすいことも大事です。これは、『つかいやすい監視』の回
でご説明いたします。

サービス・ロケーションの迅速な把握

次に、監視において、実際に障害を検知したときに最も重要になるの
が、サービスやロケーションの迅速な把握です。これは、ある程度作
りこんだとしても、その後も常に改善を続けていくことになると考え
ております。

現状で、サービス・ロケーションを把握できるようにするための取り
組みとしては、以下のようなものがあります。

  • ホスト名に、サービス名やロケーションを含めるようルールを作る。
  • 監視登録名に、サービス名やロケーションを含める。
  • アラートの通知から、切り分けWEBにリンクされている。
  • アラート通知と構成管理DBを連携し、対象顧客とステータスを表示する。

その他、イベント監視という視点ではなく監視全体で考えると、Cacti
のWeathermapプラグイン等での可視化は、今すぐに導入出来る監視と
しては非常に優れているように感じます。ただ、クラウド基盤の拡張
に対してスケーラビリティの確保が難しいなど、別の問題があります。
これらに関しては、長期状態監視に関する記事で問題点や取り組みを
ご紹介していこうかと思います。

既知アラートの蓄積

現在の検証プロセスにおいて、全ての監視アラートを運用前に事前定義
することは正直できておりません。(そもそもそのプロセスを改善せよ、
というご指摘が各所から聞こえてくるような気持ちです、頑張ります)

もちろん、検証時のログを蓄積しておき、切り替わりが発生するような
重大なイベントについては、既知のアラートとするような取り組みは
現在も行っております。

しかしながら、予期せぬアラートというものはどうしてもあり、その
場合は『未知の新規アラート』として検知しています。しかしながら、
『未知の新規アラート』には以下のリスクがあります。

  • 影響範囲も未知なので、輪番担当へのエスカレーションが発生する。
  • エスカレーションの際、ログ以外に情報がない状態でエスカレーションされる。
  • どのような影響があるか不明なので、全ての運用者に通知が行われてしまう。

こうしたこと背景から、ビットアイルクラウドのイベント監視におきま
しては、『未知の新規アラート』が発生した場合、事象の原因や影響が
わかり次第、既知のアラートとして蓄積する仕組みを導入しております。

あくまで内製のツールとなりますが、syslog-ngと連携して条件判断
を行い、既知のアラートと未知の新規アラートを明確に区別して通知
することが出来ます。日々の運用で未知の新規アラートと遭遇した時、
それを既知のアラートとすることで『また一つ基盤を改善した』とい
う実感を得ています。

出来ればかっこよくここで『Perlライブラリ公開しました』等と言え
れば良いのでしょうが、あいにく自分の作ったコードは可読性に優れ
ているとは言い難いため、社内利用に留めておきます。

わかりやすい監視インフラ

わかりやすい監視インフラ、というポリシーに基づき、ビットアイル
クラウドの監視インフラでは、『サービスネットワークから完全に独
立した監視ネットワーク』を構築しています。これを、世の中一般的
にはアウトオブバンド方式の監視と呼びます。

このアウトオブバンド方式の監視には、以下のような利点があります。

  • サービス障害時において、(災害でない限り)監視系が正常である。
  • そのため、サービスに生じた障害によりログが取れない、等の問題が起きづらい。
  • 監視系の障害時において、(災害でない限り)サービスが正常である。
  • 監視系の変更において、不慮の事故や障害が発生した際、サービス影響がない。

もちろん、お客様に提供するサービスには直接影響がないとしても、
プロセスによって障害を防ぐような取り組みを行っております。しか
しながら、監視系ネットワークには、必要なタイミングで必要な変更
を行える柔軟性と、日々の改善に追従できる迅速性が求められます。

その柔軟性、迅速性を実現するために、アウトオブバンド方式の監視
は必須であると考えております。そのため、ビットアイルクラウドで
は、完全に独立した監視管理のみのインフラを準備しています。

監視のポリシーについて南部から薫陶を受けた際、最も重要であると
念を押された部分がこの部分です。教えられた通りアウトオブバンド
方式を守りながら各方面からの依頼を承ってきましたが、いざ整理し
てみるとその効果は大きかったです。特に、サービスと切り離されて
おり、日々の改善を適用しやすいのは非常に大きいと考えています。

もちろん、冗長化されていないが故に故障したら一生懸命直す必要は
ありますが、故障によるサービス影響がないことも担保しているため、
落ち着いて対処すれば問題ありません。

以上が、わかりやすい監視として挙げた4つのキーポイントと、それが
ビットアイルクラウドの監視にどう活かされているかとなります。

おわりに

第二回では、『わかりやすい監視』に関する取り組みをご紹介させて
頂きました。どれも一般的に行われている可能性は大いにありますが、
サービス事業者としてお客様のシステムをお預かりする以上、今後も
出来る限りの改善を重ねて参ります。

第三回は、『つかいやすい監視』に関する取り組みについてご紹介する
予定です。宜しくお願い致します。

関連記事

ispっぽく

Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。 前回は2台のubuntu間でpingが届くところまで確認しましたが

記事を読む

cloud-mon

改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle promptに記事を寄稿するにあたり、新し

記事を読む

no image

誤解しがちなVMware等のHyper VisorのHAの期待効果

VMware 等の Hyper Visor の HA 冗長構成では MTBFを改善できない。

記事を読む

techops

システム運用サービスで必要なこと

こんにちは。ビットアイルの 大野 です。 本日は ITシステムにおける一連のライフサイクルの中

記事を読む

awssummt

新入社員がAWSサミットに参加してきました。

こんばんは、最近配属が決まったばかりのビットアイル新入社員です。 先週7/17、18に品川で開

記事を読む

kousei

Juniper FireFlyでJUNOSと仲良し

ネットワークG 南部です。 普段からネットワークに触れていることを楽しんでいるのですが、最近の

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が Softlayer を買収したニ

記事を読む

構成図

Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き Softlayer についての記事

記事を読む

no image

ビットアイル・エクイニクスのエンジニアブログです。データセンターの最前線から様々な情報をお伝え致します。

構成図
Softlayer Direct Link を smokeping で測ってみた ~その2 インスタンスの作成~

こんにちは。 ネットワークGの藤岡です。 前回に引き続き So

構成図
Softlayer Direct Link を smokeping で測ってみた ~その1 構成~

こんにちは。 ネットワークGの藤岡です。 昨年 IBM が S

cloud-mon
改善していける監視を目指して 第二回

ネットワークG 平(ひら)です。 第一回では、主にクラウドサービ

cloud-mon
改善していける監視を目指して 第一回

ネットワークG 平(ひら)です。 Bit-isle prompt

ispっぽく
Juniper FireFlyでJUNOSと仲良し その2

ネットワークG 南部です。 前回は2台のubuntu間でping

→もっと見る

PAGE TOP ↑