Sentry-javascript: [@ sentry / node] AWSLambdaおよびその他のサーバーレスソリューションのサポート

これは私がhttps://blog.sentry.io/2018/06/20/how-droplr-uses-sentry-to-debug-serverlessを推測するのに役立つかもしれません（コールバックがあった古いレイヴンバージョンを使用していますが、私は主にcallbackWaitsForEmptyEventLoopフラグを指しています。

まだベータ版で試しているため、正式な方法はまだありませんが、次のコードで実行できます。

import { init, getDefaultHub } from '@sentry/node';

init({
  dsn: 'https://my-dsn.com/1337'
});

exports.myHandler = async function(event, context) {
  // your code

  await getDefaultHub().getClient().captureException(error, getDefaultHub().getScope());
  context.fail();
}

@kamilogorekポインタありがとうございます。 試してみて、学んだことを再生します。

@kamilogorekあなたの提案はうまくいきます。 もっと公式な方法を楽しみにしています。

@vietbui
4.0.0-rc.1では、 closeという関数をクライアントに導入しました。これは、次のように呼び出します。

import { getCurrentHub } from '@sentry/node';

getCurrentHub().getClient().close(2000).then(result => {
      if (!result) {
        console.log('We reached the timeout for emptying the request buffer, still exiting now!');
      }
      global.process.exit(1);
})

closeは、すべてのリクエストが送信されるまで待機し、タイムアウトに達するまで（この例では2000ms）、常に解決します（結果= falseタイムアウトに達しました）。
これは私たちの公式APIです。
前のアプローチは引き続き機能しますが、 closeメソッドはすべての場合に機能します。

@HazATいいね。 大変お世話になりました。

4.0.3では、ラムダ関数で次のように呼び出します。

try {
  ...
} catch (err) {
  await getCurrentHub().getClient().captureException(err, getCurrentHub().getScope())
  throw err
}

getDefaultHub（）は使用できなくなりました。

@vietbui APIを他の言語のSDKと統合する必要があったため、現在はgetCurrentHubと呼ばれています。

@kamilogorek説明してくれてありがとう。 getCurrentHubアプローチには問題があります。どういうわけか、私が設定したスコープがSentryに到達しなかったためです。

結局、ラムダ関数で例外をキャプチャするために、 @ HazATによって提案された別のアプローチを採用しました。

try {
  ...
} catch (err) {
  Sentry.captureException(err)
  await new Promise(resolve => Sentry.getCurrentHub().getClient().close(2000).then(resolve))
  throw err
}

そしてそれは完璧に機能します。

これは、歩哨がイベントを送信するのを待つ/強制するための推奨される方法ですか？

@albinekbはい– https://docs.sentry.io/learn/draining/?platform=browser

@albinekbはい– https://docs.sentry.io/learn/draining/?platform=browser

この解決策は、何らかの理由で私には機能しません。 コールドスタート時間が存在する場合にのみ本番環境で初めて機能し、それ以降は機能しません。 これがサンプルコードです

'use strict'

const Sentry =  require('@sentry/node')
Sentry.init({
  dsn: 'xxx',
  environment: process.env.STAGE
});

module.exports.createPlaylist = async (event, context, callback) => {
  context.callbackWaitsForEmptyEventLoop = false
  if(!event.body) {
    Sentry.captureException(error)
    await new Promise(resolve => Sentry.getCurrentHub().getClient().close(2000).then(resolve))
    return {
      statusCode: 500,
      headers: { 'Content-Type': 'text/plain' },
      body: 'Missing body parameters'
    }
  }
  return {
    statusCode: 200,
  }
};

@ Andriy-Kulak Thatsもドキュメントに記載されています：

After shutdown the client cannot be used any more so make sure to only do that right before you shut down the application.

したがって、アプリケーションがいつ強制終了されるかわからないラムダでこれをどのように処理できるかわかりません。 古いAPIの場合と同じように、リクエストごとに歩哨を排出するのが最善でしょうか。

@HazATこれを再開してもらえますか？ 展開するターゲットがますます一般的になっているLambdaでこれを処理する方法を用意することが重要だと思います。

これにより、現在、最新バージョンへのアップグレードがブロックされています...

個人的には、エラーを報告するときにPromise /コールバックを取得できるようにしたいと思います。 後で実際にキューを閉じずにキューを空にする方法があると、次善の策になります...

captureExceptionからコールバックを削除する理由は何でしたか？

@albinekb次の行を削除すると、まったく機能しなくなります

await new Promise(resolve => Sentry.getCurrentHub().getClient().close(2000).then(resolve))

@LinusUあなたが使用している解決策と歩哨またはレイヴンの解決策は何ですか？

私の場合、基本的に次のようにsentry/node @4.3.0で動作しますが、ラムダを手動で一定時間（この場合は2秒）待機させて、歩哨が必要な処理を実行するようにする必要があります。 歩哨がcaptureExceptionリクエストを完了するのを待っているので、なぜそこにある必要があるのか​​わかりません。 その後待機期間がない場合、歩哨はエラーを送信していないようです。

'use strict'

const Sentry =  require('@sentry/node')
Sentry.init({
  dsn: 'xxx',
  environment: process.env.STAGE
});

module.exports.createPlaylist = async (event, context, callback) => {
  context.callbackWaitsForEmptyEventLoop = false
  if(!event.body) {
    const error = new Error('Missing body parameters in createPlaylist')
    await Sentry.captureException(error)
    await new Promise(resolve => {setTimeout(resolve, 2000)})
    return {
      statusCode: 500,
      headers: { 'Content-Type': 'text/plain' },
      body: 'Missing body parameters'
    }
  }
  return {
    statusCode: 200,
  }
};

Lambdaでもこれに火傷を負っています。 私たちは新しいライブラリから始め、レイヴンに戻ることを考慮して、完全にボックス化されています。 現在、ハブを閉じてから再初期化するためのテストを作成しています。これは、水を保持している場合に実行可能な回避策になります。 しかし、それでもハッキー/負荷の下で問題を引き起こす可能性があります。

個人的には、約束を返すようなflush()を好みますが、欠点を見つけるのは困難です。 それが起こると思いますか？

使用している解決策と歩哨またはレイヴンの解決策は何ですか？

次のエクスプレスエラーハンドラーを使用しています。

app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
  let status = (err.status || err.statusCode || 500) as number

  if (process.env.NODE_ENV === 'test') {
    return next(err)
  }

  if (status < 400 || status >= 500) {
    Raven.captureException(err, () => next(err))
  } else {
    next(err)
  }
})

次に、 scandiumを使用してExpressアプリをLambdaにデプロイしています

編集：これはレイヴンと一緒です"raven": "^2.6.3",

夢のAPIはこのようなものになります😍

Sentry.captureException(err: Error): Promise<void>

@LinusUhttps ： //github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L145-L152🙂

ただし、クライアントインスタンスを直接使用して取得する必要があります。 この理由は、メインシナリオが「ファイアアンドフォーゲット」タイプの動作であると判断したためです。したがって、これは非同期メソッドではありません。 ただし、内部的には、独自に使用する非同期APIがあります。

私が実際に欲しいのはもっと似ているようです：

const backend = client.getBackend()
const event = await backend.eventFromException(error)
await client.processEvent(event, finalEvent => backend.sendEvent(finalEvent))

すべてのキューイングとバッファリングをスキップするために...

デザインは「火をつけて忘れる」ように調整されており、長時間実行されるサーバーで実行するように調整されています。多くのバッファリングなどを行うので、おそらくそれはかなり良いでしょう。問題は、これが正反対であるということです。ますます一般的になりつつあるLambda、App Engine、およびその他の「サーバーレス」アーキテクチャに必要なものです。

イベントをできるだけ速く送信し、 awaitで可能なPromiseを返す特別なメソッドを持つことは可能でしょうか？ これは、サーバーレスシナリオに最適です。

class Sentry {
  // ...

  async unbufferedCaptureException(err: Error): Promise<void> {
    const backend = this.client.getBackend()
    const event = await backend.eventFromException(error)
    await this.client.processEvent(event, finalEvent => backend.sendEvent(finalEvent))
  }

  // ...
}

@LinusUは、このシナリオ用に特定のサーバーレスパッケージを作成する可能性があります。 今年の終わりで、物事は今混雑しているので、私たちは少し時間を見つける必要があります。 あなたを投稿し続けます！

ほとんどの場合、このシナリオ用に特定のサーバーレスパッケージを作成します

それは素晴らしいでしょう！ 😍

@ mtford90

いつこのより良いソリューションを使用しますか？ 私の知る限り、ラムダがいつシャットダウンされるかを知ることはできません。さらに、特に高価な高メモリ/ CPUラムダ関数では、シャットダウンを任意の時間待って歩哨がその処理を実行できるようにするのはばかげているようです。

（排水について話します）

これは、サーバープロセスを終了する前の最後のものとして使用することを目的としています。 drainメソッドのタイムアウトは、プロセスをシャットダウンする前に待機する最大時間です。これは、常にその時間を使い果たすことを意味するわけではありません。 サーバーが完全に応答する場合、残りのすべてのイベントをすぐに送信します。

これ自体を知る方法はありませんが、ハンドラーのコールバック引数を使用して、いつシャットダウンする必要があるかをラムダに通知する方法があります。

また、 @ LinusU 、私はあなたの以前のコメント、特にこの部分を読み直しました：

イベントをできるだけ速く送信し、私たちが待つことができるPromiseを返す特別なメソッドを持つことは可能でしょうか？ これは、サーバーレスシナリオに最適です。

これが私たちがバッファを実装した方法です。 クライアントでのすべてのcaptureX呼び出しは、それをバッファに追加します。これは正しいですが、キューに入れられることはなく、すぐに実行されます。このパターンは、すべてがセントリーに正常に送信されました。

https://github.com/getsentry/sentry-javascript/blob/0f0dc37a4276aa2b832da451307bc4cd5413b34d/packages/core/src/requestbuffer.ts#L12 -L18

これは、AWS Lambdaでこのようなことを行う場合（最も単純なケースであるデフォルトのクライアントを使用することを前提としています）を意味します。

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

Sentry.init({ dsn: '__YOUR_DSN__' });

exports.handler = (event, context, callback) => {
    try {
      // do something
    catch (err) {
      Sentry.getCurrentHub()
        .getClient()
        .captureException(err)
        .then((status) => {
          // request status
          callback(null, 'Hello from Lambda');
        })
    }
};

すぐに送信され、タイミング/処理のオーバーヘッドがなかったことを確認できます。

@kamilogorek
これは、このようなものが非同期/待機ハンドラー（コールバックを使用しない場合）で機能する必要があることを意味しますか？

import * as Sentry from '@sentry/node';

Sentry.init({ dsn: '__YOUR_DSN__' });

exports.handler = async (event, context) => {
    try {
      // do something

      return 'Hello from Lambda';
    catch (err) {
      await Sentry.getCurrentHub().getClient().captureException(err);
      return 'Hello from Lambda with error';
    }
};

@jviolas完全に！ :)

次の変更は私にとってはうまくいくようです☺️

-import Raven = require('raven')
+import * as Sentry from '@sentry/node'

 // ...

-Raven.config(config.SENTRY_DSN)
+Sentry.init({ dsn: config.SENTRY_DSN })

 // ...

 app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
   let status = (err.status || err.statusCode || 500) as number

   if (process.env.NODE_ENV === 'test') {
     return next(err)
   }

   if (status < 400 || status >= 500) {
-    Raven.captureException(err, () => next(err))
+    Sentry.getCurrentHub().getClient().captureException(err).then(() => next(err))
   } else {
     next(err)
   }
 })

正直なところ、すべての行が少し醜いです😆しかし、私はそれが内部でより良いと思います...

@kamilogorekあなたのウェブサイトのドキュメントでgetCurrentHub()を見つけることができませんでしたが、このAPIは、大きなsemverバンプなしで壊れないことが保証されていますか？ ❤️

@kamilogorekあなたのウェブサイトのドキュメントでgetCurrentHub（）を見つけることができませんでしたが、このAPIは、大きなsemverバンプなしで壊れないことが保証されていますか？ ❤️

はい、保証されています。 これは、ここで説明されている@sentry/hubパッケージの一部です-https：//docs.sentry.io/enriching-error-data/scopes/？platform = browser

このスレッドでは、ちょっとした「高度な使用法」について説明していますが、まだそれらを文書化するまでには至っていません。 最終的にこれを行います:)

明らかに、ここで欠落しているのは、この種の高度なユースケースにおけるいくつかのドキュメントとグッドプラクティスです。 それが文書化されるとき、あるいはブログ投稿でさえ良いスタートになるとき、それは本当に良いでしょう。
それ以外の場合、新しいSDKは非常に使いやすく、統合は非常に優れています。

@kamilogorek
これは、このようなものが非同期/待機ハンドラー（コールバックを使用しない場合）で機能する必要があることを意味しますか？

import * as Sentry from '@sentry/node';

Sentry.init({ dsn: '__YOUR_DSN__' });

exports.handler = async (event, context) => {
    try {
      // do something

      return 'Hello from Lambda';
    catch (err) {
      await Sentry.getCurrentHub().getClient().captureException(err);
      return 'Hello from Lambda with error';
    }
};

上記のように何かを行うことは、コンテキストを追加できないことを除いて、機能します。 たとえば、私がそうする場合：

Sentry.configureScope(scope => {
   scope.setExtra('someExtraInformation', information);
});
await Sentry.getCurrentHub().getClient().captureException(err);

Sentryには実際には「someExtraInformation」は表示されません。

誰かがこのスレッドの先頭で別の方法を提案しましたが、それは機能しますが、ハッキーなようです（タイムアウトを強制します）。

Sentry.configureScope(scope => {
  scope.setExtra('someExtraInformation', information);
});
Sentry.captureException(error);
await new Promise(resolve => Sentry.getCurrentHub().getClient().close(2000).then(resolve));

@kamilogorek @jviolas

import * as Sentry from '@sentry/node';

Sentry.init({ dsn: '__YOUR_DSN__' });

exports.handler = async (event, context) => {
   try {
     // do something

     return 'Hello from Lambda';
   catch (err) {
     await Sentry.getCurrentHub().getClient().captureException(err);
     return 'Hello from Lambda with error';
   }
};

これは_キャッチされていない例外_にも適用できますか？ Sentry.Integrations.OnUncaughtException統合を変更することが公式の方法のようですが、現在のところドキュメントはかなり貧弱です。

このために+1。 少なくとも公式に文書化されたものがあるとよいでしょう。 サーバーレスは2019年の時点で急速に成長しています。私は、Sentryからの公式サポートを本当に望んでいます。 私がここで読んで本当に気に入ったアイデアの1つは、キューに入れられているすべてのイベントを送信するためにSentry.flush()のようなものを用意することでした。

@rdsedmundoこのアプローチがうまくいかない理由を詳しく説明していただけますか？

import * as Sentry from '@sentry/node';

Sentry.getCurrentHub().getClient().close(2000).then(result => {
      if (!result) {
        console.log('We reached the timeout for emptying the request buffer, still exiting now!');
      }
      global.process.exit(1);
})

これは私たちの公式のアプローチであり、基本的にSentry.flush()です。
参照： https ：//docs.sentry.io/error-reporting/configuration/draining/？platform = javascript

@HazAT AWS Lambdaコンテナの再利用について考えると、この問題が発生します。 これは、TL; DRの用語では、リクエストを処理したばかりのプロセスが、短時間で行われた場合に新しいブランドのプロセスを処理できることを意味します。 あなたが提供したこのスニペットとの接続を閉じ、コンテナが再利用された場合、新しいリクエストのために新しいハブを作成する必要があります。 これがトリッキーになっているのが簡単にわかります。 そのため、単純なawait Sentry.flush()の方が優れたソリューションになります。

import Sentry from './sentry'; // this calls Sentry.init under the hood

export const handler = async (event, context) => {
  try {
    ...
  } catch (error) {
    Sentry.captureException(error);
    await Sentry.flush(); // could even be called on the finally block

    return formatError(error);
  }
}

@rdsedmundo何かを誤解しているのかどうかはわかりませんが、誤解している場合は

import Sentry from './sentry'; // this calls Sentry.init under the hood

export const handler = async (event, context) => {
  try {
    ...
  } catch (error) {
    Sentry.captureException(error);
    await Sentry.getCurrentHub().getClient().close(2000);

    return formatError(error);
  }
}

タイムアウトを定義することだけがawait Sentry.flushとまったく同じです。

キューにまだ何かが残っている場合、Promiseは2000ms後にfalseで確実に解決されます。
それ以外の場合、タイムアウトに達する前にキューが空になっていると、 closeはtrueで解決されます。

または、すべての約束が解決される前にコンテナが再利用されますか？ （私はそれを想像することはできません）

@HazATは、 close(...)がクライアントの再使用を妨げるという問題ではありませんか？ Lambdaは同じノードプロセスを再利用するため、呼び出しは次のようになります。これは、 closeへの最初の呼び出しの後で機能しなくなると思いますか？

• Sentry.init()
• Sentry.captureException()
• Sentry.getCurrentHub().getClient().close()
• Sentry.captureException()
• Sentry.getCurrentHub().getClient().close()
• Sentry.captureException()
• Sentry.getCurrentHub().getClient().close()
• Sentry.captureException()
• Sentry.getCurrentHub().getClient().close()
• ..。

いいえ、 closeはクライアントを破棄しません。これは、トランスポートキューを空にするためだけにあります。
このコンテキストでのcloseという名前は誤解を招く可能性があることに同意しますが、少なくともJS /ノードcloseはクライアントに対して何も行わないため、後で使用してもまったく問題ありません。

編集：それが実際に「問題」だった場合は、これを明確にするためにドキュメントを更新します。

涼しい。 しかし、ドキュメントは間違っています：

After shutdown the client cannot be used any more so make sure to only do that right before you shut down the application.

OK、チーム内でこの問題について話し合ったところです。
皆さんは正しかったです。JavaScriptは今のところ私たちが文書化したようには動作しませんが🙈私たちはあなたが期待することを正確に実行するflush関数を導入します。

したがって、現時点では問題なくcloseを使用できます（将来、クライアントを破棄/無効にするために変更するかどうかはわかりません）。
ただし、キューに_just_ flushするflush関数があります。

機能がリリースされたら、この問題を更新します。

これらのコメントのすべてで少し迷ったので、これはExpressエラーハンドラー（このリポジトリからのものを模倣する）がどのように見えるべきですか？

function getStatusCodeFromResponse(error) {
    const statusCode = error.status || error.statusCode || error.status_code || (error.output && error.output.statusCode);
    return statusCode ? parseInt(statusCode, 10) : 500;
}

app.use(async (err, req, res, next) => {
    const status = getStatusCodeFromResponse(err);

    if (status >= 500) {
        Sentry.captureException(err)

        await Sentry.getCurrentHub().getClient().close(2000)
    }

    next(err)
})

動作しているようで、 @ rreynierのコードのように余分なデータが失われることはありません。

個人的にはそう感じます

await Sentry.getCurrentHub().getClient().captureException(err)

よりクリーンです：

Sentry.captureException(err)
await Sentry.getCurrentHub().getClient().close(2000)

closeは、実際にはクライアントを閉じるように読み取られます...

完全な例：

import * as Sentry from '@sentry/node'

// ...

Sentry.init({ dsn: config.SENTRY_DSN })

// ...

app.use((err: any, req: express.Request, res: express.Response, next: express.NextFunction) => {
  let status = (err.status || err.statusCode || 500) as number

  if (process.env.NODE_ENV === 'test') {
    return next(err)
  }

  if (status < 400 || status >= 500) {
    Sentry.getCurrentHub().getClient().captureException(err).then(() => next(err))
  } else {
    next(err)
  }
})

@LinusU試してみましたが、何らかの理由で、スタックトレースとともに余分なデータが送信されません。 基本的にはスタックトレースだけを送信します。 ユーザーやOSなどに関する情報はありません。

ああ、それは全然良くない😞

flushを待つ間、上記の両方のオプションよりも信頼性の高い回避策として、レポートして結果を待つことができます。以下のスニペットを使用して、スコープを含めます。

const scope = Sentry.getCurrentHub().getScope();
await Sentry.getCurrentHub().getClient().captureException(error, scope);

私はこれを使用していますが、予想されるすべてのものを含むエラーが報告されており、確実に機能しているようです。

私は実際にこれらすべてをNetlify関数で使用していますが、理論はLambdaなどでも同じです。興味がある場合は、これを機能させる方法の詳細を記載した投稿を作成しました： https：// httptoolkit。 tech / blog / netlify-function-error-reporting-with-sentry /

現在、すべてのラムダでこのヘルパーを使用しています。

@pimterryこれは基本的に@LinusUが提案したのと同じ解決策ではありませんか？ 私はそれを試しましたが、余分なデータも送信しません。

このアプローチは、これまでのところ私にとってうまくいきました@ondrowan

@ondrowan同じですが、手動で現在のスコープを取得して含めます。 私は思うが、それはあなたが例外を機能させるのに十分なはずだ。 以前のバージョンでは、ラベルのないイベントが発生していましたが、この変更により、例外がすべての余分な通常の詳細で発生します。

@vietbui @albinekb @ Andriy-Kulak @LinusU @ dwelch2344 @jviolas @rreynier @guillaumekh @rdsedmundo @ondrowan @pimterry @zeusdeux誰がこのユースケースにまだ興味を持っているかわからないので、電話しないでください。

4.6.0から、 client/hubダンスはもうありません。 captureXメソッドを呼び出すだけで、 Sentry.flush()を使用して、すべてがサーバーに送信されたら応答を待つことができます。 すべてのスコープ/追加データは、開発者との対話なしで保持する必要があります。

成功した/タイムアウトしたリクエストの例を次に示します。

それが役に立てば幸い！ :)

良い！

Lambdaやその他のサーバーレスソリューションからの例外をキャプチャするためだけに最小限のパッケージを作成する計画はまだありますか？ それでも本当にいい追加になると思います❤️

@LinusUできればそうですが、現在、他の言語のSDKで溢れています😅

考えられるすべての解決策に感謝します。ここに来るすべての人にtl; dr

使用： await Sentry.flush()は、保留中のすべてのリクエストを送信します。これは4.6.xで導入されました。

これを閉じて、何かが足りない場合に備えて、新しい問題を開いてください（ただし、このスレッドはすでに非常に長いです）。

乾杯👍🎉

@kamilogorekねえ！ 簡単に言うと、古い回避策の代わりにアプリでSentry.flushを使用していますが、エラーは報告されていません。 現在、更新されたflushメソッドから古い回避策に戻っています。

@zeusdeuxは、このためのデバッグ情報/再現ケースを提供できる方法はありますか？
イベントをバッファに追加するcaptureExceptionメソッドをオーバーライドしているので、 flushの戻り値にawaitを追加する必要があります。 あなたはそれを「通常の方法」で使おうとしましたか？

@kamilogorekデバッグ情報があればいいのですが、ログに何もありません。 私は常にオーバーライドされたcaptureException awaitを実行しました。 通常の方法では、 captureExceptionをオーバーライドしないという意味ですか？

@zeusdeux正確には、オーバーライドなしでネイティブSentry.captureException(error)を呼び出すだけです。

したがって、ヘルパーは次のようになります。

import * as Sentry from '@sentry/node'

export function init({ host, method, lambda, deployment }) {
  const environment = host === process.env.PRODUCTION_URL ? 'production' : host

  Sentry.init({
    dsn: process.env.SENTRY_DSN,
    environment,
    beforeSend(event, hint) {
      if (hint && hint.originalException) {
        // eslint-disable-next-line
        console.log('Error:', hint.originalException);
      }
      return event;
    }
  })

  Sentry.configureScope(scope => {
    scope.setTag('deployment', deployment)
    scope.setTag('lambda', lambda)
    scope.setTag('method', method)
  })
}

そしてあなたがそれを呼ぶコードで：

import * as Sentry from '@sentry/node'

try {
  // ...
} catch (err) {
  Sentry.captureException(err);
  await Sentry.flush(2000);
  return respondWithError('Something went wrong', 500);
}

@kamilogorekやってみて、報告します。 また、 beforeSend ^ _ ^のヒントをありがとう

await Sentry.flush(2000);

また、私のために働いていません。

@tanduongリプロケースを提供できますか？ それが機能しないと述べるだけではあまり役に立ちません😅

@kamilogorek実際、私はちょうどそれを知りました

await Sentry.getCurrentHub().getClient().close(2000)

ラムダ関数がVPCにアタッチされているため、どちらも機能しません。

確認します

await Sentry.flush(2000);

実際に動作しています。

ところで、VPCでラムダをどのように処理しますか？ NATゲートウェイに接続しますか？ セントリーだけが欲しいのですが、公共のインターネットは欲しくありません。

@tanduong Sentryはパブリックインターネット上にあるため、ラムダがVPC内で実行されている場合は、NATゲートウェイが必要です。 それ以外の場合は、ホストされたセントリーオプションを検討する必要があります。

flush(2000)は実際に何をしているのですか？ このコードはほぼ正常に機能していましたが、今では2つのcaptureMessage呼び出しが同時に発生しており、毎回タイムアウトになっています。

有線でメッセージの内部キューをフラッシュする

わかりました、それは完全に理にかなっています。 私の問題は、フラッシュするものが他にないときにこの約束が二度と戻らないということだと思いますか？ ラップされcaptureException fnを同時に実行すると、ハンドラーがタイムアウトします。

export const captureMessage = async (
  message: string,
  extras?: any,
): Promise<boolean> =>
  new Promise((resolve) => {
    Sentry.withScope(async (scope) => {
      if (typeof extras !== 'undefined') {
        scope.setExtras(extras)
      }
      Sentry.captureMessage(message)
      await Sentry.flush(2000)
      resolve(true)
    })
  })

await Sentry.flush()は、最初のcaptureMessage呼び出しの後で実際には終了しません。

@enapupeと同様の問題だと思います。 await client.flush(2000);を並行して呼び出すと、最初のPromiseのみが解決されます。 これは、クライアントがハンドラーへの複数の同時呼び出しで再利用されるAWSラムダコンテキストで発生する可能性があります。

私は次のようなコードを使用しています：

 let client = Sentry.getCurrentHub().getClient();
  if (client) {
    // flush the sentry client if it has any events to send
    log('begin flushing sentry client');
    try {
      await client.flush(2000);
    } catch (err) {
      console.error('sentry client flush error:', err);
    }
    log('end flushing sentry client');
  }

しかし、ラムダ関数を2回続けて呼び出すと、次のようになります。

  app begin flushing sentry client +2ms
  app begin flushing sentry client +0ms
  app end flushing sentry client +2ms

2番目の約束が解決されないことがわかります。

@esetnik私はそれについて問題を提出しました： https ：//github.com/getsentry/sentry-javascript/issues/2131
私の現在の回避策は、（タイムアウトに基づいて）常に解決するラッパーフラッシュfnです。

const resolveAfter = (ms: number) =>
  new Promise((resolve) => setTimeout(resolve, ms))

const flush = (timeout: number) =>
  Promise.race([resolveAfter(timeout), Sentry.flush(timeout)])

@ enapupe ＃2131に回避策についてのメモを追加しました。 同時フラッシュでパフォーマンスが低下すると思います。

誰かが何か問題を抱えている場合に備えて。
これは美しく機能します

@SarasArya @HazAT
まず第一に...あなたのソリューションを共有してくれてありがとう！ :)
configureScopeメソッドのコールバックが1つあります。これは、captureExceptionの前に呼び出されるはずですが、同じ「スレッド」で実行されていません。
これは競合状態の出現につながる可能性がありますか？

@cibergarri私はそうは思いませんが、私には同期しているように見えます。そこに非同期メソッドがある場合は、競合状態が発生します。
ここで同じことが起こっているのは、配列の.mapのようなものだと考えてください。 頭を包むのに問題がある場合に備えて。 それがお役に立てば幸いです。

ええ、それをするのはまったく問題ありません

更新：Sentryは、Node / Lambda環境の自動エラーキャプチャをサポートするようになりました： https ：//docs.sentry.io/platforms/node/guides/aws-lambda/

私は次のように@sentry / serverlessを使用しています：

const Sentry = require("@sentry/serverless");
Sentry.AWSLambda.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 1.0,
  environment: appEnv
});

exports.main = Sentry.AWSLambda.wrapHandler(async (event, context) => {
     try{
           //my code
     }catch(error){
          Sentry.captureException(error);
          await Sentry.flush(3000);
     }

});

ラムダでは機能しません。
私のテスト環境では機能していましたが、同時実行が多く、コンテナーが再利用されている製品では、合計量の約10％しかログに記録されていません。

何かアドバイス？

@ armando25723

例外イベントが失われたことをどのように測定したか教えてください。 そのような失われた例外がどのようにスローされたかのコードサンプルはありますか？ より多くのコンテキストが必要です。

const Sentry = require("@sentry/serverless"); // "version": "5.27.3"
Sentry.AWSLambda.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 1.0,
  environment: appEnv
});
exports.main = Sentry.AWSLambda.wrapHandler(async (event, context) => {
     try{
           throw new Error('Test Error');
     }catch(error){
          Sentry.captureException(error);
          await Sentry.flush(3000);
     }
});

何が起こっている？
関数が呼び出しの間隔を短くして複数回呼び出された場合、イベントは1回だけログに記録されます。
呼び出し間の時間間隔が大きい場合、すべてのイベントがログに記録されます。

問題は、呼び出しが再利用されたコンテナに対して行われる場合だと思います。

私も試しました
await Sentry.captureException(error);
と：
await Sentry.flush();
フラッシングせずに
同じ結果

@ marshall-lee何をお勧めしますか？ 問題を作成した場合、私はここで立ち往生しています。

@ armando25723これらのイベントの送信中に、サーバーが429（例外が多すぎます）で応答しているようです。 クォータ/レート制限のシナリオを超えた場合にそれをスローします。 エラーを連続して送信しているのか、クォータを超えているのかを知っていますか？ これらが実際のエラーイベントがドロップされ、無料利用枠の5kの制限を下回っていると思われる場合は、さらにデバッグできます。

@ajjindal他のすべてのプロジェクトは歩哨でうまく機能しています。 組織のスラッグは「alegra」で、プロジェクト名は＃mail-microsの下のmail-dispatch-serverlessです。 私たちは長い間歩哨を使用してきましたが、サーバーレスで初めて使用しました。 これは無料利用枠ではありません。どのプランを使用しているか正確にはわかりませんが、有料プランです。
さらにデバッグするのを手伝っていただければ幸いです。
返信ありがとうございます:)

PD：チームプランです