Sentry-javascript: [@sentry/node] AWS Lambda 및 기타 서버리스 솔루션 지원

이것은 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 지금은 getCurrentHub 라고 합니다. API를 다른 언어 SDK와 통합해야 했기 때문입니다.

@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 또한 문서에 다음과 같이 명시되어 있습니다.

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에서 이 작업을 수행할 수 있는 방법을 갖는 것이 중요하다고 생각합니다. Lambda는 배포 대상이 점점 더 많아지고 있습니다.

이것은 현재 최신 버전으로 업그레이드하는 것을 차단하고 있습니다...

개인적으로 오류를 보고할 때 약속/콜백을 받을 수 있는 것을 선호합니다. 나중에 실제로 닫지 않고 대기열을 비울 수있는 방법이 있으면 차선책이 될 것입니다 ...

captureException 에서 콜백을 제거한 이유는 무엇입니까?

@albinekb 다음 줄을 제거하면 전혀 작동하지 않습니다

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

@LinusU 솔루션이 무엇이며 센트리 또는 레이븐 솔루션을 사용하고 있습니까?

나에게 기본적으로 다음은 sentry/node @4.3.0 와 함께 작동하지만 람다가 센트리가 필요한 작업을 수행할 때까지 일정 시간(이 경우 2초)을 수동으로 기다리게 해야 합니다. Sentry가 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에서 이것에 대해 불타고 있습니다. 우리는 새로운 libs로 시작했고 Raven으로 돌아갈 것을 고려하면서 완전히 상자에서 벗어났습니다. 우리는 지금 허브를 닫고 다시 초기화하기 위해 테스트를 작성하고 있습니다. 허브에 물이 남아 있는 경우 실행 가능한 해결 방법이 될 것입니다. 그러나 여전히 해키/로드 시 문제를 일으킬 가능성이 있습니다.

개인적으로 나는 약속을 반환하는 일종의 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)
  }
})

그런 다음 스칸디움 을 사용하여 Express 앱을 Lambda에 배포합니다.

편집: 이것은 Raven "raven": "^2.6.3", 입니다.

드림 API는 이렇겠죠 😍

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

@LinusU https://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))

모든 큐잉과 버퍼링을 건너뛰려면...

나는 디자인이 "fire and forgot"에 맞춰져 있고 장기 실행 서버에서 실행된다는 것을 알았습니다. 버퍼링 등을 많이 하기 때문에 아마도 꽤 좋을 것입니다. 문제는 이것이 정반대라는 것입니다. 점점 더 보편화되고 있는 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 호출은 버퍼에 추가합니다. 맞습니다. 하지만 어떤 식으로든 큐에 넣지 않고 즉시 실행되며 이 패턴은 모든 것이 Sentry로 성공적으로 전송되었습니다.

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가 큰 충돌 없이 중단되지 않는다고 보장되나요? ❤️

@kamilogorek 웹 사이트의 문서에서 getCurrentHub()를 찾을 수 없습니다. 이 API는 큰 충돌 없이 중단되지 않는다고 보장됩니까? ❤️

예, 보장됩니다. 여기에 설명된 @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. 적어도 공식적으로 문서화 된 것이 있으면 좋을 것입니다. Serverless는 2019년 현재 빠르게 성장하고 있습니다. Sentry의 공식 지원을 정말 보고 싶습니다. 여기에서 읽고 정말 마음에 들었던 아이디어 중 하나는 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 와 정확히 같습니다.

2000ms 후에 대기열에 여전히 물건이 있으면 false 로 약속이 해결됩니다.
그렇지 않으면 close 는 시간 초과에 도달하기 전에 대기열이 비워지면 true 로 해결됩니다.

아니면 모든 약속이 해결되기 전에 컨테이너가 재사용됩니까? (그건 상상도 못함)

@HazAT 는 close(...) 이 클라이언트를 다시 사용하지 못하게 하는 문제가 아닌가요? Lambda는 동일한 Node 프로세스를 재사용하므로 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/Node에서는 close 라는 이름이 클라이언트와 아무 관계가 없으며 나중에 계속 사용하는 것이 좋습니다.

편집: 그것이 실제로 "문제"였다면 이를 명확히 하기 위해 문서를 업데이트하겠습니다.

시원한. 그러나 문서가 잘못되었습니다.

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

좋습니다. 우리는 이 문제를 팀 내부에서 논의했습니다.
여러분이 옳았고 지금 JavaScript는 우리가 문서화한 방식으로 작동하지 않지만 🙈 여러분이 기대하는 것과 정확히 일치하는 flush 함수를 소개할 것입니다.

따라서 지금 당장은 아무 문제 없이 close 를 사용할 수 있습니다(향후 클라이언트를 삭제/비활성화하기 위해 변경할 것인지 확실하지 않음).
하지만 flush 함수는 _just_ 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 Functions와 함께 사용하고 있지만 이론은 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로 가득 차 있습니다 😅

가능한 모든 솔루션에 감사드립니다. 여기 와주신 모든 분들께 감사드립니다.

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);

도 ~not~ 나를 위해 일하고 있습니다.

@tanduong 재현 케이스를 제공할 수 있습니까? 효과가 없다고 말하는 것만으로는 도움이 되지 않습니다 😂

@kamilogorek 사실, 나는 그것을 방금 알았다.

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

내 람다 함수가 VPC에 연결되어 있기 때문에 작동하지 않습니다.

나는 그것을 확인한다

await Sentry.flush(2000);

실제로 작동하고 있습니다.

BTW, 그러면 VPC에서 람다를 어떻게 처리할까요? NAT 게이트웨이에 연결하시겠습니까? 나는 단지 Sentry를 원하지만 공용 인터넷은 원하지 않습니다.

@tanduong Sentry는 공용 인터넷에 있으므로 람다가 VPC 내에서 실행되는 경우 NAT 게이트웨이가 있어야 합니다. 그렇지 않으면 호스팅된 Sentry 옵션을 탐색해야 합니다.

flush(2000) 은 실제로 무엇을 하고 있습니까? 이 코드는 대부분 잘 작동했지만 지금은 몇 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); 를 병렬로 호출하면 첫 번째 약속만 해결됩니다. 이는 핸들러에 대한 여러 동시 호출 사이에서 클라이언트가 재사용되는 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');
  }

그러나 빠르게 람다 함수를 두 번 호출하면 다음과 같은 결과가 나타납니다.

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

두 번째 약속은 절대 해결되지 않는 것을 볼 수 있습니다.

@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 메소드의 콜백이 하나 있는데 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);
     }
});

무슨 일이야?
호출 사이의 짧은 간격으로 함수가 여러 번 호출되면 이벤트는 한 번만 기록됩니다.
호출 사이의 시간 간격이 더 크면 모든 이벤트가 기록됩니다.

호출이 재사용된 컨테이너에 대해 문제가 있다고 가정합니다.

나는 또한 시도했다
await Sentry.captureException(error);
그리고:
await Sentry.flush();
그리고 플러싱 없이
같은 결과

@marshall-lee 무엇을 추천하시나요? 문제를 만들면 여기에서 멈춥니다.

@armando25723 이 이벤트를 보내는 동안 서버가 429(예외가 너무 많음)로 응답하는 것 같습니다. 할당량/속도 제한 시나리오를 초과하는 경우 이를 던집니다. 순차적으로 오류를 보내는지 아니면 할당량을 초과하는지 알고 있습니까? 이것이 실제 오류 이벤트가 삭제되고 프리 티어에 대한 5k 제한 미만이라고 생각하는 경우 추가로 디버그할 수 있습니다.

@ajjindal 다른 모든 프로젝트는 sentry와 잘 작동합니다. 조직 슬러그는 "alegra"이고 프로젝트 이름은 #mail-micros 아래의 mail-dispatch-serverless입니다. 우리는 오랫동안 센트리를 사용해 왔지만 서버리스는 처음입니다. 이것은 프리 티어가 아니므로 정확히 어떤 플랜을 사용하고 있는지 말씀드릴 수는 없지만 유료입니다.
더 디버깅하는 데 도움이 된다면 좋을 것입니다.
답변 감사합니다 : )

PD: 팀플랜