Kompira cloud更新情報

2020年

12月

2020-12-04

  • AlertHubの静観スケジュールにて、毎日繰り返し静観スケジュールが設定できるようになりました
  • AlertHubのトリガーの実行条件に、「深刻度が増えた/減った」を追加しました

11 月

2020-11-30

  • Sonar の不具合修正を行いました
    • 新規ノードが発見されたときに、通知が行われない問題を修正しました
  • AlertHub のユーザー操作に対する応答を改善しました
    • 一部 API の処理速度を改善しました
  • AlertHubのメール受信スロットにてUTF-8以外のメールを受信した場合に、本文に対するルールが機能しない不具合を修正しました

2020-11-27

  • AlertHubデータ受信の安定性を向上しました
  • 外部からの攻撃に対する耐性を強化しました

2020-11-25

  • AlertHub に以下の変更を加えました
    • トリガーの実行条件について、指定時間の上限を1時間から6時間に変更しました
    • トリガーの実行条件について、イベント変化量の負の値が正常動作しない問題を修正しました

2020-11-19

2020-11-12

  • AlertHub のメッセージ受信安定度を向上

2020-11-11

  • セキュリティ強化のために認証方式を変更
    • 方式変更に伴ってログイン画面のデザインを変更

2020-11-02

  • APIドキュメントを更新しました
    • AlertHub 関連のドキュメント不備を修正
    • ユーザー管理関連のドキュメント不備を修正

10月

2020-10-19

  • Ksocket v2.2.0 をリリースしました
    • ARM 64bit(ARMv8 aarch64)対応版をリリース
    • コマンドのヘルプで利用可能コマンド一覧が表示されていなかった不具合を修正

2020-10-01

8月

2020-08-25

  • Ksocket v2.1.1 をリリースしました
    • 一部のサンプル設定ファイルがインストール時に展開されていなかった問題を修正

2020-08-21

  • Sonar のスキャンについて、SSH/WinRMによるホスト名の取得に対応

2020-08-19

  • Pigeon のコマンドジェネレータにおいて、ガイダンスの応答メッセージ内のマスタッシュ構文が展開されずパラメータ入力できないバグを修正
続きを読む

AlertHub の設定補助ツールを公開しました

AlertHub を利用するための設定を行うにあたって、 大量に設定登録する必要がある場合に利用できる設定補助ツールを公開しました。 それぞれ、READMEなどで利用方法を確認の上ご利用ください。

  • ルール/トリガー の一括登録ツール(Windows 用 exe ファイル)
    ダウンロード

  • スコープ/アクション/静観スケジュール の一括登録スクリプト(PowerShell スクリプト)
    GitHub ページ

多要素認証機能をリリースしました

Kompira cloud のログイン認証について、多要素での認証が行えるよう機能追加を行いました。
これまでの メールアドレス / パスワード の認証に加え、ショートメッセージによる認証コードを加えた認証が利用可能となります。

多要素認証を有効にするには、ログイン後にプロフィール設定から有効化を行ってください。

f:id:ueno-fixpoint:20201119140922p:plain

「AlertHub」を正式リリースしました

監視アラート情報を集約するサービス「AlertHub」について、 ベータ版として公開していたものを、この度正式版としてリリースいたしました。

f:id:ueno-fixpoint:20201008172507p:plain

秒間2,000件の大量アラートを処理でき、様々な条件でのフィルタリングが行えることで、 アラートの切り分け業務を大幅に省力化することが可能なサービスとなっています。

また、集約したアラートをメール送信やWebhook呼出、Pigeon呼出などに繋げられるため、 アラート対応の業務を自動化することも可能です。

ハンズオンガイドなども用意しておりますので、ぜひご一読ください。

AlertHub ハンズオンガイド

本記事の目的

AlertHubでアラートメッセージを集約するにあたって、 集約する要件を決定する流れと、その設定方法を具体例に沿って紹介しています。

本記事に記載されている設定と動作確認を行うことで、 AlertHubの設定の基本的な流れを理解することを目的としています。

アラート集約要件の決定例

本記事では、とあるWebサーバを担うホストに対して、HTTPリクエスト応答の有無の監視を行っている状況で、 監視によって通知されるアラートをAlertHubで集約することを考えます。

監視状況の確認もしくは決定

監視から通知されるアラートメッセージが、どのような仕様で送信されているかを確認、または送信するかを決定します。

ここでは、以下の仕様でアラートメッセージが送信されているものとします。

・異常が発生した場合にアラート通知が行われ、以降は復旧するまで異常は通知されない
・異常から復旧した場合にアラート通知が行われる

また、アラートメッセージはWebhookによって以下のJSONが送信されるものとします。

{
    "text": "http {TRIGGER.STATUS}",
    "host": "{HOST.NAME1}",
    "trigger": "{TRIGGER.NAME}",
    "severity": "{TRIGGER.SEVERITY}",
    "datetime": "{EVENT.DATE} {EVENT.TIME}"
}

AlertHubにおいてのスコープの決定

AlertHubの「スコープ」は 正常 / 警戒 / 障害 などの状態を管理する観点です。 単位については規定していないため、プロセス / サーバなどのホスト / ネットワーク機器 / サービス / データセンター など、 様々な粒度の要素をスコープとすることが可能です。

ここでは、ホストのWebサーバとしての状態をスコープとして設定することとします。

監視アラートの集約方法の決定

AlertHubは大量のアラートメッセージを集約することと、後続処理を自動化することが目的であるため、 アラートの集約方法と後続処理を決定します。

ここでは、以下の様な集約を行うものとします。

・異常が発生してアラートを受信し、1分間以内に復旧アラートを受信しなかった場合に障害発生としてWebhookを送信する
・異常のアラートを受信して1分間以上経過した後に復旧した場合に回復としてWebhookを送信する

Webhookでは以下のJSONを送信するものとします。

{
    "text": "[{{message.content.data.text}}]\n
        HOST:{{message.content.data.host}}\n
        SEVERITY:{{message.content.data.severity}}\n
        TRIGGER:{{message.content.data.trigger}}\n
        EVENT.DATETIME:{{message.content.data.datetime}}"
}

設定例

上記で決定した集約要件に従って、それを実現するための設定をAlertHubの各要素に対して行います。

受信スロット

f:id:ueno-fixpoint:20200930210428p:plain:w600

アラートメッセージを受信する受信スロットを作成します。

f:id:ueno-fixpoint:20200930200404p:plain:w300 f:id:ueno-fixpoint:20200930200439p:plain:w600

「表示名」を入力して「保存」することで受信スロットが作成されます。 f:id:ueno-fixpoint:20200930200604p:plain

作成後に受信スロットの表示名をクリックすることで、メッセージ受信の「エンドポイント」が確認できます。 監視から通知するアラートの送信先をエンドポイントのいずれかに設定するか、 動作確認時に使用するためにメモしておいてください。 f:id:ueno-fixpoint:20200930200651p:plain

アクション

f:id:ueno-fixpoint:20200930210509p:plain:w600

アラートメッセージの集約後に実行する処理を設定するためにアクションを作成します。 f:id:ueno-fixpoint:20200930200818p:plain:w300 f:id:ueno-fixpoint:20200930200846p:plain:w600

「表示名」「Webhook URL」「HTTPメソッド」「リクエスト本文」「HTTPヘッダ」を入力して「保存」することで アクションが作成されます。

「リクエスト本文」は、 {{message.content.data.[プロパティ名]}} と記述することで受信したアラートメッセージのJSONのフィールド値を含めることが出来ます。 ここではWebhookの送信先をSlackのIncoming Webhookとして「Webhook URL」に指定し、 「リクエスト本文」には以下を指定しています。

{
    "text": "[{{message.content.data.text}}]\n
        HOST:{{message.content.data.host}}\n
        SEVERITY:{{message.content.data.severity}}\n
        TRIGGER:{{message.content.data.trigger}}\n
        EVENT.DATETIME:{{message.content.data.datetime}}"
}

f:id:ueno-fixpoint:20200930201008p:plain

スコープ

f:id:ueno-fixpoint:20200930210600p:plain:w600

監視を行い、ステータスを管理する観点としてスコープを作成します。

f:id:ueno-fixpoint:20200930201123p:plain:w300 f:id:ueno-fixpoint:20200930201148p:plain:w600

「表示名」「障害判定閾値」「警戒判定閾値」を入力して「保存」することでスコープが作成されます。

「表示名」は後の検索性などを考慮して、観点の種別、ホスト名、監視の種別を含めています。 「障害判定閾値」「警戒判定閾値」はスコープのステータスを変化させる深刻度の閾値です。 深刻度が指定した値に達した場合にそのステータスとなります。 f:id:ueno-fixpoint:20200930201224p:plain

ルール

f:id:ueno-fixpoint:20200930210632p:plain:w600

受信したアラートメッセージの内容を判断して、どのようにスコープの深刻度を変化させるかを設定するために、 ルールを作成します。

f:id:ueno-fixpoint:20200930201351p:plain:w300 f:id:ueno-fixpoint:20200930201420p:plain:w600

「表示名」「受信スロット」「処理フロー」「イベント」を入力して「保存」することでルールが作成されます。

「処理フロー」はアラートメッセージのJSONのフィールド値に対して判定する条件を設定します。 JSONのフィールド値は message.content.data.[プロパティ名] で指定することが出来ます。 ここでは、障害アラートを処理するために以下の様なフローを設定しています。

[ホストの該当判定]
アラートメッセージ内のhostの値が現在設定しているスコープと一致していること
「フィールド(message.content.data.host)が文字列(vo-demo-wp2)とオペレータ(と等しい)で一致したメッセージを許可する」

[監視種別の該当判定]
アラートメッセージ内のtriggerの値に「HTTP」の文字列が含まれていること
「フィールド(message.content.data.trigger)が文字列(HTTP)を含むメッセージを許可する」

[アラート種別の判定]
アラートメッセージ内のtextの値に「PROBLEM」の文字列が含まれていること
「フィールド(message.content.data.text)が文字列(PROBLEM)を含むメッセージを許可する」

「イベント」ではスコープの深刻度の変化を設定するために、スコープを選択した上で深刻度の変化量を指定します。

「[host][vo-demo-wp2][HTTP] の深刻度を「1」「増やす」」

f:id:ueno-fixpoint:20200930201517p:plain

同様に回復アラートを処理するためのルールを以下の様に設定します。 f:id:ueno-fixpoint:20200930201559p:plain

トリガー

f:id:ueno-fixpoint:20200930210709p:plain:w600

スコープの深刻度が変化した際に、アクションを実行するか判断する条件を設定するために、トリガーを作成します。 f:id:ueno-fixpoint:20201001190631p:plain:w600 f:id:ueno-fixpoint:20201001185606p:plain:w600 f:id:ueno-fixpoint:20200930201803p:plain:w600

「表示名」「実行条件」「アクション」を入力して「保存」することでトリガーが作成されます。

ここでは、異常を検知してから1分間回復しなかった場合に障害通知を送信するために、 以下の様な条件を設定しています。

[ステータスが「正常」ではないことの判定]
「スコープステータスが文字列(正常)と等しい/等しくない(等しくない)ことを必要とする」

[1分後にもステータスが「正常」となっていないことの判定]
「(60)秒経過後、スコープステータスが文字列(正常)と等しい/等しくない(等しくない)ことを必要とする」

f:id:ueno-fixpoint:20200930201839p:plain:w600

同様に1分間異常が継続した後に回復通知を送信するために、トリガーを以下の様に設定します。 f:id:ueno-fixpoint:20200930201907p:plain:w600

動作確認

上記の設定が全て完了したら、アラートメッセージを実際に送信して動作を確認します。

受信スロットのエンドポイントに対してHTTPリクエストを送信します。 以下はcurlコマンドで障害アラートを送信する例です。

curl -X POST -H 'Content-Type: application/json' -d "{ \"text\": \"HTTP PROBLEM\", \"host\": \"vo-demo-wp2\", \"trigger\": \"HTTP\", \"severity\": \"warning\", \"datetime\": \"9999/99/99 99:99:99\" }" https://receiver.cloud.kompira.jp/webhook/xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

回復アラートの場合は以下の例の様に送信します。

curl -X POST -H 'Content-Type: application/json' -d "{ \"text\": \"HTTP OK\", \"host\": \"vo-demo-wp2\", \"trigger\": \"HTTP\", \"severity\": \"warning\", \"datetime\": \"9999/99/99 99:99:99\" }" https://receiver.cloud.kompira.jp/webhook/xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

※HTTPリクエストの送信には、talendなどのChrome拡張機能なども有効活用できます。


ここで、送信したHTTPリクエストによって以下の様な結果になれば動作確認は完了となります。

HTTPリクエスト 結果 スコープ
障害アラートを送信し、
1分以上経過した後に回復アラートを送信
障害アラート送信の1分後にSlackへ障害通知が送られ、
その後回復通知が送られる
深刻度が「0」→「1」、
「1」→「0」へ推移している
障害アラートを送信し、
1分以内に回復アラートを送信
Slackへは何も通知されない 深刻度が「0」→「1」、
「1」→「0」へ推移している

AlertHub 逆引き設定ガイド

本記事の目的

本記事では、具体的なアラートを集約する要件に対して、 AlertHub で実現するための設定方法を案内しています。

1. 夜間に自動で再起動しているので、00:00 から 01:00 についてはアラート発生時のメール送信が不要

設定

静観スケジュール

対象:再起動で発生するアラートが影響を与えるスコープの静観スケジュール
表示名:「日次夜間再起動の静観」など
開始:設定日の00:00
終了:設定日の01:00
繰り返し設定:チェック
曜日:全ての曜日をチェック

解説

AlertHub ではスコープに静観スケジュールを設定でき、
設定した期間においてはそのスコープのトリガーによるアクションが動作しなくなります。

アラートメッセージによってスコープの深刻度は変化しますが、
その結果としてのアクションは動作せず、アクションとして指定したメール送信などが行われません。


2. 日中帯と夜間帯で、アラート発生をメール送信と電話と切り替えて通知したい

設定

スコープ

日中帯用と、夜間帯用の2つのスコープを作成する

静観スケジュール

対象:日中帯用スコープの静観スケジュール
表示名:「夜間帯の静観」など
開始:設定日の18:00
終了:設定日の24:00
繰り返し設定:チェック
曜日:全ての曜日をチェック

対象:夜間帯用スコープの静観スケジュール
表示名:「日中帯の静観」など
開始:設定日の00:00
終了:設定日の18:00
繰り返し設定:チェック
曜日:全ての曜日をチェック

ルール

イベントにおいて、日中帯用スコープと夜間帯用スコープの両方に対して同様の深刻度変化をさせる

トリガー

日中帯用スコープと夜間帯用スコープで、それぞれ同様の条件を持つトリガーを設定し、
アクションには時間帯毎に適用したいアクションをそれぞれ指定する

解説

AlertHub では時間帯による制御が可能な要素はスコープの静観スケジュールのみです。
本来は1つのスコープで設定するものを、アクションを変化させるためにスコープを2つに分けて実現します。


3. 30分以内に10件以上アラートが発生したらメール送信してほしい

設定

ルール

イベント:深刻度を「1」「増やす」

トリガー

実行条件:過去「1800」秒間に「深刻度の変化量」が「1」「と等しい」イベントが「10」「以上の」回数発生した

解説

トリガーはイベント(スコープの深刻度の変化)が発生したタイミングで動作して判定を行いますが、動作時より過去のイベントの発生状態も実行条件とすることができます。


4. アラート発生の初報のみメール送信してほしい

設定

ルール

イベント:深刻度を「10」「にする」

トリガー

実行条件1:「深刻度」が「10」「と等しい」値である
実行条件2:「変化前の深刻度」が「10」「より小さい」値である

解説

まず、連続してアラートメッセージを受信した場合でも無闇に深刻度を上昇させないために、
ルールのイベントでは深刻度を絶対的な変化としています。
その上で、トリガーの実行条件は深刻度の絶対値を指定しています。
変化前の深刻度を条件に含めているのは、初報によって深刻度が上がったことを条件とするためです。


5. 同種のアラート発生は、初報から1時間は通知が必要ない

設定

トリガー

実行条件:過去「3600」秒間に、アクションが「0」「と等しい」回数発生した

解説

通知を送るアクションを実行する条件を満たした場合に、1時間(3600秒間)以内に初報を送るアクションが実行されていないことを確認する条件としています。


6. 異常が1分以内に回復したらアラート発生の通知が必要ない

設定

スコープ

警戒判定閾値:「1」

ルール

対象:異常アラートを捉えるルール
イベント:深刻度を「1」「増やす」


対象:回復アラートを捉えるルール
イベント:深刻度を「0」「にする」

トリガー

対象:障害通知を行うトリガー
実行条件1:スコープステータスが「正常」「と等しくない」
実行条件2:「60」秒経過後、スコープステータスが「正常」「と等しくない」
アクション:障害通知

対象:回復通知を行うトリガー
実行条件1:スコープステータスが「正常」「と等しい」
実行条件2:過去「60」秒間に「深刻度の変化量」が「1」「以上の」イベントが「0」「と等しい」回数発生した
アクション:回復通知

解説

異常アラートが発生した後、60秒後もスコープの深刻度が変化していない場合に障害通知を送信するものとしています。
異常アラートが続発する可能性を考慮して実行条件はスコープステータスで判断しています。

また、回復通知は異常アラートの発生から60秒以内に回復した場合は送信しないようにしたいため、
回復前の60秒間に異常が発生しなかった(=異常が発生したのは60秒より前である)ことを条件としています。


7. アラートメッセージの中に「error」の文字列があったらメール送信が必要だが、「error.html」であれば送信は必要ない

設定

ルール

処理フロー:もし「[任意のフィールド]」が「.*error([^\.]|$).*」とマッチ「した」場合

解説

アラートメッセージの文字列中に特定文字列などが含まれることを条件としたい場合は、
ルールの処理フローにおいて正規表現による条件を加えます。
AlertHub では正規表現の否定先読みが使用できないため、この例では同等の条件を満たすパターンを使用しています。
要件によっては処理フローに正規表現による条件を複数設定することで実現できる場合もあります。

Sonar で取得したノード情報を ServiceNow に連携する

Sonar で検出/取得したノード情報を、構成情報として ServiceNow にインポートする方法をご紹介します。

Sonar は管理ノード一覧を取得する API が用意されていますので、
ServiceNow 上に設定した JavaScript によって API を呼び出して取得した情報を CMDB に登録することで連携を実現します。
また、ノード情報の連携は ServiceNow の Scheduled Jobs を利用することで定期的に実行させることも可能です。

実際の設定の流れは以下の動画をご参照ください。

ServiceNow に設定するスクリプト、および詳細情報については以下をご参照ください。
github.com

Sonar のスキャンについて、SSH/WinRMによるホスト名の取得に対応しました

Kompira Sonar について、SSH/WinRMによるホスト名の取得に対応するアップデートを行いました。

今まではDNS、もしくはNetBIOSによる名前解決でのみホスト名の取得が行われておりましたが、今回のアップデートによってSSH/WinRM経由でもホスト名を取得できるようになりました。

f:id:fp4t1425:20200821182938p:plain
スキャン後のノードリストサンプル

f:id:fp4t1425:20200821180331p:plain
既存ノードの場合、赤枠のホスト名部分がSSH/WinRMで取得可能になります

取得ロジック

Linux/UnixであればSSHで、WindowsであればWinRMでホスト名を取得することが可能ですが、なるべく確実にホスト名が取得できるようそれぞれ下記のロジックで取得を行います。

SSHの場合(Linux/Unix)

  1. hostname -f コマンドでのFQDN取得
  2. hostname コマンドでの単体ホスト名取得
    -f オプションが実装されていない環境も多いため、FQDNでの取得に失敗した場合はこちらでの取得になります

WinRMの場合(Windows)

下記のPowerShellコマンドを順番に実行し、取得できたものを使用します。

  1. [System.Net.Dns]::GetHostEntry($env:COMPUTERNAME).Hostname
    ドメイン環境等であれば、こちらのコマンドでドメイン名を含むFQDNを取得します
  2. hostname
  3. $Env:COMPUTERNAME
  4. (Get-WmiObject Win32_ComputerSystem).Name

注意点

  • 既存ノードの 表示名 については互換性維持のためホスト名での上書き等は行いません
    新規ノードの場合自動でホスト名が表示名となります
  • ノードリスト画面でホスト名を確認したい場合は、リスト右上にある歯車マークから ホスト名 にチェックを入れることにより表示することが可能です
  • SSH/WinRMによる取得は認証情報が適切に設定されており、ログイン可能なノードに限ります