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による取得は認証情報が適切に設定されており、ログイン可能なノードに限ります

Ksocket を Version 2 をリリースしました

最新の Ksocket は ダウンロード ページよりダウンロードできます。

主に近日リリース予定の Ksocket リモートアップデート機能対応と ARMv7 のサポートを含んだリリースです。

このリリースに伴い以前の Ksocket は非推奨となります。 既に Ksocket を利用している方は、Ksocket ドキュメントの「マイグレーションガイド」を参照してアップグレードをお願いします。

注意: ksocket-20190726 (ksocket-core 1.8.0 / ksocket-networks 1.8.0) を利用している場合、付属しているアンインストーラーが故障しています。 お手数ですが Ksocket の手動アンインストール を参照し、手動アンインストールを行ってください。

ARMv7 Little Endian のサポート

命令セットアーキテクチャとして ARMv7 Little Endian (32bit) のサポートを追加しました。

自己診断コマンドの追加

自己診断コマンドを追加しました。 これにより、設定ファイルの検証から Kompira cloud への疎通確認までを自動検証することができます。 詳しくは ksocket マニュアルの「自己診断コマンドの利用」を参照してください。

デーモン/サービス管理コマンドの追加

Ksocket をバックグラウンド起動するために利用している systemd, upstart および Windows service の管理コマンドを追加しました。 これにより統一されたインターフェースで ksocket の起動/停止等を行うことができます。 詳しくは ksocket マニュアルの「デーモン/サービス管理コマンドの利用」を参照してください。

セマンティックバージョニングの採用

Ksocket v1 ではリリースバージョンおよび内部モジュールバージョンを記載していましたが、v2 では内部モジュールの統合が行われました。 これに伴い、リリースバージョンの表記を 20200220.0 のような日付ベースの表記から v2.0.0 のような セマンティックバージョニング 表記に切り替えます。 これにより、各リリース間での後方互換性の有無がバージョン表記から分かりやすくなります。

バグ修正

  • 一部のアドレス存在確認プロトコルにて OS のルーティングテーブルを考慮しない問題を修正
  • ネットワーク遅延等によりオペレーションが重複発行された場合にスキャンが不安定になる問題を修正
  • 大量のアドレスをスキャンした際にスキャンが不安定になる問題を修正

最新の Ksocket は ダウンロード ページよりダウンロードできます。


Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

Ksocket の Azure 上で動作を改善しました。

Ksocket に以下の内容を含むアップデートを行いました。

  • ksocket-20200220
    • ksocket-core: 1.9.2
    • ksocket-networks: 1.9.1

アップデート内容

  • 全体的なパフォーマンス向上
  • 新規インストール時のデフォルトの loglevel を INFO に変更
  • Azure 上にて ksocket が動作しないバグを修正
  • スキャン対象に大量のアドレスを指定した際に発生するメモリリークバグを修正
  • インストーラーが一部環境で動作しなかった問題の修正
  • アンインストーラーが付属していなかった問題の修正

最新の Ksocket はこちらよりダウンロードすることができます。



Kompira cloud 製品紹介ページはこちら
Kompira cloud 資料ダウンロードはこちら

新しい画面デザインを正式にリリースしました

Kompira cloudについて、下記の機能を含むアップデートを行いました

新しい画面デザインを正式にリリースしました

これまでβ機能としていた、新しい画面デザインを正式リリースいたしました。

f:id:honda_fixpoint:20191204184448p:plain:w720
新しい画面デザイン

見た目・使い勝手が向上しているのはもちろん、スマートフォン等の画面サイズの小さい端末での表示に関する考慮や、英語表示への切り替え機能が追加されております。

f:id:honda_fixpoint:20191204184710p:plain:w200
スマートフォンサイズでの表示

f:id:honda_fixpoint:20191204184738p:plain:w720
英語での表示

なお、旧デザインについては今後廃止を予定しておりますが、当面の間は上部メニューより切り替えて使用することが可能です。

f:id:honda_fixpoint:20191204185640p:plain:w200
旧デザインに戻す

[Pigeon] 連絡実行・中止を行う新しいAPI機能をリリースしました

連絡実行・中止を行うためのAPIとして、これまでのAPIよりも高機能な新しいAPIを追加しました。
旧APIに関しては引き続きご利用いただけますが、今後は新APIを推奨する形となります。

詳しくは下記の記事をご覧ください。
Pigeonの新しい連絡APIの機能と使いかたについて

Pigeonの新しい連絡APIの機能と使いかたについて

Pigeonの連絡に使用するAPIについて、新しいAPIをリリースしました。

  • 連絡実行API
    • 旧:POST /api/tasks
    • 新:POST /api/apps/chain/invoke
  • 連絡中断API
    • 旧:POST /api/tasks/{taskId}/abort
    • 新:POST /api/apps/chain/abort

新しいAPIはこれまでより高機能かつ使いやすいものとなっており、本記事ではこのAPIの使用方法についてご説明いたします。 (コマンド例にて使用するデータは Pigeon チュートリアルのものに準じます)

連絡の実行:POST /api/apps/pigeon/chain/invoke

定義済みのコールフロー・ガイダンスを用いて連絡を実行する

事前定義したコールフロー・ガイダンスを用いて連絡を行うには、それぞれのID値を用いて例えば下記のデータをリクエストボディに指定してPOSTリクエストを行います。

{
  "params": {
    "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6",
    "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d",
    "parameters": {
      "server": "テスト用サーバー",
      "incident": "軽度の障害"
    }
  }
}

curlコマンドでのリクエスト例を下記に示します。

$ curl -X POST -H "X-Authorization: Token aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789" \
https://yourspace.cloud.kompira.jp/api/apps/pigeon/chain/invoke \
-d '{"params":{"callflowId":"049de6fc-c1a7-4963-af43-616cce2492c6","guidanceId":"570e6f71-5459-43fe-a745-aa7d115ce20d","parameters":{"server":"テスト用サーバー","incident":"軽度の障害"}}}'

リクエストを行うと、例えば下記のように「リクエストに使用したパラメータ」「連絡結果ID(成功時のみ)」「連絡の成否(requested であれば成功)」を含むレスポンスを返します。

{
  "params": {
    "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6",
    "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d",
    "parameters": {
      "server": "テスト用サーバー",
      "incident": "軽度の障害"
    }
  },
  "resultId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "status": "requested"
}

レスポンス中に含まれる連絡結果IDを用いて、後述する「連絡の中止」や、
既存のAPI GET /api/apps/pigeon/results/{resultId} を通した連絡結果情報の取得を行うことができます。

コールフロー・ガイダンスの内容をその場で指定して連絡を実行する(新機能)

リクエスト時に callflowId guidanceId の代わりに、使用するデータの内容を callflow guidance として指定して連絡することができます。

{
  "params": {
    "callflow": {
      "loopLimit": 3,
      "contacts": [
        {
          "displayName": "田中さん",
          "phones": [ { "phoneNumber": "0999001122" } ]
        },
        {
          "displayName": "山田さん",
          "phones": [ { "phoneNumber": "0999334455" } ]
        },
        {
          "displayName": "斎藤さん",
          "phones": [ { "phoneNumber": "0999778899" } ]
        }
      ]
    },
    "guidance": {
      "messageTemplate": "テスト用サーバーにて軽微な障害が発生しました。 対応される場合は1を、次の担当者に連絡する場合は2を、以降この電話への連絡をスキップする場合は3を押してください。",
      "reactions": {
        "1": {
          "behavior": "terminate",
          "messageTemplate": "1が押されました。対応をよろしくお願いいたします。"
        },
        "2": {
          "behavior": "continue",
          "messageTemplate": "2が押されました。次の担当者に連絡します。"
        },
        "3": {
          "behavior": "leave",
          "messageTemplate": "3が押されました。以降この電話への連絡をスキップします。"
        }
      }
    }
  }
}

上記の例ではコールフロー・ガイダンスの内容を双方とも直接指定していますが、片方はID指定にて事前登録済みのデータを使用し、もう片方は内容をその場で指定するといった形でのリクエストも可能です。

本機能により、例えば電話番号を含む名簿データを自前で管理しているシステムとの連携時に、呼び出し側でコールフローのデータ内容を生成する形をとることでPigeonへ電話番号を二重登録することを防ぐ、といった使い方が可能となります。

連絡の中止:POST /api/apps/pigeon/chain/abort

連絡の中止を行うには、連絡結果IDを用いて例えば下記のリクエストボディにてPOSTリクエストを行います。

{
  "resultId": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}

curlコマンドでのリクエスト例を下記に示します。

$ curl -X POST -H "X-Authorization: Token aAbBcCdDeEfFgGhHiIjJkKlLmMnNoO0123456789" \
https://yourspace.cloud.kompira.jp/api/apps/pigeon/chain/abort \
-d '{"resultId":"3fa85f64-5717-4562-b3fc-2c963f66afa6"}'

旧APIの今後の取り扱いについて

今後は新しいAPIを使用することを推奨し、旧APIは 非推奨 となります。
ただし、旧APIの既存機能については今後も引き続きご利用いただけますので、既にご活用いただいているものをただちに置き換えていただく必要はございません。

なお今後連絡APIへの機能追加を行う場合、その対象は原則として新APIのみになりますのでご承知おきください。