Kompira cloud更新情報

2020年

Kopmira cloud の更新情報はこちらに移動しました。
今後は上記サイトをご確認ください。

12月

2020-12-21

  • AlertHub
    • イベント履歴、アクション履歴の一覧においてタイムスタンプが秒単位まで表示されるように修正しました
    • アクション履歴のタイムスタンプをクリックするとレスポンスが表示されるようになりました
    • ルール/スコープ/アクション一覧で、2ページ目以降でfilterをかけるとデータなしと表示されてしまうことがあったので、フィルタした後は1ページ目に戻るように修正しました
  • Pigeon
    • 連絡先詳細画面を追加しました

2020-12-17

  • Ksocket v2.2.1 をリリースしました
    • 特定のスキャン命令が正常に処理されていなかった不具合を修正
      ※ 2020/12時点ではJuniper製品のLLDP情報収集処理のみが影響

2020-12-15

  • Sonar の不具合修正を行いました
    • ノードの詳細情報( extraFields )の一部項目が、スナップショットから正常に反映されないことがある問題を修正しました

2020-12-10

  • Kc 全般
    • データがない時に表示されるアイコンを変更しました
  • AlertHub
    • 深刻度の手動リセット機能を追加しました
    • スコープ/ルール/アクション一覧での表示名フィルタ機能を追加しました

2020-12-04

  • AlertHubの静観スケジュールにて、毎日繰り返し静観スケジュールが設定できるようになりました
  • 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 関連のドキュメント不備を修正
    • ユーザー管理関連のドキュメント不備を修正
続きを読む

AlertHub でアクション実行に異常があった場合、通知を受け取れるようになりました

AlertHub ではアクション実行時に異常があった場合には、まずリトライが行われます。 30秒間隔で3回リトライされますが、最終の実行においても異常があった場合に通知先を登録したアドレスにメールで通知を行う機能が実装されました。

AlertHub のメニューから「設定」をクリックすることで通知先を設定する画面に遷移することができます。 ここで指定されたメールアドレスには、全てのアクションを対象として異常が発生した場合の通知が行われます。 f:id:ueno-fixpoint:20210330213021p:plain

アクションの失敗時には以下の様なメールが送信されます。

2021-03-29 12:43:56 に実行開始したアクション実行に失敗しました
下記のリンクから、スコープの「アクション」一覧にて、該当アクション実行の詳細を確認してください。
https://example.com/apps/alerthub/scopes/ca4af115-0990-4640-b02f-392fea5c7a71/overview

■ 関連情報
・対象スペース
https://example.com/

・アクション実行開始日時
2021-03-29 12:43:56

・アクション実行失敗日時
2021-03-29 12:54:56

・失敗理由
something wrong

・アクション発生元スコープ
https://example.com/apps/alerthub/scopes/ca4af115-0990-4640-b02f-392fea5c7a71/overview

・失敗したアクション
https://example.com/apps/alerthub/actions/dd07a858-2d55-489e-83ea-c412085704c8

※このメールは自動で送信されています。返信はできませんのでご注意ください。
※このメールにお心当たりのない方は、恐れ入りますが破棄して頂けますようお願いいたします。
------------------------------------------------------
Kompira cloudサポート
お問い合わせ https://kompira.zendesk.com/hc/ja/community/topics
------------------------------------------------------

AlertHub で受信したメッセージの情報を確認できるようになりました

監視ツールなどから AlertHub へ送られたアラートメッセージについて、 AlertHub の画面上で確認ができるようになりました。 直近30日間に受信したメッセージが確認できるようになっています。

メッセージ一覧

メッセージ一覧では、メッセージを受信したスロットやルール実行の有無、イベント発生の有無が確認できるようになっており、 受信日時に加えてそれぞれの状態を条件とした絞り込みが行えます。 f:id:ueno-fixpoint:20210330213700p:plain:w800

メッセージ詳細

メッセージ詳細では、メッセージ内容やヘッダ情報などが確認できます。 また、そのメッセージが処理されたルールの実行履歴と、 ルール処理の結果発生したイベントが確認できるようになっています。 f:id:ueno-fixpoint:20210330213821p:plain:w600

AlertHub で1つのルールで複数のスコープを条件指定できるようになりました

AlertHub では受信したアラートメッセージをルールの設定に基づいて条件判断し、 スコープの深刻度を増減させることで後続のアクションの発生に繋げています。

2/28 に適用したアップデートでは、ルールで設定する深刻度を増減させる対象のスコープの指定について、 これまでは直接指定のみだったものを、条件指定できるような機能追加を行っています。

アップデート内容

  • スコープにおいて、任意の名称と値の組み合わせを「属性」として追加できるようにしました
  • ルールにおいて、「属性」の値を条件としてスコープを指定できるようにしました

スコープの属性設定イメージ

スコープの属性は、対象となる機器や監視観点の固有の情報や、種別や分類などの情報を持たせることができます。 以下は、機器の IP アドレスと機器が配置されている拠点を設定するイメージです。

属性の設定はスコープの「設定」から行います。

f:id:ueno-fixpoint:20210302221102p:plain:w800 f:id:ueno-fixpoint:20210302221213p:plain:w800

ルールのスコープ指定イメージ

これまではルールでは以下の様に、メッセージ内容から機器を判別して対象のスコープを直接指定することしかできませんでした。 この場合、ルールは機器の数と同じ数以上作成しなくてはいけません。 f:id:ueno-fixpoint:20210302222327p:plain:w600

スコープの条件指定では、属性の値とメッセージ内容の一部が一致するスコープを指定することができます。 このような指定ができることで、同種の監視を行っている機器についてはルールを共通化することが可能になります。 f:id:ueno-fixpoint:20210302223117p:plain:w600

また、スコープの条件指定では、属性の値を固定値で指定することも可能です。 下記は、拠点Aのコアスイッチがダウンしたアラートを受信した場合に、拠点Aに属する機器を全て警戒状態にするイメージです。 f:id:ueno-fixpoint:20210302224359p:plain:w600

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:Rindrics:20210205101916p: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:Rindrics:20210205102044p: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:Rindrics:20210205102120p: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:Rindrics:20210215221105p:plain

同様に回復アラートを処理するためのルールを以下の様に設定します。 f:id:Rindrics:20210215221114p: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」へ推移している