I thought epsagon was gonna be shutted down?! from...
# random
s
I thought epsagon was gonna be shutted down?! from I remember seeing threads here and Twitter. I was checking out their site, look to be still in business with new pricing of 10m tracing for free! That's way cheaper than most if not all the tools I've looked into for serverless monitoring.
j
Yeah I’m not sure what their deal is. Maybe because of the backlash Cisco decided to support them?
r
They changed their mind. I imagine they got a tonne of complaints and decided it was a PR disaster. We've still decided to move off the platform though. If we're not paying for something like that, coupled with the previous, reverted decision, I'm just not comfortable relying on it. We've signed up with Thundra. The team there have been super supportive and they have a couple of key features for us that Epsagon can't which are • Configurable trace truncation ◦ With Epsagon, if your lambda perfomed more than x operations it just stopped recording, if an error occurred in one of the discarded operations, tough. With Thundra you can specify some functions to store more traces • Time Travel Debugging ◦ With Thundra you can see the code at each stage of execution after it's run. So for debugging purposes you can see exactly what variable values were when it ran.
s
Makes sense. They ruin a lot of trust. We were using thundra and switched to datadog but will check out thundra again.
r
What made you switch?
s
It was overall team preference as they used it in the past and it looked to be cheaper. $5 per 1m invocation/tracing. But I am not a fan of their distributed tracing tool, a lot of setup upfront to get what you can get out of the box from thundra.
r
Right, interesting. Thundra now can almost entirely be set up with the addition of a layer.
s
I know, they've improved so much beyond just serverless monitoring as well. How you liking it so far?
r
We like it, although it's fair to say it's early days and we're learning the best ways to use it.
a
it’s weird that you open up https://www.thundra.io/ and their main slogan is: “Monitor/Debug your CI Pipelines & Tests with Foresight” Serverless monitoring only appears half way down the landing page. And their tagline is:
Shift-left CI/CD observability for developer’s everyday use!
We’re right now evaluating o11y tools and it’s interesting to see how Thundra’s branched out into CI/CD and where their future product development efforts will lie.
j
Let me mention this to @Serkan Özal. Maybe he can add some context around this.
s
Thanks for your kind words @Ross Coundon I'm glad to hear that you're happy with Thundra Hi @Sione This is Serkan, CTO @ Co-Founder of Thundra. We would be happy to schedule a meeting to present our product. Please don't hesitate to reach out me (DM or serkan@thundra.io) for any question and help
Hi @Akos, We have multiple teams building 3 of our products: APM, Foresight and Sidekick. APM and Foresight is deeply integrated with each other, sharing same infrastructure and developed by the same team: • APM is focusing on debugging and tracing serverless centric workflows • Foresight is focusing on monitoring and debugging CI pipelines and tests to help you monitor your apps through all stages from development to production.
j
Thanks for chiming in Serkan!
k
@Ross Coundon how did you get the time travel debugging working in SST do i really have to add an env. for each function 😂 Is there a way to configure it globally for all functions?
r
I'm not in front of the code right now but there's a way to set a pattern match for the functions to enable it for. @Serkan Özal will have a more detailed answer
s
Hi @Kujtim Hoxha, you can enable it for all functions with
*.*
pattern but it is not the way that I am suggesting as it instruments everything so you will get too much extra performance overhead 🙂
Have you managed to get it working in a simple example?
k
So the thing is that SST either way compiles everything within one file… And all my handlers have the same handler method called handler. So could something like this work
backend/src/**/*.handler[traceLineByLine=true]
s
so that is the reason that why we provide es build plugin https://github.com/thundra-io/thundra-esbuild-plugin 🙂
It instruments your TS source files during bundling so you can specify particular files/methods and debug over original TS source code, not the bundled js file @Kujtim Hoxha
@Ross Coundon might provide an example configuration when he is available I think
k
Ah ok thanks
r
Here's a very simple example. We have an esbuild.js file that contains:
Copy code
const { ThundraEsbuildPlugin } = require('@thundra/esbuild-plugin');

module.exports = [
  ThundraEsbuildPlugin({
    traceableConfigs: ['src.main.handler.api.*[traceLineByLine=true]'],
  }),
];
Which is referenced in the esbuildConfig property in the bundle like:
Copy code
bundle: {
  esbuildConfig: {
    plugins: 'config/esbuild.js',
  }
},
j
We should update our docs with this.
k
@Ross Coundon
'src.main.handler.api.*[traceLineByLine=true]'
is the path before compilation right ?
r
That's right
k
Ok perfect thanks a lot for the help
s
Thanks Ross 🙏
@Kujtim Hoxha Please feel free to reach us if you need help or question
k
Thanks a lot @Serkan Özal
j
@Frank @manitej can we add this to this doc? https://docs.serverless-stack.com/advanced/monitoring#thundra
m
@Jay yup