Next.js: サーバー側でログを報告するためのエラーをキャッチして処理する方法

クライアント側でエラーをログに記録するために、次のことを行っています。
https://gist.github.com/jgautheron/044b88307d934d486f59ae87c5a5a5a0

基本的にサーバーにエラーを送信します。エラーは最終的にstdoutに出力され、 Dockerロギングドライバーによってキャッチされます。
react-guardでSSRエラーを正常に検出し、コアNextファイルをオーバーライドする必要はありません。

私もこの問題を抱えています。 私は疑問に思います：次のhandleRequestから拒否された約束を返すだけで十分でしょうか？ つまり、ここのコードを次のように変更します。

handleRequest (req, res, parsedUrl) {
  // .....snip....

   return this.run(req, res, parsedUrl)
     .catch((err) => {
       if (!this.quiet) console.error(err)
       res.statusCode = 500
       res.end(STATUS_CODES[500])

       // rethrow error to create new, rejected promise 
       throw err;
     })
}

次に、ユーザーコードで：

const app = nextJs({ dev: process.env.NODE_ENV !== 'production' });
const nextJsHandler = app.getRequestHandler();
const expressApp = express();

app.prepare().then(() => {
   // invoke express middlewares
   // ...

   // time to run next
   expressApp.use(function(req, res, next) {
     nextJsHandler(req, res).catch(e => {
       // use rejected promise to forward error to next express middleware
       next(e)
     })
   });

   // Use standard express error middlewares to handle the error from next
   // this makes it easy to log to sentry etc.
})

@arunoda @rauchg私がすぐ上で提案した変更は

エラーを再スローして、それを試してみることに同意します。
また、 renderToHTMLでも再スローする必要があります...

また、サーバー側とクライアント側の両方で、Sentryと同様のサービスにエラーを送信したいという状況にあります。

このようなサービス/ツールの最も価値のある機能は、最も予期しない問題を報告することであると私は信じています。これは、私の経験では、実際の（つまり、クライアント側の）キャッチされないエラーです。 残念ながら、関連する問題＃2334で以前に強調したように、Next.jsのクライアント側ハンドラーはこれらのエラーを自分自身に保持し、そのような他のツールのSentryにそれらを渡す方法はありません。

私たちを特に苦しめたのは、これです。クライアント側でReactレンダリングを行う前にキャッチされない例外が発生した場合、適切にサーバー側でレンダリングされたページがエラーページとして再レンダリングされます。 これは優れた機能であると同時に、クライアントの驚くべき部分で既にレンダリングされたドキュメントを提供する利点を本質的に損なうため、イライラする開発者エクスペリエンスと見なすことができます。

問題を説明するサンプルページを次に示します。

import React from 'react';

// Works well in Node 8, but crashes in Chrome<56, Firefox<48, Edge<15, Safari<10, any IE…
const whoops = 'Phew, I made it to the client-side…'.padEnd(80);

export default () => <pre>{whoops}</pre>;

上記のコードは、サーバー側で完全にレンダリングしてクライアントに配信できますが、ほとんどのブラウザでページ全体がクライアント側で恐ろしい「予期しないエラーが発生しました」というメッセージに置き換えられる前に、不要なコンテンツのフラッシュになります。 、 Sentry （または他のサービス/ツール）にません。

この「エラーの飲み込み」は、ほとんどのクライアント側のエラー報告ツールがフックする標準のonerrorハンドラー（または、クライアント側の非同期性を考えるとより適切な、より現代的ではあるが普及していないonunhandledrejection ）の活用も防ぎます。コード）。

考えられるクライアント側の解決策

私の知る限り、このタイプのpre-Reactクライアント側エラーは、Next.jsのclient / index.jsのtry / catchブロックに飲み込まれます。 Componentレンダリングされる程度の値に再割り当てされErrorComponent （現在の線67-72 ）。

Next.jsの作成者およびメンテナの皆様、レンダリング内容を制御するために、次のアイデアの中で何が許容可能/可能であると思いますか。

• この種のエラーを処理するために、client / index.jsのcatchブロックにフックを導入しますか？
• エラーが検出された場合は、onerror / onunhandledrejectionハンドラーにエラーを送信しますか？
• エラーを再スローするオプションを提供しますか？
• エラーコンポーネントを表示しないオプションを提供しますか？
• カスタムエラーコンポーネントを表示するオプションを提供しますか？

この種のエラーを処理するために、client / index.jsのそのcatchブロックにフックを導入しますか？
エラーが検出された場合は、onerror / onunhandledrejectionハンドラーにエラーを送信しますか？

これは私たちが社内で話し合ったことです。 そして、私たちはすぐに対処します。

私はSentry.ioを使用してエラーを報告していますが、適用する解決策は次のとおりです。

1-サーバー側でravenノードを構成します
2-クライアント側でravenjsを構成します（ _document 。

この2つの手順で、クライアントとサーバーの両方で未処理の例外をキャッチします。

3- _errorページを作成します。 nextjsがリクエストを処理すると（クライアント側かサーバー側かに関係なく）、そのページがレンダリングされるとエラーが発生します。 _errorページのgetInitialPropsメソッドで、歩哨にエラーを報告します。

クライアントconst Raven = require('raven-js');またはサーバー側const Raven = require('raven');どちらにいるかに応じて、動的にインポートしてraven-nodeまたはravenjsが解決されるかどうかをロードする方法を決定する方法。
ravenモジュール（サーバー側のモジュール）をバンドルしないようにwebpackを構成したことに注意してください。これにより、 next.config.jsが次のように更新されます。

const webpack = require('webpack');

module.exports = {
  // Do not show the X-Powered-By header in the responses
  poweredByHeader: false,
  webpack: (config) => {
    config.plugins.push(new webpack.IgnorePlugin(/^raven$/));
    return config;
  },
};

@acanimal

2-クライアント側でravenjsを構成します（これは_documentで行いました。

_document.js raven-jsをどのように設定したか教えていただけますか？ エラーが発生しても歩哨は何も起こらないので、うまくいきません。

_error.jsページですべてのエラーを手動で歩哨に送信する必要がありますか？

// _document constructor
constructor(props) {
    super(props);
    Raven
      .config('...')
      .install();
}

Next.jsは、 quietに設定しない限り、サーバー上のconsole.errorにエラーを出力します。

Sentryを使用すると、 autoBreadcrumbsを有効にしてこの出力をキャプチャしてから、独自のメッセージを手動でキャプチャできます。 タイトルはわかりにくくなりますが、スタックトレース全体が含まれます。

実装例：

const express = require('express');
const nextjs = require('next');
const Raven = require('raven');

const dev = process.env.NODE_ENV !== 'production';

// Must configure Raven before doing anything else with it
if (!dev) {
  Raven.config('__DSN__', {
    autoBreadcrumbs: true,
    captureUnhandledRejections: true,
  }).install();
}

const app = nextjs({ dev });
const handle = app.getRequestHandler();

const captureMessage = (req, res) => () => {
  if (res.statusCode > 200) {
    Raven.captureMessage(`Next.js Server Side Error: ${res.statusCode}`, {
      req,
      res,
    });
  }
};

app
  .prepare()
  .then(() => {
    const server = express();

    if (!dev) {
      server.use((req, res, next) => {
        res.on('close', captureMessage(req, res));
        res.on('finish', captureMessage(req, res));
        next();
      });
    }

    [...]

    server.get('/', (req, res) => {
      return app.render(req, res, '/home', req.query)
    })

    server.get('*', (req, res) => {
      return handle(req, res)
    })

    server.listen('3000', (err) => {
      if (err) throw err
      console.log(`> Ready on http://localhost:${port}`)
    })
  })
  .catch(ex => {
    console.error(ex.stack);
    process.exit(1);
  });

これは、実際のコードを応用した非常に工夫された例です。 私はこの形式でそれをテストしていません。 壊れたら教えてください。

もちろん、Next.jsがこれらのエラーをExpressに渡すことができれば、それでも最善です。そうすれば、Sentry / Express統合をすぐに使用できます。

@tusgavomelo返信が遅くなってすみません。

更新があります。 私たちのアプリには、クライアント側またはサーバー側にいる場合にRavenインスタンスを考慮に入れるためのメソッドを含むヘルパーファイルがあります。

let clientInstance;
let serverInstance;

const getRavenInstance = (key, config) => {
  const clientSide = typeof window !== 'undefined';

  if (clientSide) {
    if (!clientInstance) {
      const Raven = require('raven-js');  // eslint-disable-line global-require
      Raven.config(key, config).install();
      clientInstance = Raven;
    }

    return clientInstance;
  }

  if (!serverInstance) {
    // NOTE: raven (for node) is not bundled by webpack (see rules in next.config.js).
    const RavenNode = require('raven'); // eslint-disable-line global-require
    RavenNode.config(key, config).install();
    serverInstance = RavenNode;
  }
  return serverInstance;
};

このコードは、サーバー側（リクエストが到着したとき）とクライアント側の両方で実行されます。 ravenパッケージのバンドルを回避するために、webpack（ next.config.jsファイル）を構成しました。

@acanimalあなたは多分実用的な例を提供できますか？ フルスタックトレースを取得していないようですか？ または多分あなたはあなたの_error.jsを投稿できますか？

_error.jsでRavenInstance.captureException(err)ようなことをしていますが、発生したエラーの種類と場所がわかりません。

export default class Error extends React.Component {
  static getInitialProps({ res, err }) {
    const RavenInstance = getRavenInstance('__SENTRY__')
    if (!(err instanceof Error)) {
      err = new Error(err && err.message)
    }
    RavenInstance.captureException(err)
    // const statusCode = res ? res.statusCode : err ? err.statusCode : null;

    return { }
  }

  render() {
    return (
      <div>
        <p>An error occurred on server</p>
      </div>
    )
  }
}

モジュールの再構築時に次の画面がクリアされてエラーが表示されないようにするには、 quietをfalseに設定する必要があるため、これはカスタムロガーのサポートを求める場所のようですが、ここで実行可能な唯一のハックにはquietをfalseに設定します。

エラーの詳細は、stderrストリームでも入手できます。
process.stderr.write = error => yourErrorLog(error);

_unortodox_ソリューションが大好きです

function installErrorHandler(app) {
  const _renderErrorToHTML = app.renderErrorToHTML.bind(app)
  const errorHandler = rollbar.errorHandler()

  app.renderErrorToHTML = (err, req, res, pathname, query) => {
    if (err) {
      errorHandler(err, req, res, () => {})
    }

    return _renderErrorToHTML(err, req, res, pathname, query)
  }

  return app
}
// ¯\_(ツ)_/¯

カスタムWebpack構成なしでノードとブラウザーの正しいRavenを取得する方法のコンパクトバージョン。 @acanimalコメントに触発された

// package.json
"browser": {
    "raven": "raven-js"
}

// getRaven.js
const Raven = require('raven')

if (process.env.NODE_ENV === 'production') {
  Raven.config('YOUR_SENTRY_DSN').install()
}

module.exports = Raven

要旨

この問題を調査している人のための簡単な要約。

// pages/_error.js
import Raven from 'raven';
...
static async getInitialProps({ store, err, isServer }) {
   if (isServer && err) {
      // https://github.com/zeit/next.js/issues/1852
      // eslint-disable-next-line global-require
      const Raven = require('raven');

      Raven.captureException(err);
    }
    ...

// next.config.js
config.plugins.push(new webpack.IgnorePlugin(/^raven$/));

@acanimalのコメントに感謝します。

raven （前のコメントで提案されているようにwebpackでは無視してください）とraven-js両方をインストールしてから、同形のRavenをインスタンス化するヘルパーを作成します（例： lib/raven.js

import Raven from 'raven-js';

// https://gist.github.com/impressiver/5092952
const clientIgnores = {
  ignoreErrors: [
    'top.GLOBALS',
    'originalCreateNotification',
    'canvas.contentDocument',
    'MyApp_RemoveAllHighlights',
    'http://tt.epicplay.com',
    "Can't find variable: ZiteReader",
    'jigsaw is not defined',
    'ComboSearch is not defined',
    'http://loading.retry.widdit.com/',
    'atomicFindClose',
    'fb_xd_fragment',
    'bmi_SafeAddOnload',
    'EBCallBackMessageReceived',
    'conduitPage',
    'Script error.',
  ],
  ignoreUrls: [
    // Facebook flakiness
    /graph\.facebook\.com/i,
    // Facebook blocked
    /connect\.facebook\.net\/en_US\/all\.js/i,
    // Woopra flakiness
    /eatdifferent\.com\.woopra-ns\.com/i,
    /static\.woopra\.com\/js\/woopra\.js/i,
    // Chrome extensions
    /extensions\//i,
    /^chrome:\/\//i,
    // Other plugins
    /127\.0\.0\.1:4001\/isrunning/i, // Cacaoweb
    /webappstoolbarba\.texthelp\.com\//i,
    /metrics\.itunes\.apple\.com\.edgesuite\.net\//i,
  ],
};

const options = {
  autoBreadcrumbs: true,
  captureUnhandledRejections: true,
};

let IsomorphicRaven = null;

if (process.browser === true) {
  IsomorphicRaven = Raven;
  IsomorphicRaven.config(SENTRY_PUBLIC_DSN, {
    ...clientIgnores,
    ...options,
  }).install();
} else {
  // https://arunoda.me/blog/ssr-and-server-only-modules
  IsomorphicRaven = eval("require('raven')");
  IsomorphicRaven.config(
    SENTRY_DSN,
    options,
  ).install();
}

export default IsomorphicRaven;

その後、 pages/_error.jsで使用でき、サーバー側とクライアント側の両方で機能します。

import NextError from 'next/error';
import IsomorphicRaven from 'lib/raven';

class MyError extends NextError {
  static getInitialProps = async (context) => {
    if (context.err) {
      IsomorphicRaven.captureException(context.err);
    }
    const errorInitialProps = await NextError.getInitialProps(context);
    return errorInitialProps;
  };
}

export default MyError;

これが、Next.jsをサポートするRollbar sourcemapwepbackプラグインhttps://github.com/thredup/rollbar-sourcemap-webpack-plugin/pull/56のPRです:)

@tusgavomelo 、ストリームに存在するエラーを利用する方法について詳しく説明していただけますか？
"process.stderr.write = error => yourErrorLog（error）;"

エラーをノードコンソールに記録するために、このコード行をどこに書く必要がありますか？

それはクライアント側だけです。
Rollbar.error('some error')

https://docs.rollbar.com/docs/javascript

@ teekey99 @sentry/browserについて同様の解決策はありますか？ たぶん-sentryの例で更新しますか？

@sheerunこれまでravenとraven-js使用してきました。 すべての新機能が@sentry/nodeと@sentry/browser追加されたため、これらはおそらく非推奨になることを認識しています。 プロジェクトでこれらの新しいライブラリをまだ使用していませんが、調べてみます。 実用的な例があれば、それを取り戻します。

with-sentryの例は最近更新されました。

@timneutkensわかりましたが、サーバーエラーをキャッチするには遅すぎるアプリ内でSentryが初期化されるため、サーバー側エラーはサポートされていません。 適切な解決策はおそらくどこかで@sentry/node使用するでしょう

@sheerun同じ問題が発生しています。 @sentry/nodeを使用するのは簡単ではありません。 このSentryの例のreadmeは、私が作業しているアプリケーションにすでにあるカスタムサーバーの使用を提案しています。 カスタムExpress.jsサーバーで例外をキャプチャするには、ミドルウェアを処理する最初のエラーとしてSentryエラーハンドラミドルウェアエラーを挿入する必要があります。 次のハンドラーの直後にSentryのエラーハンドラーを挿入すると、エラーはその時点ですでに飲み込まれており、Sentryはそれを認識しません。

@sentry/browserのgetInitialPropsで_error.jsを使用していますが、クライアント側とサーバー側の両方で機能しているようです。 @sentry/browserがサーバー側でサポートされることになっているのかどうかはわかりませんが、Sentryにイベントを受信して​​います。

カスタムExpressサーバーのエントリファイルで@sentry/node Sentry.init()を介して

これが私が使用しているセットアップの要点です： https ：

面白い！

ここでは確かにある種のグローバルな状態が起こっています（これは少し怖く、おそらくもろくて望ましくありません）。 _error.js変更を適用する：

• __なし__カスタムサーバーでSentryを構成する：
  
  
  
  • 開発モードまたは本番環境で実行している場合（つまり、アプリをビルドしている場合）、サーバー側のエラーが発生してもSentryに何も報告されませんが、サーバーログにReferenceError: XMLHttpRequest is not definedエラーが発生します
  
  
• __構成後__カスタムサーバーでSentry：
  
  
  
  • サーバー側の例外が報告されますが、Sentryに奇妙なError: Sentry syntheticException記録されます
  
  

公式の解決策が何であるかを理解するのは良いことです。 Nextのドキュメントでは、カスタムの<App>コンポーネントの使用を推奨しているようです。これは、「with Sentry」の例で行われていることですが、これはクライアント側でのみ機能します。

確かにエラー報告は、アプリが最初にレンダリングされるまで発生しません。 次は、たとえばページをレンダリングする前に失敗する可能性があります。 たまたま、アプリがサーバー側で最初にレンダリングされた後に機能する場合もありますが、完全なソリューションではないことは確かです。

with-sentryの例は、@ timneutkensでも機能しません。 プロジェクトを実行し、実際のDSNでテストすると、400の応答が返され、歩哨には何も届きません（APIのバージョン7）。

{"error":"Bad data reconstructing object (JSONDecodeError, Expecting value: line 1 column 1 (char 0))"}

@mcdougalは私のために機能しませんでした。 どういうわけかクライアントにバブルアップするグローバルなサーバー側のセットアップがあることは、すでにそれほど素晴らしいことではありませんでしたが、そのハックがあっても、私は歩哨301の応答を受け取りました。

多くのオプションがなく、複数のプロジェクトで実行されているため、歩哨のセルフホストセットアップで構成が誤っている可能性があるかどうかはわかりません。

with-sentryの例で推奨されているのと同じ方法で@sentry/browserを使用していますが、サーバーとクライアントの両方から歩哨にエラーを送信しているようです。 特別な設定はありません。例と同じコードだけです。

@Jaunyサーバーから送信してもよろしいですか？ どのようにそれをテストしましたか？ 例のreadmeは、サーバーでは機能しないことを示唆しているようです。

@timrogersはい、確かに私の悪いです。テストされたエラーはサーバーから来ていると思いましたが、実際にはクライアントからトリガーされました:(

現在の例with-sentryは、getInitialPropsでスローされたエラーをキャッチせず、アプリケーションのレンダリングツリーにあるエラーをキャッチしているようです。私の場合、エラーのほとんどはgetInitialPropsからのものです。

@sheerun上記のmcdougal回避策を試すことができますか？ 完璧ではありませんが（奇妙な合成歩哨エラー）、すべてのエラーが発生するという印象を受けており、それが正しくないかどうかを知りたいと思います。 trueの場合、with-sentryの例は、Next.jsがそれを改善する方法をアドバイスできるようになるまで、おそらくそれで更新する必要があります（理想的には、server.jsの歩哨エラーハンドラーがスキップされないようにしますか？）。

それは2つの主要な問題でちょっとうまくいくようです：

1. おそらく、非同期サーバー側コードが不必要にリジェネレーターコードにコンパイルされるため、本番環境のサーバー側スタックトレースはinternal / process / next_tick.jsで切り捨てられることが多く、エラーの原因はまったくわかりません。
2. 次のリクエストハンドラが呼び出される前にエラーがスローされた場合、エラー処理は機能しません（カスタムサーバーコードなど）

実際には、カスタムエラーのgetInitialPropsをさらにテストした後、たとえばカスタム_appのgetInitialProps内でエラーが発生した場合、何らかの理由で本番環境で発生することさえありません。

ええ、私は数日間私の試みで走った後、確かにいくつかの奇妙な行動をとっています。 私たちが直面している主な問題は次のようです。

1. CSRの場合は@sentry/browserをインポートし、SSRの場合は@sentry/nodeをインポートします
2. CSRとSSRの両方で常にトリガーされるエラー処理を配置する場所を見つける

私は怠惰なインポートとグローバル状態を使用して#1を解決しようと考えていました。

const sentryInitialized = false;

# Inside some trigger point
const Sentry = ssr ? eval(`require('@sentry/node')`) : eval(`require('@sentry/browser')`);
if (!sentryInitialized) {
  Sentry.init({dsn: SENTRY_DSN});
}
Sentry.captureException(err);

Nextの動的インポートを使用できるかもしれませんが、私はまだそれらに精通していません。 また、エラー処理コードがトリガーされるたびにrequireを呼び出すことの影響もわかりません。 これを試してみたら更新します。

問題#2限り、可能性は次のように思われます。

1. _app.componentDidCatch 、これはSSRでは起動しません
2. _error.getInitialProps 、これには多くの問題があります
3. ...他に何かありますか？ Nextサーバーハンドラー関数でSSRに対してできることはありますか？

私の直感では、Nextの前にSentryのエラーハンドラーを挿入することでサーバー上でこれを行う方法があると思いますが、まだ試してみません。

現時点では、Nextはそれを行うのに役立つフックを提供していません。 これが機能することがわかった場合は、それらを追加できます👌

ただし、Nextのキャッチが早すぎるため、これが機能しないリスクがあります。

@mcdougal Ah＆＃！％回避策が、

私の完全な無知を許してください。しかし、

@Enalmada次のエラーハンドラーを無効にしたくないと思います。これは、適切なエラーページをレンダリングするものになるためです。 その前に他のミドルウェアを挿入したいだけです。 それでうまくいくと思いますが、試してみる必要があります。

それを修正しても、クライアント側のエラー処理がうまく機能しているとは思えません:(

この問題全体は残念であり、Nextを本番環境で安全に実行するための障害になります。

参考までに、私はどこにでも@sentry/nodeをインポートし、next.config.jsに次のように配置します。

        if (!isServer) {
          config.resolve.alias['@sentry/node$'] = '@sentry/browser'
        }

これは@mcdougalのevalよりも優れている可能性があります

カスタム_appコンポーネントとエラー処理に関する追加の注意事項は次のとおりです。

1. _app.jsは、 _error.jsまたは404のようなページを含むすべてのページに使用されるため、 ctx.errが渡されたときにエラーがスローされないようにする必要があります。
2. _error.js getInitialPropsが呼び出されないようにするため、アプリのgetInitialPropsでComponent.getInitialPropsを呼び出すことを忘れないでください（ ctx.errが存在する場合でも呼び出す）

class MyApp extends App {
  static async getInitialProps (appContext) {
    const { Component, ctx } = appContext
    if (ctx.err) {
      if (Component.getInitialProps) {
        pageProps = await Component.getInitialProps(ctx)
      }
      return { error: true, pageProps }
    }
    // here code that can throw an error, and then:
    if (Component.getInitialProps) {
      pageProps = await Component.getInitialProps(ctx)
    }
    return { pageProps }
  }
  render() {
    if (this.props.error) return super.render()
    // rest of code that can throw an error
  }
}

これまでのところ、next.jsでエラーレポートを適切に設定することは非常に壊れやすい手順です:(

正しい方向への良い停止のように見える@sheerunに感謝します。 次のエラー処理は現時点では最適ではないことに同意します。エラー処理などを追加できるように、拡張可能なモジュール/ミドルウェアが追加されているのを見るのは素晴らしいことです。

歩哨などの同形ライブラリがないため、事態は複雑になっています。つまり、コンポーネントにどちらのライブラリも単純にインポートできないため、実行時に動的にインポートして、サーバー側またはブラウザ側でエラーが発生したかどうかを常に確認する必要があります。

この問題の更新はありますか？ これまでに試したことは次のとおりです。すべてのトラッキングコードを_app.jsに移動しました

constructor(args: any) {
        super(args)
        Sentry.init({
            dsn: 'blah',
            environment: 'local',
        })
        Sentry.configureScope(scope => {
            scope.setTag('errorOrigin', isServer ? 'SSR' : 'Client')
        })
    }

    static async getInitialProps({ Component, router, ctx }: any) {
        let pageProps = {}

        try {
            if (Component.getInitialProps) {
                pageProps = await Component.getInitialProps(ctx)
            }
        } catch (error) {
            // console.log('we caught an error')
            console.log(error)
            Sentry.captureException(error)
            throw error
        }

        return { pageProps }
    }

@sheerunからのnext.config.jsの追加と、server.jsでの歩哨の初期化と組み合わせてif (!isServer) { config.resolve.alias['@sentry/node$'] = '@sentry/browser' }
これは、クライアント側のすべてのエラーを追跡しているように見えますが、サーバー側では、サーバーの再起動後に発生した最初のエラーのみを追跡しているようです。 ただし、サーバー上のそれ以降のエラーは追跡されません。 このアプローチでは、ログにSyntheticErrorsはありませんが、実際のエラーのみがあります。

それでも、これは私にはかなりハッキーだと感じます。サーバー側の追跡は初めて機能するだけなので、まだ使用できません。

with-Sentryの例からこの部分も追加しました

    componentDidCatch(error: any, errorInfo: any) {
        // if (process.env.FIAAS_NAMESPACE !== undefined) {
        Sentry.configureScope(scope => {
            Object.keys(errorInfo).forEach(key => {
                scope.setExtra(key, errorInfo[key])
            })
        })
        Sentry.captureException(error)
        console.log('componentDidCatch')

        // This is needed to render errors correctly in development / production
        super.componentDidCatch(error, errorInfo)
        // }
    }

しかし、これが必要かどうかは完全にはわかりません

私の場合、問題なく動作します。 また、あなたは歩哨を初期化しないでください
_app.jsコンストラクターですが、完全にこのクラスの外にあります

2時53分PMで水曜日、2018年11月21日にはabraxxas [email protected]書きました：

この問題の更新はありますか？ 私がこれまでに試したことは次のとおりです。
すべての追跡コードを_app.jsに移動しました

`
コンストラクター（引数：任意）{
super（args）
Sentry.init（{
dsn： '何とか'、
環境： 'ローカル'、
}）
Sentry.configureScope（scope => {
scope.setTag（ 'errorOrigin'、isServer？ 'SSR'： 'クライアント'）
}）
}

static async getInitialProps（{Component、router、ctx}：any）{
pageProps = {}

try {
    if (Component.getInitialProps) {
        pageProps = await Component.getInitialProps(ctx)
    }
} catch (error) {
    // console.log('we caught an error')
    console.log(error)
    Sentry.captureException(error)
    throw error
}

return { pageProps }

}

`

@sheerunからのnext.config.jsの追加と組み合わせて
https://github.com/sheerunおよびserver.jsでの歩哨の初期化も
（！isServer）{config.resolve.alias ['@セントリー/ノード$'] = '@ sentry / browser'}
これはクライアント側ではすべてのエラーを追跡しているようですが、サーバー側では
再起動後に発生する最初のエラーのみを追跡しているようです。
サーバ。 ただし、サーバー上のそれ以降のエラーは追跡されません。 これとともに
アプローチログにSyntheticErrorsはありませんが、実際のエラーのみがあります。

それでも、これは私にはかなりハッキーだと感じます。サーバー側の追跡は
初めて動作する場合のみ、まだ使用できません。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/zeit/next.js/issues/1852#issuecomment-440668980 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAR2DeIhoOj6PdWRA2VqiEZyrO5Jui8vks5uxVrHgaJpZM4NOQlp
。

私はすでにそれを移動しようとしましたが、それでも同じ動作です。 @sheerunセットアップの最小限の要点を投稿できますか？ 提供されたスニペットを使用して設定しようとしましたが、機能しません。 全体が非常に複雑に見えるので、私はかなり単純なタスクであると期待していました:(サーバーで歩哨を初期化していますか、それともクラス外の_app.jsでのみ初期化していますか？

公式の歩哨の例を更新しますが、「複雑すぎる」として拒否されるのではないかと思いますが、時間があれば投稿を試みることができます。

@sheerun公式の例に更新しようとしても、非常に価値があります。 SyntheticErrorsなしでsentryssrを動作させるため、または発生した最初のサーバーエラーのみを記録するために必要な最小限の複雑さであれば、マージされると思います。 次に、そこから、それを改善する方法、またはnextjsコアの改善または歩哨同型サポートを推進する方法を見つけることができます。

ここに行きます..https：//github.com/zeit/next.js/pull/5727

必然的に複雑な実例ができたので、状況を改善するための次のステップは何ですか。

• 未解決の歩哨の問題を検討します（何か欠けていますか？）：
  https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment -442778751
  https://github.com/getsentry/sentry-javascript/issues/1622
  https://github.com/getsentry/sentry-javascript/issues/951
• @sheerunは、サーバーとアプリのプラグインを作成するnext.jsサポートが役立つ可能性があると述べています。 どこかに焦点を当てたフィーチャーチケットはありますか？
• nextjsチームは、エラーを簡単に解決する方法を支援できます。
  https://github.com/zeit/next.js/issues/1852#issuecomment -337573921
  https://github.com/zeit/next.js/issues/1852#issuecomment -427124032

next.jsで必要なのは、next.config.jsにカスタムミドルウェアを追加する機能と、ユニバーサル（同形）プラグイン構成用のnext.browser.jsなどです（next.config.jsは、特にWebpack構成に使用されます。つまり、このファイルで定義されている他のものは、循環依存を引き起こすため、アプリケーションコードでは使用できません）。

next.browser.jsの場合、next.jsは、アプリまたはドキュメントコンポーネントのデコレータのような構成を定義できます。 このようにして、歩哨統合を完全にプラグインとして実装できました。

編集：これのチケットがあるかどうかはわかりませんが、 @ timneutkensはすでに次のサーバーを別のパッケージに抽出していると思います。 最高のプラグインインターフェースは次のようなものになると思います。

module.exports = {
  server: server => {
    server.use(Sentry.Handlers.errorHandler())
  }
}

そのようなAPIの提案を＃6922で実装しました

コントラクトが.listen()自動的に呼び出さないものに変更されるため、カスタムサーバーコードにデコレータを追加できるため、next.jsでインスタンス化する前にさらにデコレータを作成できます。

with-sentry例を使用するのに多くの問題があったので、もっと簡単な例のPRを開きました。 それはすべての鐘と笛を持っているわけではありませんが、それは私のために働いています。

https://github.com/zeit/next.js/pull/7119

カスタム_document.jsこれを試してください：

import React from "react";
import Document, {
  Html,
  Head,
  Main,
  NextScript,
} from "next/document";
import { NodeClient } from "@sentry/node";

const { default: getConfig } = require("next/config");
const { publicRuntimeConfig: { sentryDSN } } = getConfig();

let sentry = null;
if (sentryDSN) {
  sentry = new NodeClient({ dsn: sentryDSN });
}

export default class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx);
    if (ctx.err && sentry) sentry.captureException(ctx.err);
    return { ...initialProps };
  }

  render() {
    return (
      <Html>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

そしてこれはカスタム_app.js ：

import * as Sentry from "@sentry/browser";

const { default: getConfig } = require("next/config");
const { publicRuntimeConfig: { sentryDSN } } = getConfig();

if (sentryDSN) {
  Sentry.init({ dsn: sentryDSN });
}

それはわたしを助ける。

Tbh私はnext.jsのエラーをキャッチする正しい場所が今何であるかについて非常に混乱しています。 _app.tsx、_error.tsx、および_document.tsxがあり、いくつかのものを_error.tsxに取り込む必要があるというコメントがあります（https://github.com/zeit/next.js/pull/5727/filesなど）。 ＃r235981700）ただし、現在の例では_app.tsxまたは_appと_documentのいずれかを使用しています。

私は今両方の方法を試しましたが、ssr中に発生するいくつかのエラーが私に捕らえられていないようです。 エラーをチェックするのに正しい場所はどこですか？ 私にとって最も論理的なものは、_appのcomponentDidCatchと_errorのgetInitialPropsをチェックインするようです。これは、エラーの場合に提供されるためです。 _documentのprocess.on部分全体について少し混乱しています

より深い知識を持っている人がこの質問を解決してくれませんか？

@abraxxas process.onで_document.js 、サーバー上で起こるエラーをキャッチされました。 要約すると、

• _document.jsは_サーバー側のみ_であり、サーバー側でレンダリングされた最初のドキュメントマークアップを変更するために使用されます。
• _app.jsは_クライアント側のみ_であり、ページの初期化に使用されます。

したがって、サーバーでエラーが発生すると、 process.onを介してSentryにエラーがスローされ、クライアントはデフォルトのエラーページまたは_error.jsをレンダリングします。

うまくいけば、これが役立つでしょう： https ：

_app.jsはクライアント側のみではありませんが、 componentDidCatchは

@timneutkensさて、それは私の脳を少ししわにします。 前回見た時からドキュメントが更新されて_app.jsがクライアントサイドではないことを詳しく説明していただけますか？

@timneutkensおそらく、どこで、なぜエラーをキャッチするのか説明できますか？ たくさんの意見があるようです。

@timneutkensさて、それは私の脳を少ししわにします。 前回見た時からドキュメントが更新されて_app.jsがクライアントサイドではないことを詳しく説明していただけますか？

こんにちはリーロブ！
あなたの例のマージリクエストについて質問を投稿しました：
https://github.com/zeit/next.js/pull/7360#issuecomment -514318899

その質問に加えて...私はサーバー側のrender（）でエラーをスローしようとしました（raiseErrorInRender：trueで状態を開始したので、サーバー側の最初のレンダリングはすでにエラーをスローします）、そしてそのエラーもSentryによってキャプチャされませんでした。

アプリケーションでそれをテストしましたか？それらのサーバー側のエラーは実際にキャプチャされていますか？ Next9を使用しています。

それが実際に当てはまり、クライアント側のエラーのみがキャプチャされている場合は、_document.jsファイルをオーバーライドする理由もありません。

助けてくれてありがとう！

@timneutkensさて、それは私の脳を少ししわにします。 前回見た時からドキュメントが更新されて_app.jsがクライアントサイドではないことを詳しく説明していただけますか？

質問に答えると、_appは、ページを初期化するためにAppコンポーネントが定義されている場所です。 ページ変更の間に永続的なレイアウトが必要な場合（すべてのページが同じ_appを利用する）、またはreduxを利用する場合など、これをオーバーライドします。 したがって、サーバー側で発生する最初のレンダリングでさえ、_appのコンテンツをレンダリングします（クライアント側のみではありません）。

その質問に加えて...私はサーバー側のrender（）でエラーをスローしようとしました（raiseErrorInRender：trueで状態を開始したので、サーバー側の最初のレンダリングはすでにエラーをスローします）、そしてそのエラーもSentryによってキャプチャされませんでした。

そのエラーを歩哨に表示させるために他の方法で管理しましたか？ _errorのgetInitialPropsでキャプチャしようとしましたが、歩哨では何も表示されません。 現在、サーバー上のエラーをキャプチャする信頼できる方法を1つ見つけていません。そのうちのいくつかは（ほとんどの場合、API障害に接続されている場合）表示されますが、エラーテストページから単純なエラーを取得して歩哨に表示することはできませんでした。

その質問に加えて...私はサーバー側のrender（）でエラーをスローしようとしました（raiseErrorInRender：trueで状態を開始したので、サーバー側の最初のレンダリングはすでにエラーをスローします）、そしてそのエラーもSentryによってキャプチャされませんでした。

そのエラーを歩哨に表示させるために他の方法で管理しましたか？ _errorのgetInitialPropsでキャプチャしようとしましたが、歩哨では何も表示されません。 現在、サーバー上のエラーをキャプチャする信頼できる方法を1つ見つけていません。そのうちのいくつかは（ほとんどの場合、API障害に接続されている場合）表示されますが、エラーテストページから単純なエラーを取得して歩哨に表示することはできませんでした。

残念ながら違います。 私が実装しようとしている解決策は、テンプレートとして例（オーバーライドされた_document.jsファイルを除く）を使用して、クライアント側で発生するエラーをキャプチャすることです。ユーザーが私に報告しない限り、知っています。 サーバー側では、ログ行をログファイルに直接リダイレクトするだけだと思います。 すべてのエラーを同じ場所に置きたかったので、これは間違いなく最善の解決策ではありませんが、そうすることで、少なくともアプリケーションで発生する可能性のあるエラーに関する情報を得ることができます。

あなたはそれをどう思いますか？ ありがとう！

その質問に加えて...私はサーバー側のrender（）でエラーをスローしようとしました（raiseErrorInRender：trueで状態を開始したので、サーバー側の最初のレンダリングはすでにエラーをスローします）、そしてそのエラーもSentryによってキャプチャされませんでした。

そのエラーを歩哨に表示させるために他の方法で管理しましたか？ _errorのgetInitialPropsでキャプチャしようとしましたが、歩哨では何も表示されません。 現在、サーバー上のエラーをキャプチャする信頼できる方法を1つ見つけていません。そのうちのいくつかは（ほとんどの場合、API障害に接続されている場合）表示されますが、エラーテストページから単純なエラーを取得して歩哨に表示することはできませんでした。

残念ながら違います。 私が実装しようとしている解決策は、テンプレートとして例（オーバーライドされた_document.jsファイルを除く）を使用して、クライアント側で発生するエラーをキャプチャすることです。ユーザーが私に報告しない限り、知っています。 サーバー側では、ログ行をログファイルに直接リダイレクトするだけだと思います。 すべてのエラーを同じ場所に置きたかったので、これは間違いなく最善の解決策ではありませんが、そうすることで、少なくともアプリケーションで発生する可能性のあるエラーに関する情報を得ることができます。

あなたはそれをどう思いますか？ ありがとう！

それはまさに私たちが今していることです、それは少し不格好ですが、私たちが思いつくことができる最高のものです。 しかし、サーバー側のエラーの一部が歩哨に表示されるため、歩哨またはnext.jsのいずれかで何かが起こっているに違いないと思います。 単純な例とより複雑な例の両方を試してみましたが、どちらも同じように動作するため、この動作はセットアップとは関係がないことを少なくともある程度確信しています。

このスレッドの人々は、 https：//github.com/zeit/next.js/pull/8684および関連するバグに興味があるかもしれません。 未処理の例外の12の異なるテストがあり、Next.jsが処理する例外と処理しない例外を理解するために、さまざまなテストを行うことができます。

この問題に関するニュースはありますか？

私の解決策は、 reduxを使用して、ノードフェッチデータエラーをstate redux保存することです。次に、 _app.jsのcomponentDidMountで、何かを実行します（ユーザーへのアラートまたはエラー後の要求バックエンドへ）。
コードはnext-antd-scaffold_server-errorにあります。

========>状態

import {
  SERVER_ERROR,
  CLEAR_SERVER_ERROR
} from '../../constants/ActionTypes';

const initialState = {
  errorType: []
};

const serverError = (state = initialState, { type, payload }) => {
  switch (type) {
    case SERVER_ERROR: {
      const { errorType } = state;
      errorType.includes(payload) ? null : errorType.push(payload);
      return {
        ...state,
        errorType
      };
    }
    case CLEAR_SERVER_ERROR: {
      return initialState;
    }
    default:
      return state;
  }
};

export default serverError;

=======>アクション

import {
  SERVER_ERROR
} from '../../constants/ActionTypes';

export default () => next => action => {
  if (!process.browser && action.type.includes('FAIL')) {
    next({
      type: SERVER_ERROR,
      payload: action.type 
    });
  }
  return next(action);
};

=======> _app.js

...
componentDidMount() {
    const { store: { getState, dispatch } } = this.props;
    const { errorType } = getState().serverError;
    if (errorType.length > 0) {
      Promise.all(
        errorType.map(type => message.error(`Node Error, Code：${type}`))
      );
      dispatch(clearServerError());
    }
  }
...

https://github.com/zeit/next.js/issues/1852#issuecomment -353671222のおかげで、サーバー側のロールバーエラーレポートを使用した

_unortodox_ソリューションが大好きです

function installErrorHandler(app) {
  const _renderErrorToHTML = app.renderErrorToHTML.bind(app)
  const errorHandler = rollbar.errorHandler()

  app.renderErrorToHTML = (err, req, res, pathname, query) => {
    if (err) {
      errorHandler(err, req, res, () => {})
    }

    return _renderErrorToHTML(err, req, res, pathname, query)
  }

  return app
}
// ¯\_(ツ)_/¯

404エラーの場合はerr引数がnullになるため、このメソッドは404エラーには適用できません。

Elastic APMノードクライアント（https://www.npmjs.com/package/elastic-apm-node）でこれを解決しました

興味のある方へ：

next.config.js ：

webpack: (config, { isServer, webpack }) => {
      if (!isServer) {
        config.node = {
          dgram: 'empty',
          fs: 'empty',
          net: 'empty',
          tls: 'empty',
          child_process: 'empty',
        };

        // ignore apm (might use in nextjs code but dont want it in client bundles)
        config.plugins.push(
          new webpack.IgnorePlugin(/^(elastic-apm-node)$/),
        );
      }

      return config;
} 

次に、 _error.jsレンダリング関数でcaptureErrorを手動で呼び出すことができます。

function Error({ statusCode, message, err }) {

const serverSide = typeof window === 'undefined';

  // only run this on server side as APM only works on server
  if (serverSide) {
    // my apm instance (imports elastic-apm-node and returns  captureError)
    const { captureError } = require('../src/apm'); 

    if (err) {
      captureError(err);
    } else {
      captureError(`Message: ${message}, Status Code: ${statusCode}`);
    }
  }

}

やあみんな！ Expressサーバーを追加せずにNext.jsでExpressスタイルアーキテクチャ用のNPMライブラリを起動しました。 サーバーのエラー処理の課題に役立つ場合があります。 興味のある方は是非チェックしてみてください。 https://github.com/oslabs-beta/connext-js

getServerSidePropsで発生する例外をキャッチ（および処理）することに成功した人はいますか？

getServerSidePropsで発生する例外をキャッチ（および処理）することに成功した人はいますか？

不明確ですが、フレームワークはクライアントとサーバーの両方でエラーをログに記録する慣用的な方法を提供すると思います🤷‍♂️

getServerSidePropsで発生する例外をキャッチ（および処理）することに成功した人はいますか？

@stephankaag

はい、このようなものが私のために働いた：

まず、クラッシュレポートを処理するミドルウェアを作成します。 Sentryを返すだけでは機能しないため、 SentryをCrashReporterクラスにラップしました（つまり、 req.getCrashReporter = () => Sentry ）。

// crash-reporter.js

const Sentry = require("@sentry/node");

class CrashReporter {
  constructor(){
    Sentry.init({ dsn: process.env.SENTRY_DSN });
  }
  captureException(ex){
    return Sentry.captureException(ex);
  }
}

function crashReporterMiddleware(req, res, next) {
  req.getCrashReporter = () => new CrashReporter();
  next();
}

module.exports = crashReporterMiddleware;

次に、もちろん、Next.jsリクエストハンドラーが設定される前に、ミドルウェアをアプリにロードします。

// server.js

const crashReporterMiddleware = require("./middleware/crash-reporter")

...

app.use(crashReporterMiddleware);

...

setHandler((req, res) => {
  return handle(req, res);
});

その後、どこに電話してもgetServerSideProps ：

// _error.js

export async function getServerSideProps({req, res, err}) {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404;
  const crashReporter = req.getCrashReporter();
  const eventId = crashReporter.captureException(err);
  req.session.eventId = eventId;
  return {
    props: { statusCode, eventId }
  }
}