https://serverless-stack.com/ logo
Join Slack
Powered by
<https://cloudash.dev/>
# random
t
a
Nice.
I’ve been using Epsagon for years.
Might take a look to this.
Also used Lumigo, but didn’t like it.
t
This looks cool because there's no additional things to install
Just queries aws
a
Nice.
Yeah Epsagon adds a layer.
t
We just wrote docs for epsagon and lumigo as well. I didn't love either
a
What you mean wrote docs?
t
Just on how to integrate with those services since people ask a lot
I tried them all out in the process of writing the docs. Epsagon broke my production functions with their layer lol
s
What interests me most about the next step in serverless monitoring is having my data not need to leave the aws estate, savings on those crazy egress costs. https://www.sensedeep.com/ is the only one I have seen that is serverless self hosted infrastructure
a
@Simon Reilly their onetable lib for dynamodb is amazing as well.
a
@thdxr but is that doc for SST or what?
t
Yeah
a
I’m interested on the Epsagon stuff.
@thdxr is that published already?
t
It's in a pr
It's not a lot, just shows how to add the layer
a
Yeah I’m looking for that.
@thdxr for the Epsagon Layer ARN, should I store that into SSM? Or there is a way to “lookup” for ARN from SST code? thoughts?
t
I was just thinking to hard code it. Do you expect to be using multiple different layers?
a
Well, each environment has their own, right?
t
Iirc every region + node version has its own. Are you in multiple regions?
You can hardcode a map and look it up by region
a
@thdxr sorry, I meant, I have 1 account for each environment… dev/stage/prod… so is going to be one ARN per account.
So I was thinking to store the ARN in SSM like… “/epsagon-arn” and share it across the account.
r
Talking to Ran, the CTO at Epsagon, he recommended not to use the layer approach and to use the individual wrapping of functions
a
Ideally I can do a lookup, but not sure if that’s possible.
@Ross Coundon yeah I been using wrapping, but doesn’t work with Middy.
I mean, not right away, maybe some setup must be done.
t
You can create a map in TS with the three layer arns and lookup which one you need
r
That's interesting, I did mention we were thinking about middy and he said it should work fine
a
Ok, I couldn’t get it to work right away, I was also looking for an epsagon-middy, but couldn’t find one.
@Ross Coundon any reason why wrapper is better? I think also you can send events, which is not something you can do without it.
I don’t think you can trigger events only with the layer.
r
Let me try to find the conversation, it was on Slack so should be there
a
Nice.
r
There was this
a
Thanks @Ross Coundon, is that in Epsagon slack or where? I can ask how has been done maybe.
r
We have a shared slack workspace with them
a
Oh I see.
Nice.
r
I can't find the msg about layer vs wrapping, I think I had that conversation on their Intercom live chat and that's not searchable
a
Makes sense.
But what you think about sending tags/events?
You can’t do that with layer, right?
Like I want to send 
userId
as a label.
r
Found it, was Ron in support. He said "And TBH I wouldn't use the extensions.. there's not much benefit to it over the current method."
That was back in April
We can raise error events with our wrapped lambdas. Not sure about if/how that works with layers
a
Yeah, me neither.
My problem at the moment is the wrapper not working due Middy.
So without the layer, does Epsagon still creates the traces diagram? @Ross Coundon
r
Yep
worth asking them about the middy thing on Live Chat
a
Ok going to do that.
Thanks man.
r
pleasure
t
I wonder why wrapping is preferred. The docs I wrote suggest the layer
a
@thdxr you can’t send events with layer.
Or I’ve never found a way to do it.
I mean, you can’t send “custom events” or “custom labels” whatever is called.
Because you need an instance of the Monitor in your code.
t
ah I see
a
With wrapper you can trigger events and then those shows in the logs, which a nice “label”. This is nice to display USER ID or things like that.
@thdxr I don’t get something… is Epsagon Layer a single one for the entire AWS region?
I thought they deployed a layer on each account.
t
No they don't deploy a layer, it's uploaded to a shared aws marketplace type thing. And you can just import it
a
I see, that makes sense.
t
You can just hardcode this "arnawslambdaap southeast 1066549572091layerepsagon-node-layer:307"
as long as you're not deploying between region
a
But I’m hardcoding the version there.
But anyway, no major issue.
I was thinking if 
script
from SST can help on this, pulling the updated arm.
t
script won't be helpful because it executes after everything has been deployed. But also I'm not sure I'm following - is there a reason you want to dynamically pull the arn value?
a
Ok, just because of the layer version.
But it’s ok, No major issue, I can hardcode it.
Can I add to the main 
app.setDefaultFunctionProps()
?
Looks like it can’t run outside stack?
Copy code
Error: Import at 'EpsagonLayer' should be created in the scope of a Stack, but no Stack found
t
You can use the callback form of app.setDefaultFunctionProps(stack =>
a
Nice trick.
@Ross Coundon once you add a layer to function, do you get auto-tracing enabled? I dont…
r
Sorry, never tried it
a
This is what creates the diagrams with traces, do you use that feature?
t
I'm not sure if that button reflects if it's working or not. Once you add the layer are traces showing?
r
The diagrams are there when we click on the trace with the wrapped functions. The button to turn on auto-tracing isn't there when the function is wrapped
a
Ok.
Well, I have the Layer in my lambda, I see it.
But the auto-tracing is not eabled.
Apparently if I click it, it does something else.
It wraps the function apparently, but not sure how they do it.
This is my function at the moment, check the handler.
Now I’m going to enable auto-tracing.
This happens after enabling auto-tracing.
Apparently they inject a Wrapper in my function? insane!
r
Yep. This broke one of our functions (can't remember the reason) so we wrap it ourself instead
t
@Adrián Mouly I forgot a step in the docs
Configure Environment Vars for Node or Python auto-tracing.
EPSAGON_TOKEN=TOKEN
EPSAGON_APP_NAME=APP_NAME
NODE_OPTIONS='-r epsagon-frameworks'
a
Ah!!
@thdxr yeah this is also added when I enabled the auto tracing.
Wondering if we can do the wrapping with SST too.
t
we have an idea of how to do that
a
Nice @thdxr let me know how that goes.
Also, what 
NODE_OPTIONS='-r epsagon-frameworks'
is supposed to do, do you know what 
-r
is? I think I need also to add 
epsagon-frameworks
to my node package.
t
You don't need to add it because I believe that's what's in the layer. 
-r
auto-requires the package specified
a
Yeah.
I see.
The bad thing about this, is the Token is being exposed on the env-vars… but well..not that bad.
If you do the in-lambda-wrapper, then all can be done un run-time.
Well, I can not get the tracing to work, might require the wrapper.
r
A while back I was chatting to Frank about this, wondering if there was a way to provide a plugin-esque option for SST. Like Epsagon has a serverless plugin that autowraps the functions, would be cool to be able to do a similar thing with SST
a
Yeah I would love to have that @Ross Coundon.
f
@Ross Coundon yeah, been thinking a lot about that. Last time when we chatted, I was thinking just wrapping around the code (ie. middleware). After looking at some other use cases with @thdxr, it makes sense to wrap around both the resource and code, so the plugins can also add layers, environment variables, ie.
Copy code
new Function(this, "MyFunction", {
  handler: "src/lambda.handler",
  plugins: [
    "fetch-ssm-plugin": {
      DB_PASSWORD: "/path/to/ssm",
    },
    "sentry-plugin": {
      SENTRY_KEY: "...",
    },
  ],
});
The 
fetch-ssm-plugin
would be a middy like middleware that fetches the SSM value and sets it as 
process.env.DB_PASSWORD
. And the 
sentry-plugin
would add a layer, and may or may not wrap the code.
r
Sounds interesting
a
@Frank I love it.
Let’s do it 😍 .
Open in Slack
PreviousNext
Powered by