「[AlertHub] アクション実行に失敗しました」の通知メールについて

回答済み

コメント

21件のコメント

  • Kompiraサポートチーム

    ご質問ありがとうございます。
    回答させていただきます。

    現状、アクション失敗通知からのデータ追跡に関しては、通知時刻を元にアクションの実行実績やメッセージ一覧を検索していただき、関連する情報を探していただく形となります。

    メッセージ受信の頻度がよほど高頻度でなければ情報を絞り込むことはできるかとは思いますが、関連する情報をストレートに辿ることができない点については社内でも課題として上がっており、機能改善を検討中でございます。

    ご不便をおかけいたします。よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    以前、PoC時の手法から、このWEBHOOKに変更しようかと思う時点で、
    Pigeonに加えて、デグレードすることはないかと伺ったかと思います。

    【投稿】
    Kompira シリーズ間での架電情報の引き渡しについて

    その時点でこの社内での課題を共有いただくことはできなかったのでしょうか?

    すでに変更に向かって動いているので、このご結果は遺憾です。
    機能改善について、具体的なスケジュールなどはありますか?

    0
    コメントアクション Permalink
  • 原井麻有

    追加質問で申し訳ありません。

    弊社の購入予定は今のところ、

    AlertHub: スタンダード
    Pigeon  :スタンダード  
    です。
    アラート頻度が増加し、待ち行列30を超える場合の懸念をしております。
    1回線契約・同時架電数1ですので、
    受信スロットに入った架電要求は、すべて入った順に一列で処理されていく仕様でしょうか?
    どのような仕様となるか、ご教示いただけますでしょうか?

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    以前、PoC時の手法から、このWEBHOOKに変更しようかと思う時点で、
    Pigeonに加えて、デグレードすることはないかと伺ったかと思います。

    【投稿】
    Kompira シリーズ間での架電情報の引き渡しについて

    その時点でこの社内での課題を共有いただくことはできなかったのでしょうか?

    すでに変更に向かって動いているので、このご結果は遺憾です。

    アクション実行失敗時の通知内容にはスコープ・アクションへのリンクのみ記載していることから、アクションの実行履歴やトリガー実行の契機となったイベント、そのイベントの発生契機となったメッセージを逆順で辿ることができないというのはPigeonアクション・Webhookアクションを問わない普遍的な問題であり、この点についてはアクションの種類を変えたことで差異になると考えてはおりませんでした。

    しかしながら、確かに複数に分かれていたアクションが1つに統一されることで、失敗したアクションの情報だけでは連絡に使用したコールフローを割り出すことが出来ないというのはおっしゃる通りで、この点については見落としをしておりました。

    これまで個々の質問に対する回答を単に示すだけでなく御社の構成を可能な限りシンプルに、わかりやすく構築できるよう心がけてはまいりましたが、力及ばず不快感を与えてしまったこと、大変申し訳ございませんでした。

    機能改善について、具体的なスケジュールなどはありますか?

    こちらについて、御社からの要望によるもの、他ユーザー様からの要望によるもの合わせて現在多くの改善要望が上がっている状態であり、現時点ではスケジュール未定となります。
    重ね重ね、大変申し訳ございません。

    受信スロットに入った架電要求は、すべて入った順に一列で処理されていく仕様でしょうか?

    基本的にはリクエスト順に処理されますが、特に短時間にリクエストが集中した時など、処理タイミングとの兼ね合いにより順番が前後するケースはございます。
    ご理解のほど、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話様です。
    10/17日曜日15時前後に以下のようなエラーが出ておりますが、どのようなものか教えていただけますでしょうか?
    現時点では障害情報はありませんでした。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    対策を考えておりますが、アクション失敗時に、その入力データ(メッセージ画面)を明確にたどる方法がないというのは、やはり大きな難点です。
    この後自動化を展開して1000件のデータを自動で受け取るにあたり、アクション異常となってPigeonへの渡りがない状態で、AlertHub内で入力データが特定できないというのは、基本運用が成り立っていない感覚です。

    このアクション異常通知はPoCの仕様では発生させるのが難しく、WEBHOOK に切り替えることにしてほぼ初めて、WEBHOOKのパラメータエラー発生経緯で中身が見れた状況です。


    表題「アクション実行に失敗しました」の通知メールからでは、リンク情報が

    ・スコープ

    ・アクション

    だけであり、スコープの画面情報や、アクション画面の情報からではメッセージにたどりつけないのは、すでにお答えいただきました。
    他ルール・イベント・トリガーを拝見したところ、

    ①ルールは受信スロットを指定している

    ②イベントはスコープ概要画面の末尾にIDを表示している

    ようですね。
    ①から考えられることは、アクションの失敗時に、どのメッセージが入力データなのか明確にたどる方法がないのでしたら、受信スロットをコールフロー別にするしか手はないのでしょうか?
    受信スロットの作成上限はない、と以前確認した気がいたしますが。

    ②イベントに関しては知識が浅いのですが、こちらはIDが分かったとしても、受信メッセージをたどる助けにはならないのでしょうか?

    ■AlertHub内で、失敗したアクションがどのメッセージなのか辿る術は本当にないのですか?

    0
    コメントアクション Permalink
  • 原井麻有

    追加で失礼いたします。
    2021/10/17 【質問_3件目】

    >>アクション失敗通知からのデータ追跡に関しては、通知時刻を元にアクションの実行実績やメッセージ一覧を検索していただき、
    と、ありますが、WEBHOOKアクションの実行実績は、以下のように invalid としか表示されず何がはいっていたのかもわかりません。
    WEBHOOKアクションではなく、Pigeonアクションだったら、もっとリカバリーに役立つ実行実績が表示されますか?
    Pigeonアクションで、アクションが異常になった場合に表示される画面構成・表示情報の内容を共有いただけますでしょうか?

    0
    コメントアクション Permalink
  • 原井麻有

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    多くの質問をいただきましたので、分けて回答させていただきます。

    10/17日曜日15時前後に以下のようなエラーが出ておりますが、どのようなものか教えていただけますでしょうか?

    スコープの詳細画面では

    • スコープ自身の情報
    • スコープが持つ深刻度の情報
    • スコープに関連するイベントの情報
    • スコープに関連するアクション実行の履歴情報

    を30秒に1回ずつ自動更新いたしますが、これはそれぞれAPIリクエストによって取得されます。このAPIリクエストにおいて「規定時間(10秒)以内にレスポンスを得られず、タイムアウトが発生した」場合に、添付画像のエラーが発生いたします。

    タイムアウトが発生するケースとしてはサーバー側の障害や過負荷によるケースと、利用者様のネットワーク断等によりそもそもサーバーへリクエストが届かないケースが考えられます。

    アクセスログを確認致しましたがタイムアウトエラーにあたるようなエラー発生およびレスポンスタイムが10秒を超えるようなログは確認できず、また他スペース様からのアクセスを含めて同時間帯の処理は正常に行われている様子であり、おそらくは回線の一時断によるものと考えられます。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ①から考えられることは、アクションの失敗時に、どのメッセージが入力データなのか明確にたどる方法がないのでしたら、受信スロットをコールフロー別にするしか手はないのでしょうか?
    受信スロットの作成上限はない、と以前確認した気がいたしますが。

    ②イベントに関しては知識が浅いのですが、こちらは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が必要になってしまっている

    という点があり、これらに関しては具体的な解消スケジュールについて現在検討を行っております。
    目処が立ちましたら、別途お知らせいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    承知しました。
    情報をありがとうございました。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    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」の内容も加味してアクション実行の成否を判断するため、全体のステータスは「失敗」と判定されております。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    色々と情報提供をありがとうございます。
    弊社でも、アクション異常の発生確率を抑える(架電要求待ち超過)など、運用面から検討をしております。

    アクション異常通知から少し離れた観点で伺いますが、
    WEBHOOKを利用すると設定工数が大幅に縮小できますし、構成としてはシンプルです。
    ですが反対にすべてのアラートが同じ名前の設定群を使用するので、アラート数が増えるほど、切り分けは難しくなると思います。
    なのでインプットデータ表示であるメッセージとのつながりを重視しているのですが、その上でWEBHOOKは、どのくらい利用されているのでしょうか?
    使われているユーザ様は、時間で入力データを見分けられるケースの運用に限られている状況でしょうか?

    また以前、以下のお尋ねをいたしました。
    >>受信スロットをコールフロー別にするしか手はないのでしょうか?
    受信スロットの作成上限はない、と以前確認した気がいたしますが。

    APIなどを使うのではなく、構築設計上で手立てがあるとすれば受信スロットの活用くらいでしょうか?
    データ受信時にすべてのルールを精査しているようなので、
    処理フローが同じでも、受信スロットが異なれば、処理が分けられ見分けがつくと考えておりますが、
    受信スロット作成上限
    受信スロットが多くなることで処理効率が落ちる

    などはございませんでしょうか?

    また、入力メールに依存するものと思いますが、WENHOOKアクションは、Pigeonアクションよりも失敗してしまう可能性は高いと思います。
    >>書式エラーが発生しないようパラメーターを制限しており、実際には添付いただいた「Invalid request payload」エラーが発生することはありません。
    と書かれているのは、

    通常テストでパラメータ指定は済ませる

    入力データであるメールフォームは通常崩れることはない
    というお考えからでしょうか?

    テスト・構築段階でおいても、どのパラメータが違っているのかが表示されるかされないかは、リカバリ工数を左右するところかと思います。
    また、Pigenが表示しているパラメータすべてをWEBHOOKでも指定することは可能でしょうか?
    以前出来ない部分もあると伺った気がいたします。
    できるだけ、Pigeonのパラメータ表記に近づけたいと考えておりますので、どのような仕様になっているか、ご教示ください。
    ちなみに今は以下のものは指定しております。
    "scopeId":"{{scope.scopeId}}",
    "scopedisplayName":"{{scope.displayName}}",
    "callflowId":"{{CFid}}",
    "scopeSeverities":"{{scopeSeverities.severity}}"

    長くなり、申し訳ありません。
    ご回答のほど、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    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アクションにて渡す情報は今後の機能追加によって増やしていく可能性があり、こういった仕様追加に対してお客様側で追従していくことを考えますと、この方針は推奨し兼ねます。

    そのため、載せたい情報があればピックアップいただき、その取得可否および取得可能な場合のフィールド名を提示させていただくのが現実的かと思います。

    0
    コメントアクション Permalink
  • 原井麻有

    早速のお返事ありがとうございました。

    一点、齟齬があるようなので確認させてください。
    >>処理フローが同じでも、受信スロットが異なれば、処理が分けられ見分けがつくと考えております

    上記の弊社の書き方が良くなかったかと存じます。

    アクション異常通知からの情報をたどる中で、
    ルール画面やメッセージ画面で受信スロットも表示されていることから、
    各種アラートをチェックするルールは単一であっても、入口の受信スロットが分かれていれば、
    切り分けが可能になるかと考えました。もちろんスコープは別になります。
    運用対策としてですが、そういう対処法もあるかと、既存プログラムの修正も視野にいれております。

    >>また受信スロットや、仮にルールを複数に切り分けたとしても、アクション失敗通知やアクション実行履歴からどの受信スロット・ルールが使われたかを直接知ることはできず、見分けをつけるのは難しいかと思います。

    上記の件につきましては、アクションタイムスタンプから、スコープとルールが辿れると思っております。

    なので、受信スロットを分けることは入力データの切り分けに一役買えると考えており、それもあって受信スロット作成数の上限をうかがっております。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    アクション異常通知からの情報をたどる中で、
    ルール画面やメッセージ画面で受信スロットも表示されていることから、
    各種アラートをチェックするルールは単一であっても、入口の受信スロットが分かれていれば、
    切り分けが可能になるかと考えました。もちろんスコープは別になります。

    「ルールは単一」とありますが、先の回答の通り1つのルールに対して設定可能な受信スロットは1つだけとなります。そのため複数の受信スロットに対する入力を1つのルールで処理することはできません。

    仰る意図としてはルールの定義内容が単一なだけで、ルールの実体は受信スロットに対して1対1対応する形で分けて作るということでしょうか?

    なので、受信スロットを分けることは入力データの切り分けに一役買えると考えており、それもあって受信スロット作成数の上限をうかがっております。

    申し訳ございません、こちらについては再確認の意図を見落としておりました。受信スロットの作成数に上限は特にございません。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。昨日のうちに返答できず、申し訳ありません。

    >>仰る意図としてはルールの定義内容が単一なだけで、ルールの実体は受信スロットに対して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も同じもの)なのにという声もあがると思いますが、対象アラート数を減らす意味の暫定対応です。


    この時に受信スロットが分かれているので、メッセージ画面でアクション異常通知されたアラートが
    見つけやすくなると考えています。

    アクション異常通知がメッセージまで紐づけできれば不要となります。
    また、運用を開始してみて、アラートが時間で管理できそうならは、暫定設定はしないつもりです。

    言葉ばかりで説明してしまったので、齟齬が発生していたのではないかと思うのですが、これで如何でしょうか?
    どの受信スロットから入っても、ルールは全件舐めているようですが、そこで不都合が生じるようなら今のうちに教えていただけますか?

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    詳細なご説明ありがとうございます。

    どの受信スロットから入っても、ルールは全件舐めている

    この点については理解を誤っている可能性がございますので念のため触れておきますと、受信スロットにてデータを受信したとき、処理が行われるのは「その受信スロットを選択したルール」のみとなります。

    これを確かめるための極端な例として、新しく作成した受信スロットに対して特にルールを設定せずにデータを送信していただきますと、既存の他ルールが1つも実行されないことを確認できるかと思います。

    ご確認のほど、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    迅速なご返信ありがとうございます。
    >>受信スロットにてデータを受信したとき、処理が行われるのは「その受信スロットを選択したルール」のみとなります。

    そうだと思っておりましたが、ご明言いただけて安心いたしました。
    ご提案のテストも検証に組み込ませていただきます。
    ありがとうございます。

    末筆になりますが、
    >>この時に受信スロットが分かれているので、メッセージ画面でアクション異常通知されたアラートが
    見つけやすくなると考えています。

    上記の考えは間違っていないということでよろしいですか?
    何度も申し訳ありませんが、ご返答をお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    メッセージ一覧画面には受信に使用した受信スロットが表示され、また受信スロットによる絞り込み検索(添付画像参照)が可能ですので、これをメッセージの絞り込みに利用することは可能です。

     

    アクション失敗時の通知内容には受信スロットの情報が含まれることはないため、そこに関してはスコープと受信スロットの命名を対応付けるなどして工夫が必要となりますが、考えとしては間違っていないかと思います。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    絞り込み検索のご教示、ありがとうございました!

    0
    コメントアクション Permalink

サインインしてコメントを残してください。