実行結果の通知について考える

[ta-chibana]

関連: #7

検討事項

1. Slackで通知を行うが、どのようなAPIを使うか決める
2. どういったイベントを通知するか決める

   考えていること

3. 利用するAPI
   • Incoming Webhook
4. 通知するイベント
   • 実行結果（成功 or 失敗）が把握できた方が良い
   • 各ログレベルの基準を別Issueで決め、実行結果の把握できるログレベル以上を通知するようにする

[ta-chibana]

1. 利用するAPIについては、Incoming Webhookで良い。
2. 通知するイベントについては #23 より、INFOが毎回通知されると通知量が多くなって、より重要な情報が埋もれてしまう可能性があると考えられるため、WARN以上で良いと思う。

[ta-chibana]

• ログレベルでなくイベント
  • 完全に止まってしまった場合
  • ここまで終わった的なイベント
• 始まりしかないログだと結果がわからなくなってしまう
  • 止まってしまうケースをきちんと想定しなければならない

[ta-chibana]

ログレベル以外で出力先を振り分けるにはTurboFiltersとmarkerを使えばできそう。 http://d.hatena.ne.jp/torazuka/20120617/logback

[ta-chibana]

前回まで決まってたこと

• ログレベルの出力ではなくイベントでログを出す

わからないこと

1. どういうイベントの時にログを出していいかわからない
2. イベントで通知をしようとするとアプリが止まったことを感知できない

決まったこと

1. イベントを出す時

   * アプリ起動時
   * アプリ終了時
   * Contrller, Transfer, Loaderのサービス的なメソッドの呼び出し/終了
   * DB保存時
   * main()にcatchされた時

2. 終了のログが来なければ異常終了を感知できる

[dodoichi]

• Contrller, Transfer, Loaderのサービス的なメソッドの呼び出し/終了
• DB保存時

上のタイミングでの通知はいりません。 下のパターンだけでよいです。

• アプリ起動時
• アプリ終了時
• 異常終了時 起動クラスでトラップする

[ta-chibana]

@javamas/javamas-admins

[ta-chibana]

通知するのはアプリが動いているかどうかのみで良いのですね！

1. 利用するAPI
   • Incoming Webhook
2. 通知するイベント
   • アプリ起動時
   • アプリ終了時
   • 異常終了時

上記で決めようと思います。

---

起動クラスでトラップする

36 とも関連しますね。

[disc99]

アプリとはこのアプリの起動、終了? それともバッチ処理の起動、終了? アプリ自体は常時起動になるので、バッチのイベントを出すのであれば、Contrllerの先頭とLoaderの最後で通知が必要になると思います。

[dodoichi]

あ、そだね！ 整理しよう。

初期要件

プロセスの開始、終了時に通知する。

MQを考えてなかった頃は、1プロセスの開始と終了で通知する想定だった。

しかし、MQを挟んでプロセスが3つに分かれたので、プロセスを跨いで通知する必要がある。

変更後の要件

バッチ処理の開始、終了時に通知する。

バッチ起動時と、Loaderでの処理終了時に通知する。実装方法は別Issueで考える。

他への影響

監視対象を再精査する。関連 #50

[ta-chibana]

すでにまとまっている感じはありますが、正常時の流れとして

1. 起動クラスによってCollectorを起動
2. CollectorがMQにメッセージを送り、それをTransformer、Loaderで処理
3. Loaderによる処理が終了

上記の流れの1と3、異常終了時に通知する（ #36 ）ようにし、 MQ、Transformer、Loaderで通知するイベントに関しては #50 で検討という認識でよろしいでしょうか？

[ta-chibana]

@javamas/javamas-admins

[dodoichi]

MQ、Transformer、Loaderについては、通知はありません。なので、#50 で考えればよいです。