「[AlertHub] アクション実行に失敗しました」の通知メールについて
回答済み
お疲れ様です。
表記機能につきましてご教示ください。
noreply@kompira.jp からメールで渡される情報には、
①スコープID
②アクションID
がありましたが、
今、一つのWEBHOOKアクション（スコープも１つ）で、すべてのアラートを
架電させようとしているので、①②はすべて同一となってしまい、どのアクションが
失敗したのかがわかりません。
③メッセージ
④トリガー一覧と通知メールを一致させた時間のアクションからのイベントID
などや、それ以外から、異常となったもとの受信したデータがどれだったのかを
たどる方法を教えてください。
よろしくお願いいたします。
-
以前、PoC時の手法から、このWEBHOOKに変更しようかと思う時点で、
Pigeonに加えて、デグレードすることはないかと伺ったかと思います。
【投稿】
Kompira シリーズ間での架電情報の引き渡しについて
その時点でこの社内での課題を共有いただくことはできなかったのでしょうか？すでに変更に向かって動いているので、このご結果は遺憾です。
アクション実行失敗時の通知内容にはスコープ・アクションへのリンクのみ記載していることから、アクションの実行履歴やトリガー実行の契機となったイベント、そのイベントの発生契機となったメッセージを逆順で辿ることができないというのはPigeonアクション・Webhookアクションを問わない普遍的な問題であり、この点についてはアクションの種類を変えたことで差異になると考えてはおりませんでした。
しかしながら、確かに複数に分かれていたアクションが1つに統一されることで、失敗したアクションの情報だけでは連絡に使用したコールフローを割り出すことが出来ないというのはおっしゃる通りで、この点については見落としをしておりました。
これまで個々の質問に対する回答を単に示すだけでなく御社の構成を可能な限りシンプルに、わかりやすく構築できるよう心がけてはまいりましたが、力及ばず不快感を与えてしまったこと、大変申し訳ございませんでした。
機能改善について、具体的なスケジュールなどはありますか？
こちらについて、御社からの要望によるもの、他ユーザー様からの要望によるもの合わせて現在多くの改善要望が上がっている状態であり、現時点ではスケジュール未定となります。
重ね重ね、大変申し訳ございません。受信スロットに入った架電要求は、すべて入った順に一列で処理されていく仕様でしょうか？
基本的にはリクエスト順に処理されますが、特に短時間にリクエストが集中した時など、処理タイミングとの兼ね合いにより順番が前後するケースはございます。
ご理解のほど、よろしくお願いいたします。 -
お世話になっております。
対策を考えておりますが、アクション失敗時に、その入力データ（メッセージ画面）を明確にたどる方法がないというのは、やはり大きな難点です。
この後自動化を展開して1000件のデータを自動で受け取るにあたり、アクション異常となってPigeonへの渡りがない状態で、AlertHub内で入力データが特定できないというのは、基本運用が成り立っていない感覚です。
このアクション異常通知はPoCの仕様では発生させるのが難しく、WEBHOOK に切り替えることにしてほぼ初めて、WEBHOOKのパラメータエラー発生経緯で中身が見れた状況です。
表題「アクション実行に失敗しました」の通知メールからでは、リンク情報が・スコープ
・アクション
だけであり、スコープの画面情報や、アクション画面の情報からではメッセージにたどりつけないのは、すでにお答えいただきました。
他ルール・イベント・トリガーを拝見したところ、①ルールは受信スロットを指定している
②イベントはスコープ概要画面の末尾にIDを表示している
ようですね。
①から考えられることは、アクションの失敗時に、どのメッセージが入力データなのか明確にたどる方法がないのでしたら、受信スロットをコールフロー別にするしか手はないのでしょうか？
受信スロットの作成上限はない、と以前確認した気がいたしますが。
②イベントに関しては知識が浅いのですが、こちらはIDが分かったとしても、受信メッセージをたどる助けにはならないのでしょうか?
■AlertHub内で、失敗したアクションがどのメッセージなのか辿る術は本当にないのですか？ -
多くの質問をいただきましたので、分けて回答させていただきます。
10/17日曜日15時前後に以下のようなエラーが出ておりますが、どのようなものか教えていただけますでしょうか？
スコープの詳細画面では
- スコープ自身の情報
- スコープが持つ深刻度の情報
- スコープに関連するイベントの情報
- スコープに関連するアクション実行の履歴情報
を30秒に1回ずつ自動更新いたしますが、これはそれぞれAPIリクエストによって取得されます。このAPIリクエストにおいて「規定時間（10秒）以内にレスポンスを得られず、タイムアウトが発生した」場合に、添付画像のエラーが発生いたします。
タイムアウトが発生するケースとしてはサーバー側の障害や過負荷によるケースと、利用者様のネットワーク断等によりそもそもサーバーへリクエストが届かないケースが考えられます。
アクセスログを確認致しましたがタイムアウトエラーにあたるようなエラー発生およびレスポンスタイムが10秒を超えるようなログは確認できず、また他スペース様からのアクセスを含めて同時間帯の処理は正常に行われている様子であり、おそらくは回線の一時断によるものと考えられます。
-
①から考えられることは、アクションの失敗時に、どのメッセージが入力データなのか明確にたどる方法がないのでしたら、受信スロットをコールフロー別にするしか手はないのでしょうか？
受信スロットの作成上限はない、と以前確認した気がいたしますが。
②イベントに関しては知識が浅いのですが、こちらはIDが分かったとしても、受信メッセージをたどる助けにはならないのでしょうか?
■AlertHub内で、失敗したアクションがどのメッセージなのか辿る術は本当にないのですか？こちらに関して、APIを利用することで画面よりも追跡性が改善することがわかりましたので、詳しくご説明いたします。
まず、既にご存知の通りアクション実行履歴の詳細画面にはイベントIDの表示があり、逆に言えばアクション実行履歴を特定できればイベントを特定することが可能です。ただしイベントには個別の詳細画面がなく、イベント一覧の「eventId」列を用いてイベントを特定することこそ可能なものの、それ以上の有用な情報を得ることができません。
一方で、APIにはイベント情報の詳細取得を行うものがございます。
GET /api/apps/alerthub/scopes/{scopeId}/events/{eventId}このAPIではスコープ・イベントのIDを元に、イベントの詳細情報を取得することができます。
詳しい仕様に関してはAPIドキュメントを合わせてご参照いただければと思いますが、この取得結果には「messageId」というフィールドがあり、これはメッセージに対して一意に振られるID情報となっています。
（深刻度の手動リセット時など、メッセージを経由せずにイベントを発行した場合はこのフィールドは出力されません）メッセージの詳細画面には下記のURLが振られております。
「xxxx」はご利用のスペース名に、「{messageId}」は先の方法で調べたメッセージのIDに置き換えます。https://xxxx.cloud.kompira.jp/apps/alerthub/messages/{messageId}/overviewこのURLよりメッセージの詳細画面を開くことで受信したメールの内容および、そちらに記載されたコールフローのIDを特定することが可能です。
なお上記の流れにおける課題として、
- 通知メールからアクション実行履歴を直接特定することができず、時刻や個々の実行履歴の内容から人手で絞り込む必要がある
- イベントの詳細情報に関する画面がないため、アクション実行履歴に関連するイベントの情報取得や、その中に記載される関連メッセージの情報取得にAPIが必要になってしまっている
という点があり、これらに関しては具体的な解消スケジュールについて現在検討を行っております。
目処が立ちましたら、別途お知らせいたします。 -
WEBHOOKアクションの実行実績は、以下のように invalid としか表示されず何がはいっていたのかもわかりません。
WEBHOOKアクションではなく、Pigeonアクションだったら、もっとリカバリーに役立つ実行実績が表示されますか？
Pigeonアクションで、アクションが異常になった場合に表示される画面構成・表示情報の内容を共有いただけますでしょうか？エラー内容が非常にわかりにくくなってしまっているのはPigeonのAPIが抱えている問題でございまして、Pigeonアクションにおいて仮に同エラーが発生したとしてもWebhookアクション利用時と取得可能な情報の質に違いはございません。
なお、PigeonアクションにおいてはAPIの仕様をお客様が意識しなくて済むように、書式エラーが発生しないようパラメーターを制限しており、実際には添付いただいた「Invalid request payload」エラーが発生することはありません。
アクションの種類による履歴出力の差異について
2つのアクションにおける履歴出力の差異として、Webhookアクションにおけるアクション実行履歴ではリクエスト対象のシステムを限定しないため、HTTPの一般的な仕様として「レスポンスコード」「レスポンスボディ」「レスポンスヘッダ」の3点を確認できるようにしております。
一方でPigeonアクションではリクエスト対象をPigeonに限定するため、アクション実行履歴においては上記3点を元にPigeonのAPI仕様に従って結果をある程度整理して出力します。
「実行対象のコールフローが存在しない」ケースにて、両者の実行履歴出力例を添付いたしますので、ご参考になさってください。
Webhookアクションを用いた場合
下記のようにレスポンスボディの「status」フィールドが「rejected」になることで処理が失敗したことを、「errorDescriptor」フィールドにてエラーの詳細を確認可能です。
なお本ケースにおいてはPigeonのAPIのレスポンスコードが「201」を返しており、Webhookアクションではアクション実行の成否をレスポンスコードによってのみ判断することから全体のステータスとしては成功にあたる「実行済」と判定されております。
Pigeonアクションを用いた場合
確認可能な情報のレベルはWebhookと変わりませんが、「status」「errorDescriptor」の内容を「ステータス」「開始失敗理由」としてある程度整形して出力します。
また、Pigeonアクションではレスポンスコードだけでなく「status」の内容も加味してアクション実行の成否を判断するため、全体のステータスは「失敗」と判定されております。
-
お世話になっております。
色々と情報提供をありがとうございます。
弊社でも、アクション異常の発生確率を抑える（架電要求待ち超過）など、運用面から検討をしております。
アクション異常通知から少し離れた観点で伺いますが、
WEBHOOKを利用すると設定工数が大幅に縮小できますし、構成としてはシンプルです。
ですが反対にすべてのアラートが同じ名前の設定群を使用するので、アラート数が増えるほど、切り分けは難しくなると思います。
なのでインプットデータ表示であるメッセージとのつながりを重視しているのですが、その上でWEBHOOKは、どのくらい利用されているのでしょうか？
使われているユーザ様は、時間で入力データを見分けられるケースの運用に限られている状況でしょうか？
また以前、以下のお尋ねをいたしました。
＞＞受信スロットをコールフロー別にするしか手はないのでしょうか？
受信スロットの作成上限はない、と以前確認した気がいたしますが。
APIなどを使うのではなく、構築設計上で手立てがあるとすれば受信スロットの活用くらいでしょうか？
データ受信時にすべてのルールを精査しているようなので、
処理フローが同じでも、受信スロットが異なれば、処理が分けられ見分けがつくと考えておりますが、
受信スロット作成上限
受信スロットが多くなることで処理効率が落ちるなどはございませんでしょうか？
また、入力メールに依存するものと思いますが、WENHOOKアクションは、Pigeonアクションよりも失敗してしまう可能性は高いと思います。
＞＞書式エラーが発生しないようパラメーターを制限しており、実際には添付いただいた「Invalid request payload」エラーが発生することはありません。
と書かれているのは、通常テストでパラメータ指定は済ませる
入力データであるメールフォームは通常崩れることはない
というお考えからでしょうか？
テスト・構築段階でおいても、どのパラメータが違っているのかが表示されるかされないかは、リカバリ工数を左右するところかと思います。
また、Pigenが表示しているパラメータすべてをWEBHOOKでも指定することは可能でしょうか？
以前出来ない部分もあると伺った気がいたします。
できるだけ、Pigeonのパラメータ表記に近づけたいと考えておりますので、どのような仕様になっているか、ご教示ください。
ちなみに今は以下のものは指定しております。
"scopeId":"{{scope.scopeId}}",
"scopedisplayName":"{{scope.displayName}}",
"callflowId":"{{CFid}}",
"scopeSeverities":"{{scopeSeverities.severity}}"長くなり、申し訳ありません。
ご回答のほど、よろしくお願いいたします。 -
WEBHOOKを利用すると設定工数が大幅に縮小できますし、構成としてはシンプルです。
ですが反対にすべてのアラートが同じ名前の設定群を使用するので、アラート数が増えるほど、切り分けは難しくなると思います。
なのでインプットデータ表示であるメッセージとのつながりを重視しているのですが、その上でWEBHOOKは、どのくらい利用されているのでしょうか？
使われているユーザ様は、時間で入力データを見分けられるケースの運用に限られている状況でしょうか？そもそもWebhookアクションは対象をPigeonに限るものではなく、既存の利用ケースとしてはチケット管理システムへの起票やKompira Enterprise含む別システムの処理リクエスト送信など、Pigeon以外のシステムとの連携が基本となります。
またPigeonとの連携を行うケースにおいては、コールフローを今回ほど細かく切り分けることを望まれたケースはなく、多くて数種類のコールフローごとにPigeonアクションを用意し、ルール・トリガーにて使用アクションを振り分けるのが現時点での一般的な構成となっております。
データの追跡性について、より直接的に辿っていけるよう要望をいただいており、先にお知らせした通り対応スケジュールの策定中でございます。ただ現時点では多くて1分に1件程度のメッセージ受信を取り扱っているお客様がほとんどで、この程度の頻度であればアクション失敗通知や実行履歴に記載されたタイムスタンプを元にメッセージ一覧の検索機能にて関連するメッセージを絞り込むことが現実的に行えるため、一旦はそちらでまかなっていただいている形となります。
APIなどを使うのではなく、構築設計上で手立てがあるとすれば受信スロットの活用くらいでしょうか？
データ受信時にすべてのルールを精査しているようなので、
処理フローが同じでも、受信スロットが異なれば、処理が分けられ見分けがつくと考えておりますが、
受信スロット作成上限
受信スロットが多くなることで処理効率が落ちるなどはございませんでしょうか？
そもそもルールには受信スロットを1つしか設定できないため、受信スロットだけを複数に切り分けるということはできません。また受信スロットや、仮にルールを複数に切り分けたとしても、アクション失敗通知やアクション実行履歴からどの受信スロット・ルールが使われたかを直接知ることはできず、見分けをつけるのは難しいかと思います。
なおパフォーマンス面に関して、受信スロットの数を増やしたとしても処理効率が低下することはございません。逆に処理効率へ影響しやすい要素として、1つの受信スロットに対して極端に多くのルールを設定しますと1回のデータ受信に対する処理が増大するため、処理効率が低下しやすくなります。
また、入力メールに依存するものと思いますが、WENHOOKアクションは、Pigeonアクションよりも失敗してしまう可能性は高いと思います。
＞＞書式エラーが発生しないようパラメーターを制限しており、実際には添付いただいた「Invalid request payload」エラーが発生することはありません。
と書かれているのは、通常テストでパラメータ指定は済ませる
入力データであるメールフォームは通常崩れることはない
というお考えからでしょうか？
テスト・構築段階でおいても、どのパラメータが違っているのかが表示されるかされないかは、リカバリ工数を左右するところかと思います。「Invalid request payload」エラーは、Pigeonの連絡実行APIに対してAPIの仕様から外れたリクエストを送信したときに発生します。Pigeonアクションでは設定されたコールフロー・ガイダンスのIDおよび、受信したメッセージ、発行されたイベント等から **APIの仕様に合うように** リクエストを自動的に構築・送信するため、このエラーが発生することはございません。
一方でWebhookアクションを用いる場合はリクエスト内容をより自由に制御できる分、設定や、場合によっては入力データの誤りによりPigeonのAPI仕様から外れたリクエストが送信され、同エラーを発生させてしまう可能性がございます。
また、Pigenが表示しているパラメータすべてをWEBHOOKでも指定することは可能でしょうか？
以前出来ない部分もあると伺った気がいたします。
できるだけ、Pigeonのパラメータ表記に近づけたいと考えておりますので、どのような仕様になっているか、ご教示ください。全てのパラメータを再現することは不可能ではないものの、 各要素が持つ子フィールドを全て個別指定する必要がありこれが現時点で50以上あること、メッセージや深刻度の情報は受信内容・設定等に依存してフィールド名が不定でこれを全て埋め込むための設定難易度が高いことなど、非常に高いハードルを有します。
またPigeonアクションにて渡す情報は今後の機能追加によって増やしていく可能性があり、こういった仕様追加に対してお客様側で追従していくことを考えますと、この方針は推奨し兼ねます。
そのため、載せたい情報があればピックアップいただき、その取得可否および取得可能な場合のフィールド名を提示させていただくのが現実的かと思います。
-
早速のお返事ありがとうございました。
一点、齟齬があるようなので確認させてください。
＞＞処理フローが同じでも、受信スロットが異なれば、処理が分けられ見分けがつくと考えております
上記の弊社の書き方が良くなかったかと存じます。
アクション異常通知からの情報をたどる中で、
ルール画面やメッセージ画面で受信スロットも表示されていることから、
各種アラートをチェックするルールは単一であっても、入口の受信スロットが分かれていれば、
切り分けが可能になるかと考えました。もちろんスコープは別になります。
運用対策としてですが、そういう対処法もあるかと、既存プログラムの修正も視野にいれております。
＞＞また受信スロットや、仮にルールを複数に切り分けたとしても、アクション失敗通知やアクション実行履歴からどの受信スロット・ルールが使われたかを直接知ることはできず、見分けをつけるのは難しいかと思います。
上記の件につきましては、アクションタイムスタンプから、スコープとルールが辿れると思っております。
なので、受信スロットを分けることは入力データの切り分けに一役買えると考えており、それもあって受信スロット作成数の上限をうかがっております。 -
アクション異常通知からの情報をたどる中で、
ルール画面やメッセージ画面で受信スロットも表示されていることから、
各種アラートをチェックするルールは単一であっても、入口の受信スロットが分かれていれば、
切り分けが可能になるかと考えました。もちろんスコープは別になります。「ルールは単一」とありますが、先の回答の通り1つのルールに対して設定可能な受信スロットは1つだけとなります。そのため複数の受信スロットに対する入力を1つのルールで処理することはできません。
仰る意図としてはルールの定義内容が単一なだけで、ルールの実体は受信スロットに対して1対1対応する形で分けて作るということでしょうか？
なので、受信スロットを分けることは入力データの切り分けに一役買えると考えており、それもあって受信スロット作成数の上限をうかがっております。
申し訳ございません、こちらについては再確認の意図を見落としておりました。受信スロットの作成数に上限は特にございません。
-
お世話になっております。昨日のうちに返答できず、申し訳ありません。
＞＞仰る意図としてはルールの定義内容が単一なだけで、ルールの実体は受信スロットに対して1対1対応する形で分けて作るということでしょうか？
はい。そういう意図です。
具体的にはルールの定義内容は、以前からご相談してきたとおり、正規表現とのマッチング
^callflow:\s*(\S+)$ や
^callflow:コールフロー名\s*(\S+)$
しか考えておりません。^callflow:コールフロー名\s*(\S+)$ は、運用上何らかの不都合が生じた時用と考えております。
なので、スコープからアクションまで単一のもの
受信スロットXXX－スコープAールールA－トリガーA－アクションWEBHOOK_W が主ですが、
切り分けがより必要なアラート群に関しては、
受信スロットYYYースコープBールールBートリガーB－アクションWEBHOOK_W として別構成いたします。
トリガーは外出し定義？ではないようなので、中身は同じものを手設定いたします。
アクション以外は新規作成となり、定義内容は受信スロット以外単一（AもBも同じもの）なのにという声もあがると思いますが、対象アラート数を減らす意味の暫定対応です。
この時に受信スロットが分かれているので、メッセージ画面でアクション異常通知されたアラートが
見つけやすくなると考えています。
アクション異常通知がメッセージまで紐づけできれば不要となります。
また、運用を開始してみて、アラートが時間で管理できそうならは、暫定設定はしないつもりです。
言葉ばかりで説明してしまったので、齟齬が発生していたのではないかと思うのですが、これで如何でしょうか？
どの受信スロットから入っても、ルールは全件舐めているようですが、そこで不都合が生じるようなら今のうちに教えていただけますか？
よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
21件のコメント