sentryオススメ設定

original https://vividmuimui.github.io/slides/sentry-tips/slides/

1. sentry オススメ設定 sentry オススメ設定 2018/02/06 社内LT 資料 @vividmuimui 1
2. sentry とは sentry とは ざつにいうと、プログラムのエラーを通知したりその詳細を見れたりするサ ービス Ruby, C#, JS, Go etc 色々対応してます https://docs.sentry.io/ 2
3. はじめに はじめに Ruby/Rails 中心に書きます 他の言語でもほぼ一緒だと思いますが違ったら良い感じに読み替え たり調べたりしてください まだ使いこなしたとはいえない状態で書いているので、現時点でのオス スメ設定です 動かすための基本設定みたいなのは書かないです 3
4. ドキュメント系 ドキュメント系 ドキュメント 設定画面一覧 account settings project settings organization settings https://docs.sentry.io/ https://docs.sentry.io/clients/ruby/ https://docs.sentry.io/clients/ruby/integrations/rails/ https://your- sentry.example.com/account/settings/ https://your- sentry.example.com/sentry/sandbox/settings/ https://your- sentry.example.com/organizations/sentry/settings/ 4
5. 秘匿情報はきちんと lter す 秘匿情報はきちんと lter す る る メールアドレスやパスワードなどがsentry 上で表示されないようにするた め。 のprocessors の項目 rails だと以下のようにすると良いとdocument にある。 概ねこれで問題がないが、 rails だと lter_parameters に を登録すれば や も lter してくれる。 sentry は しか lter してくれないので注意。 sentry でもよしなにやってもらうためには を登録する必要がある。 https://docs.sentry.io/learn/sensitive-data/ https://docs.sentry.io/clients/ruby/con g/#optional-settings config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s) 5
6. user のcontext を出す user のcontext を出す 誰がそのエラーを起こしたかをわかるようにするため。 デフォルトではIP アドレスが取得されます。 設定する内容としては、 一般ユーザーの場合はそのユーザーを一意に識別できるID など 管理ツール等で社内の人間がエラーを起こした場合は、ID よりは名前や メールアドレスを設定したほうが解決が圧倒的にスムーズで良い sanitize eld にemail を追加している場合、user context にemail を 設定したときも lter されてしまうので注意. フィールド に入れる必要がある https://docs.sentry.io/learn/context/#capturing-the-user 6
7. tags context を活用する tags context を活用する タグはこんな感じでそのエラーがどういう環境で起きたかとかを見れる。 https://docs.sentry.io/learn/context/#tagging-events 7
8. tags context を活用する tags context を活用する そのエラーでどういう端末・サーバーで起きているのかを割合でみれる 8
9. tags context を活用する tags context を活用する そのタグで起きているエラーを絞込できる 9
10. extra context を活用する extra context を活用する そのエラーが起きた時に追加したい詳細な情報をなんでも詰め込める場所。 request_id, params あたりを出しておくと良さ https://docs.sentry.io/learn/context/#extra-context 10
11. context の種類の補足 context の種類の補足 tags, user, extra の3 種類ある。 tags は、tags で lter したりできる extra は、そのエラーに表示されるだけ。 lter できたりしない。 リクエストparams だしたり、http header 出したりするのが良さそ う user はtags とextra 両方の扱いになる という認識。 https://docs.sentry.io/learn/context/ 11
12. 通知ルールのカスタマイズ 通知ルールのカスタマイズ デフォルトでは初めてそのエラーが発生した時に通知がされるだけ 通知rule は複数設定できる 「指定時間内に指定回数起きたら」や「特定のタグがついていたら」な どの条件が設定できる また、１つのrule の中に条件を複数書くことが出来る https://your-sentry.example.com/sentry/your- project/settings/alerts/rules/
13. 既知のエラーでも1 日1 回は通知するようにルールを設定する場合はこんな漢 字。 12
14. 通知内容のカスタマイズ 通知内容のカスタマイズ 通知のintegration(slack など) が設定されていると以下のような設定項目が出 てくる https://your-sentry.example.com/sentry/your-project/settings/alerts/
15. include tags は設定すべき incude rule は通知rule が複数ある場合は設定したほうが良い ほかはよしなに。 13
16. auto resolve する auto resolve する 該当エラーが一定期間発生しなければresolve 、という設定ができる。 古いエラーを溜め込んでしまっても割れ窓っぽくなってしまうので、 勇気を持って見て見ぬふりしていくのも大事そう( プロジェクトやチームの 都合によりけり) https://your-sentry.example.com/sentry/your-project/settings/ 14
17. release を設定する release を設定する 該当エラーがどのリリースで発生したのかを特定できるようにするため。 のrelease の項目 github リポジトリだったらそのSHA リポジトリルートにREVISION ファイルがあればその中身を見る => capistrano でデプロイしてれば勝手に読んでくれる api を叩く などで設定できる。 そのリリースでどういうエラーが起きたのか、次回リリースのタイミングで resolve 、github との連携がうまく行ってればそのコミットのauther や github のページへのリンクなどいいこといっぱい https://docs.sentry.io/learn/releases/ https://docs.sentry.io/clients/ruby/con g/ 15
18. bash のエラーを検知する bash のエラーを検知する 出来るらしい https://docs.sentry.io/learn/cli/send-event/#bash-hook 16