SentryをNext.js13に導入したい

In particular, building with Turbopack will currently cause the Sentry SDK not to be included in your app.

Turbopackは今んとこムリ

Automatic Performance Monitoring for both the client and server, from version 6.5.0

こんなこともやってくれるのか

Under the hood the SDK relies on our React SDK on the frontend and Node SDK on the backend, which makes all features available in those SDKs also available in this SDK.

React / Node SDKの内容も確認する必要がありそう

npx @sentry/wizard -s -i nextjs

こっちでやったら@sentry/nextjs isn't in your dependencies.と怒られた。
yarn addしたら通った

client, server, edgeと3種類のconfigファイルが生成された。
それぞれにwizardcopyっていうファイルがあって、さらにpropertiesファイルもある。
多いな。

Vercel integrationもあるみたい
デプロイしたら見る
https://docs.sentry.io/product/integrations/deployment/vercel/

Error: Event handlers cannot be passed to Client Component props.
<button type="button" style={{...}} onClick={function} children=...>
^^^^^^^^^^
If you need interactivity, consider converting part of this to a Client Component.

sampleのbuttonをHomeに追加したらエラーになった。それはそう。

↑このエラー自体をキャッチしてくれていたので自ずと検証ができたw

シンプルにErrorをthrowするだけでいいんだな

Sentry.captureException(new Error("something went wrong"), {
  tags: {
    section: "articles",
  },
});

こういう感じっぽい

Sentry.withScope(function(scope) {
  scope.setUser(someUser);
  Sentry.captureException(error);
});

scopeという概念がよくわからない

Slack通知も有料かー、じゃあきついかもな

Sentry のエラーを Slack などで通知している場合、 environment を設定しておくと通知設定などを分けられるので便利です。

エラーが送信されても、そのエラーがどのユーザーによって起こされたものか分からなければ意味は半減します。

login処理のときについでにsetUserすればよいのかな

ユーザーがエラーを起こしたことが特定できても、その直前まで何をしていたのか、という文脈が重要になることはあります。たとえばチャットアプリを開発していて、チャットメッセージの送信直後にエラーが出ていた場合などです。

その文脈はSentryではBreadcrumbsという機能で保存できます。

Breadcrambのpopは勝手にやってくれるのかな

特にWebフロントエンドでは、ブラウザ依存のエラーなどどうしようもないエラーログがしょっちゅう流れますし、Network Errorなどユーザー側の通信状況に依存するようなエラーが流れることも多いです。これらのエラーが毎回Slackに流れるとうるさいので、マナリンクの場合はIssueの詳細画面で「Ignore」を押してAlertの対象外にしています。

トリアージの問題はたしかにあるな

エラーが通知されたとき、即座に対応する必要があるものもあれば、一時的なものや短期的には許容したいものがあります。いずれにしても、定期的にトリアージしなければSentry上にissueとしてたまり続ける一方です。自分が所属しているチームでは、週に一度30分、スクラムのレトロスペクティブ・プランニングをやる前にissueのトリアージを行うことにしました。

週次のルーティンにするのは良さそう

現状すべてのエラーを通知する必要がないため、アプリケーション側でフィルタリングしています。原則アプリケーションサーバーへのリクエストが共通して通過する部分で、ステータスコードが500系の場合のみ通知されるように実装しています。

エラーコードの詳細な場合分けよくわかってない

ignoreErrors では、無視したい (Sentry に通知しない) エラーを設定しています。
メンテナンスモード時の通信エラーや、利用しているモジュール側で発生するエラーなど、開発側で想定済みのエラーを ignore の対象にしています。

UI の一部に不具合があった際、React 16 以降では error boundary という機構により、子コンポーネントのエラーを親コンポーネントでキャッチ出来ます。

app dirだとerror.tsで呼べるのかな

そうっぽいな
https://beta.nextjs.org/docs/api-reference/file-conventions/error

Magic Moment Playbook 上で通信エラーが起きた際は、スナックバーの UI コンポーネント AlertSnackbar.tsx を表示させるようにしていますので、try / catch で拾ったエラーの大半はこのコンポーネントから Sentry に通知させています。

こういうのもいいね