詳細
簡単に私の経歴についてご紹介させていただきます。
某 IT 企業の社内インフラ、運用チームのオペレーター業務からこの業界に入り、その後インフラ、特に Linux サーバーやストレージ等を中心とした構築業務を実施してまいりました。
一部開発案件を実施しており、その延長上で数年前からKompira Enterpriseのジョブフロー開発、Kompira Cloudの導入支援やプリセールスの場における各製品の説明等も行なっております。
全体的に浅くではありますが、運用構築開発を広く担当させて頂いております。
自己紹介はこれぐらいにさせて頂いて、早速始めさせていただきたいと思います。
そうだ！Sonarしよう
運用現場などで機器の構成管理をExcelで行っている案件というのは少なくなっていると思いますが、それでも構成情報は手動管理で、いざ構成情報を見て作業を行おうとすると情報に差違があったり、構成情報収集を自動化したいんだけど、エージェントタイプのソフトはノードへの導入許可が取りにくいだとか、
せっかく構成情報を取得したんだから、別な、もっと色々なところと連携できないだろうか、といった問題や課題などがあったりするのではないでしょうか。
そこで「そうだ、Sonarしよう」ということで、Kompira Sonarの、より一歩進んだ構成管理情報の利用方法という形で構成例を考えてみましたので、この場を借りてご紹介させていただければと思います。
Kompira Sonarの簡単なご紹介をさせていただきます。Kompira Sonarは、構成情報管理の自動化のためのマイクロサービスとなっております。こんなことができるよというポイントをここではいくつか紹介させていただきます。
まずはエージェントレスなので、導入にあたり既存ノードに何かツールを入れる必要がありません。また新しいノードがネットワークに追加された際もすぐに発見することができます。
次に定期的なスキャン。スケジュール設定により、ネットワーク内のノード情報を最新化させることができます。スケジュールの最小単位は一日一回ですが、スケジュールをいくつも作ることができるので半日に一回といったスケジュールも作成可能です。またGUIで実行可能なことはすべて API で実行可能となりますので、 API のやり取りができるすべてのツールやサービスと連携が可能となっております。
最後に、Kompira Sonarはスキャン対象ネットワークに1台、ksocketと呼ばれるスキャンを行うためのクライアントを導入する必要があるのですが、このksocketから各種必要な通信が可能なネットワークであれば、それらのネットワークをまとめて1台のksocketで構成情報の収集を行うことが可能となります。
こちらはKompira Sonarの構成例となります。スライド内の中央付近、セグメント B にksocketを配置している例となります。先ほど説明した通り、ksocketからアクセス可能であれば拠点問わず別拠点などの情報も取得可能となりますので、ksocketを導入したセグメントとは別のセグメント、この図であればセグメントAや、 VPN 越しの別拠点セグメントCのノード情報であっても取得することができます。
具体的には Linux であれば ssh、Windows であれば winrm、ネットワーク機器であれば snmp での疎通が可能であれば、構成情報の取得が可能となります。
ksocketで取得した構成情報はTCP443のwss通信にて、Kompira Cloudにアップロードされ、情報が管理蓄積されます。
GUI上ではIPアドレスやホスト名、導入パッケージ情報と、様々な条件でノードの検索を行うことが可能となっております。先程ご説明したこととなりますが、収集した情報は全て API で取得可能となりますのでセグメントC のサーバーから API で構成情報を取得し、別の用途に利用する、といったことも可能となります。
以上Kompira Sonarについて簡単にご紹介させていただきました。ここからは講演のメインテーマです。
Kompira Sonarの活用術
せっかく構成情報を取得管理しているのでそれらを素材とした運用現場を楽にするかもしれないレシピ・活用術について、実際の設定等とともにご紹介させていただきます。
ご紹介するのはアラート発生時にKompira Sonarで取得・管理しているノード情報を付与して、担当者にメール送信といった活用例となります。
私がオペレーターとして業務を行っていた時に何度か経験したことがあるのですが、障害発生のアラートメールを受信したはいいものの、手順書が見つからないとか認証情報が分からない、設置されたばかりのノードなどで OS やログイン方法もよく分からないといった事態に直面して、急いで各種情報を集めて、やっと対応開始みたいな問題が、ご紹介させていただく活用術によって改善されるかもしれません。
今回、活用術のご紹介に向けて活用例としてデモ環境を構築しておりますので、その環境に沿ってお話を進めさせていただきます。少し簡素な構成となっておりますがご了承ください。
こちらは構成例となります。
「DemoSpace」というネットワークを作成し、そこに Webサーバー、DBサーバーというサービス提供用のサーバーを用意しております。
そしてKompira Cloud上に 「demo-space-2020」というスペースを作成して、ネットワーク内のksocketサーバーがネットワーク内の情報をスキャンしアップロードします。
監視装置としてZabbixを配置してWebサーバーや DBサーバーに障害が発生した際に、同じくKompira CloudのサービスであるAlertHubのwebhookで障害を通知します。
AlertHubはKompira Cloudの新サービスで、アラートの集約や障害判断の自動化を行うサービスになりますが、ここでは細かい説明については省かせていただきます。
さらに今回の活用例の肝となる連携用サーバーとして webhookレシーバー、略して「whreceiver」というホスト名のサーバーを配置し、外部からの TCP 28080の通信を whreceiverにフォワードさせるといった構成となっております
whreceiverのことを単にレシーバーと呼ばせていただきます 。
この構成における連携イメージについてご説明させていただきます。
Webサーバー、DB サーバーで障害が発生した際の連携イメージとなります。障害のアラートはZabbixで検知され、Zabbixからそれをアクションとして webhookでKompira AlertHubに通知されます。
Kompira AlertHubでアラートを集約してレシーバーに webhookを通知し、レシーバーからKompira Cloudに API アクセスして情報を取得します。
最後にノード情報を付与して担当者にメールを送信します。この構成であれば直接Zabbixからレシーバーでwebhookを送信することも可能ですが、Kompira AlertHubを経由することによりアラートを集約し担当者に通知するメールを少なくすることが可能となります。
ここからは実際の設定での概要を紹介します。
まずはKompira Sonar側の設定です。活用例におけるKompira Sonarの役割は構成情報収集したノードの付加情報の管理/蓄積となります。
こちらはKompira Sonarで収集したノードの一覧となります。今回の活用例では、 Web サーバーのサービスが停止して障害が発生した場合を例に説明しています。
こちらは Web サーバーの構成情報の詳細画面となっております。右上にあるノートより、各ノードに追加情報という形で任意の情報登録を可能としています。
今回はノードの用途ですとか、簡易的な障害の対応手順であったり関連資料のパスであったりといった情報をノートとして追加しております。今回の活用例ではこちらのノート情報を利用します。
Zabbix設定
本活用例におけるZabbixの役割は、障害のアラート検知およびアクションにより webhookにてKompira AlertHubにwebhookを送信することです。
まずはアイテムとトリガー設定となります。
特別な設定は特になく、よくあるアイテムやトリガー設定かと思います。
そしてイベント発生時はアクションでwebhookを送信します。
アクション設定となります。
アイテムはトリガー同様に特別な設定は特になく、障害発生時や復旧時にユーザー側のメディアタイプ「AlertHub」に送信する設定としております。
こちらはメディアタイプ「AlertHub」の設定となります。メディアタイプのタイプ(Type)は webhookで作成しております。イベント発生時、発生したイベントに関連する情報や、送信先となるkompira AlertHubの受信スロットをパラメータとして設定し、スクリプト内容に沿って webhookをKompira AlertHubに送信します。
Kompira AlertHubの設定
本活用例におけるKompira AlertHubの役割はアラートの集約およびレシーバーへの通知です。
こちらは受信スロットと呼ばれるKompira AlertHubの webhook受付口となっております。特別設定項目はございません。
こちらはスコープと呼ばれるKompira AlertHubの監視単位となっております。
監視単位は任意の粒度で作成することが可能です。
スライドではWebサーバーとDBサーバーそれぞれの死活監視およびサービス監視の合計四つのスコープを作成していますが、今回はWebサーバーのhttpd 監視のスコープを使用します。
Webサーバーのhttpd監視のスコープに設定されているルールです。
ルールとは、webhookなどで受信したメッセージを条件判定して、深刻度と呼ばれる対象スコープのパラメーターを増減させるための条件となります。
今回はサービス障害、サービス復旧の二つのルールを作成しており、それぞれwebhookで受信したアラート情報の中からホスト名が Web サーバーであること、トリガーが Apache のサービスダウンであること、アラートステータスが障害であることや復旧であることを条件に、アラートステータスが障害なら深刻度を10にセット、復旧なら0にセットという条件としております。
こちらはトリガーの設定となります。
トリガーはイベントと呼ばれるスコープの深刻度変化に合わせて生成する、アクションの実行判断のようなものとなっております。ここでは二つ、それぞれステータスが障害になった場合、正常になった場合のトリガーを設定しており、それぞれ障害アクションや復旧アクションを実行するための条件となります。
今回は特別な条件なくアクションを発火させていますが、この設定を変更することにより、5分以内に復旧しない時のみ障害アクション発火、などの障害通知方法が設定でき、アラートの集約を行うことが可能です。
最後にトリガーから呼び出されるアクション設定となります。
webhookをレシーバーに送信するための設定となり、それぞれ障害と復旧のアクションを作成しています。送信するデータはアラート発生日時、アラート内容、ステータス、アラート発生ホスト、 IP アドレス、アクション名となり、送信するデータのほとんどの部分は同一となっていますが、どちらがアクションにより送信されたのか分かりやすくするため、アクション名というアクション固有の文字列を追加するようにしています。
レシーバー設定
本活用例におけるレシーバの役割は、Kompira AlertHubからのwebhook受信、Kompira Cloud へのAPIアクセス、対象ノードの詳細情報の取得、そして担当者へのアラート通知です。
こちらはレシーバーに焦点を当てた、もう少し細い構成となっております。動作内容としては TCP 28080でKompira AlertHubから送信されるwebhookを待ち受けます。
webhook受信後はWebookのデータに記された IP アドレスを利用してKompira Cloudに対してノード検索を行い、取得できたノード情報を利用しメール形成してメールを送信といった動作概要となります。
構成的には Python スクリプトおよび postfix がサーバーの主体となっており webhook待ち受けやKompira CloudへのAPIアクセス、メール送信命令は Pythonで動作をしており、メール送信は自身のpostfixを経由し、gmailへメールリレーを行います。
動作にあたり一部パラメーターはレシーバー内にパラメーターファイルを準備して、そこから読み込むようにしております。
今回使用するKompira Cloudの API は二つです。１つはノード検索を行うための API 、Post アクセスにて検索クエリを渡し、検索クエリに該当するノード情報を受け取るAPIです。ノード情報は Windows アップデートの詳細情報やパッケージ一覧、ノートといった情報以外の詳細情報を含んでおります。
今回はクエリー情報としてKompira AlertHubから受け取った IP アドレスを使用しています。
もう一つのAPI はノードに紐づくノート情報を受け取る API です。GETアクセスのURLの一部であるネットワーク ID とマネージドノード ID にて対象ノードを指定して、そのノードに設定されているノート情報を受け取ります。今回はノード検索で取得したノード情報を利用して URL の文字列を汲み上げております。
こちらは API の実行フロー、イメージの詳細となります。AlertHubからレシーバーにアラート情報送信後、その IP アドレスをクエリに利用してノード検索を行います。その結果ノード情報が返ってくるので、ノード情報に含まれるネットワーク IDとマネージドノード ID を、ノードのノート検索を行うためのURL の一部に使用してノードのノート情報を受け取ります。ここで得た情報を含めメール本文を作成いたします。
まずはサーバー用のスクリプト、こちらはwebhookを待ち受けして、Webhookを受信した後に受信時のメイン処理を呼び出すためのスクリプトとなっています。
続いてWebhook受信後のスクリプト、Kompira Cloud接続用のインスタンスを生成し、検索用の API実行や、そこで取得したノード情報にノート情報を付与した上、メール送信準備の後、指定された宛先にメール送信を行います。
メール本文やメール送信先などの情報は、パラメーターファイルに記載されています。
こちらはKompira Cloudの API を実行するためのクラスモジュールです。今回はノード検索やノードのノート情報を取得する二つの API を利用するため、その二つを呼び出すための処理を主に記載しております。
これは単純に自身のpostfix に対してメール送信をするための関数です。
最後に各パラメーターの定義を行っているスクリプトです。アクセスするKompira Cloudのインスタンス情報やAPIの実行用トークン及びメール送信に必要となる各種情報を定義しております。
システム連携画面
各サーバーについての説明は以上です。続いては実際の動作のイメージをご紹介させて頂きます。
まずは障害発生前となる画面です。
左上にはwebサーバーのコンソールが配置されており httpdが起動している状態です。右上はZabbixのダッシュボード、右下はKompira AlertHubのスコープ一覧です。現在は障害が発生しておらず、全て正常な状態となっております。左下はレシーバーのコンソール画面でスクリプトが起動しており TCP 28080でwebhookを待ち受けている状態となっております。
この状態で左上 Webサーバーのコンソールより httpdを停止させます。そうすると、まずはZabbixにてアラート検知し、その情報がKompira AlertHubにwebhook通知され、Kompira AlertHub上のスコープ深刻度が変化し障害となります。
その後Kompira AlertHubからレシーバーにwebhookが送信され、レシーバーでノード情報等を付与して、メール送信が行われます。
こちらが実際に送信されたメールとなっております。Zabbixで検知したアラート情報の他にKompira Sonarの機器情報ページへの URL や ID、さらにノードに登録されたノート情報が API によって取得され、併せてメール送信されます。
担当者はこのメールひとつで機器の詳細情報や手順書のパスなどの手がかりを取得することが可能となっております。
今度は Web サーバーでhttpdを起動し障害を復旧させます。 httpd が起動するとZabbix上で障害がなくなって、その通知がAlertHubに送信され、障害だったスコープが正常となります。
その後レシーバーにwebhookが通知された後、ノード情報をKompira Cloudから取得し、メール送信が行われます。
こちらが実際に送信されたメールとなります。障害メールと同様、Zabbixで検知したアラート情報の他にKompira Sonarの機器情報ページへの URL や ID を付与しておりますが、障害が復旧した場合には特別対応が必要なくなる想定として、復旧メールの場合はノートの情報は省いております。
デモ
今度は実際に画面を操作している動画をデモとしてお見せいたします。
こちらは実際の操作画面となっております。左上には構成図を表示しており、左下のコンソールはレシーバーのコンソール、真ん中の下のコンソールが Web サーバー、そして右下が DB サーバーのコンソールとなっております。
まずはレシーバーでスクリプトを起動してwebhookの待ち受けを行います。現在、障害は何も発生しておらず、メールも０件です。
この状態でDBサーバーの httpd サービスおよび DBサーバーのmariadbを停止します。それぞれのサービスを停止することでZabbixに障害が検知されます。その後AlertHubに webhookが届き、スコープが障害となったら、左下のレシーバーに webhook通知が届きます。そして障害メールを1通受信しました。こちらが Web サーバーの障害メールとなります。Kompira Sonarから取得した情報とともにノード詳細画面 URL も記載され、クリックすることでノードの詳細を確認することができます。
DBサーバーについても同じような内容のメール構成となっており、こちらのURLをクリックすることで詳細情報を確認することができます。
それでは今度は障害を復旧させてみます。それぞれのサーバーでサービスを起動させることにより、Zabbixで復旧検知が行われます。その後Kompira AlertHubのスコープも正常となり、障害復旧のメールが届きます。障害復旧メールも同じように、URLから詳細情報のページに飛ぶことが可能となっております。こちらが Webサーバーですね。次にDBサーバーの方も同じような形でURLが記載してあり、URL をクリックすることで DB サーバーの詳細情報の確認が可能となっております。
デモ動画はここまでとなっています。
今回はノード情報を中心にメールに付加情報を追加して送信しておりますが、Kompira Sonarのノードの情報は全て取得できているので、その他必要に応じてメールフォームに内容追加可能となっております。
発展形
更なる発展型といった形で少し考えてみたいと思います。こちらが発展型のイメージとなります。先ほどの構成例と異なる部分として、Kompira Sonarで取得した情報は CMDBで同期され、そこでは認証情報も含めた情報が管理されているものとします。またレシーバーはKompira Enterpriseへと変更され、同じようにwebhookの待ち受けを行っているものとします。
発展型では一部障害連絡用に自動電話サービスKompira Pigeonを利用するような構成となっております。
障害が発生した際に障害アラートをZabbixで検知して、その情報がKompira AlertHubに通知され、アラート集約後、Webhook送信するところまでは先ほどの構成例と同様となりますが、ここからKompira Enterpriseの自動化を利用し、CMDBにアクセスして認証情報や連絡先を取得します。
その後、入手した認証情報を利用し、障害発生サーバーへログインし、自動で一次対応し、もし障害が復旧した場合にはノード情報を付与して担当者に対応完了のメールを送信します。もし障害が復旧しなかった場合はKompira Pigeonを使って担当者に電話連絡を行うという動作が可能となっております。この構成であれば、簡単な障害であればオペレーターの手を煩わせることなく自動化で対応することができ、先ほどの構成例でサーバー側にパラメータとして用意していた連絡先などの情報もCMDBから取得することができます。
先ほどの構成例でも、Kompira Sonarのノード情報に連絡先や認証情報を入れておけば同じような事が可能となりますが、発展型ではCMDBでの集中管理ができるため、情報の差異が出にくく、より実践的な構成例になるかと思います。
他にも構成情報を利用した活用で思いつくものを挙げてみました。スキャン終了後に追加情報をサーバーから取得してCMDBに入れ込んだり、監視エージェントを自動的にインストールして用途に合わせた監視設定を投入したり、ブラックリストに登録されたアプリケーションを入れているノードがあったらすぐさま削除したりと、いろんな形でKompira Sonarの情報を活用できるかなと考えております。
最後になりますが今回は構成情報を活用術の例ということで設定等を中心に紹介させていただきました。
もっともっと良い構成情報の使い方や他サービスとの連携など沢山あるかと思いますが、より現場を楽にするための、より良い運用サービスのための検討に向けてのヒントになることができれば幸いです。
