8000 Issue titles from errors captured with `@sentry/aws-serverless` differ from `@sentry/node` · Issue #15788 · getsentry/sentry-javascript · GitHub
[go: up one dir, main page]
Skip to content

Issue titles from errors captured with @sentry/aws-serverless differ from @sentry/node #15788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
s1gr1d opened this issue Mar 24, 2025 · 5 comments
Closed

Issue titles from errors captured with @sentry/aws-serverless differ from @sentry/node #15788

s1gr1d opened this issue Mar 24, 2025 · 5 comments
Labels
AWS Lambda Improvement Stale

Comments

@s1gr1d
Copy link
Member
s1gr1d commented Mar 24, 2025

Description

Originally posted in this comment by @rowbot-weisguy

@relm923 good point. We use CDK so I've been bundling it using esbuild via aws-cdk-lib/aws-lambda-nodejs.

Today, given your advice, I set up a separate layer and marked express as an external module. It works! Warning is gone and I managed to get traces that I wanted to see from the lambda as long as I explicitly include the integrations I care about (e.g. expressIntegration, redisIntegration, and postgresIntegration).

I'm still noticing the generated issue titles (span names?) are a little unhelpful.

In development, using @sentry/node I see:

Image

Lovely! The path is so helpful to know immediately. Whereas in deployed lambdas, using @sentry/aws-serverless I see:

Image

So I tried implementing your suggestion @andreiborza:

// instrument.lambda.ts
import * as Sentry from "@sentry/aws-serverless";
import { nodeProfilingIntegration } from "@sentry/profiling-node";

import { env } from "./env";

Sentry.init({
  dsn: env.PILOT_API_SENTRY_DSN,
  defaultIntegrations: false,
  integrations: [
    ...Sentry.getDefaultIntegrations({}).filter(
      (integration) => !["Aws", "AwsLambda"].includes(integration.name),
    ),
    nodeProfilingIntegration(),
    Sentry.expressIntegration(),
    Sentry.redisIntegration(),
    Sentry.postgresIntegration(),
  ],
  environment: env.PILOT_API_SENTRY_ENVIRONMENT,
  tracesSampleRate: Number(env.PILOT_API_SENTRY_TRACING_SAMPLE_RATE),
  profilesSampleRate: Number(env.PILOT_API_SENTRY_PROFILING_SAMPLE_RATE),
});

export const wrapHandler = Sentry.wrapHandler;
This change made no visible difference to spans / names, and I'm not sure if there's a different way I should disable the Aws integration.

Image

Would love to make sure our Sentry issues are informative at a glance, so please let me know if there's something else I can do here. This is my first time instrumenting Sentry w/ Express & Lambda, so I have no experience with previous versions to share.
@s1 8000 gr1d s1gr1d mentioned this issue Mar 24, 2025
Closed
3 tasks
@s1gr1d
Copy link
Member Author
s1gr1d commented Mar 24, 2025

@rowbot-weisguy The @sentry/aws-serverless SDK sets the transaction name based on the function name we get from the AWS Lambda context (see code here).

That's the reason why the naming is different to the @sentry/node SDK which you are using in development mode. Does the naming resemble the AWS Lambda function name or is this not correct either?

@getsantry getsantry bot moved this to Waiting for: Community in GitHub Issues with 👀 3 Mar 24, 2025
@rowbot-weisguy
Copy link

@s1gr1d thanks for creating a new issue for me. That's correct, the transaction names are using our lambda's name.

Is it possible to have it use the request path instead?

@getsantry getsantry bot moved this from Waiting for: Community to Waiting for: Product Owner in GitHub Issues with 👀 3 Mar 24, 2025
@s1gr1d
Copy link
Member Author
s1gr1d commented Mar 25, 2025
< 8000 /div>

You can change the transaction name based on what is documented here: https://docs.sentry.io/platforms/javascript/guides/aws-lambda/enriching-events/transaction-name/

Does that work for your case?

@AbhiPrasad AbhiPrasad added the Package: aws-serverless Issues related to the Sentry AWS Serverless SDK label Mar 25, 2025
@getsantry getsantry bot moved this to Waiting for: Community in GitHub Issues with 👀 3 Apr 10, 2025
@stephanie-anderson stephanie-anderson removed the Package: aws-serverless Issues related to the Sentry AWS Serverless SDK label Apr 16, 2025
@getsantry
Copy link
getsantry bot commented May 14, 2025

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you remove the label Waiting for: Community, I will leave it alone ... forever!

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

9CF0
@getsantry getsantry bot added the Stale label May 14, 2025
@getsantry getsantry bot closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2025
@rowbot-weisguy
Copy link

Hi @s1gr1d, sorry for the long delay on this issue! I can finally report back.

Up front: using @sentry/aws-serverless@9.24.0

I tried manually setting the transaction / span names in a middleware function to look more like our routes and although it's not perfect, it did help! I can click into a trace and see the title reflects the route name and an option to "View Summary" of aggregates based on the route name (which looks like GET /api/resource/:id).

However, the issue list still shows the function name when I wish it showed the route:

Image

Ultimately my hope is to see express span context preferred given these three choices:

  • Using @sentry/aws-serverless SDK to call init and wrapHandler
  • Sentry.expressIntegration() explicitly added in Sentry.init
  • Sentry.setupExpressErrorHandler(app) is added to the express app

PS. I did find an interesting startTrace option in the Sentry.wrapHandler method added by this PR #9154. It mentions that express users may want to set this to false. But it seems like that would put us into a situation of manually starting spans? I'm not sure how that option is intended to be used and it seems like it suits somebody's manual overrides but I'm not sure how to follow in their footsteps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
AWS Lambda Improvement Stale
Projects
GitHub Issues with 👀 3
Archived in project
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mydea @rowbot-weisguy @stephanie-anderson @AbhiPrasad @s1gr1d
0