Let's pretend to Will. I just click done. Bam. Now it's done within Sentry as well. And it would have done it as well. From alerting to the deep context to the commit that causes this, getting the right person involved so that we can stabilize this. And you can even say fixes this Sentry issue and will automatically mark it as resolved in that release as well.
Long story short, we want to make sure the developer gets notified, has the context they need, has the information they need. They can trace it. They can fix it. They know what commit caused it, get the right firefighter on the job, and go back to development, or playing racquetball, or whatever it was that you're doing.
So that is mostly what I had for today. I wanted to showcase how we can use Sentry for knowing about our errors, getting the context we need for errors, transactions and performance, know about our releases as well, query our data, and integrate into our entire workflow. And now I just want to open it up for questions. And I see that there are a couple of questions in the chatroom, so I'll address those first.
Can you use Sentry for CICD? So a Sentry is an application monitoring tool, so when you deploy into any of your environments, Sentry will tell it you know that you're having these slowdowns or errors. So as part of your CICD process, where you're pushing out these releases, to production, to your staging environments, yep, you can use Sentry to monitor these things, detect that these issues are happening as you keep releasing.
Looks like Santiago asked, is Sentry a complement of some other tools such as Datadog or New Relic, or is Sentry a replacement for those APM tools? Good question. So Datadog and New Relic are traditional monitoring tools that are mostly used in the back end, and they're mostly agent based. What Sentry is doing is a little bit different. We're doing this from the front end, and we're an SDK in your code that starts typically from the front end, and we're able to trace all of these things. So what we're seeing is developers are using Sentry because it fits into their workflow, it's in their application, it starts from the user experience, and the operations teams use Datadog and New Relic to kind of monitor these back ends and some of these system level type of things. There is a little bit of overlap, but that is the major divide of where you use these things and the personas that typically use these things.
How would it work in a microservice environment? So as you saw earlier, I was debugging a 500 error. Let's say if we did have more microservices attached to this, or the back end actually was more complicated, we would see more transactions here, and we would be able to trace this all the way through. So what we're doing is we're passing these Sentry Trace Headers, and that's being set as contacts, and our server side is then making sense of all of this, establishing the parent-child relationship, and who requested to whom, and what happened, and then uniting all of these transactions and errors as well.
Serverless? Good question. So we do have serverless integrations. And the big thing that we have to make sure about serverless is that the event is flushed out. So that's one of the changes that we made here. So here's our AWS Lambda plug-in for Node. You can go ahead and use that.
Alright. Next question, can you – so for serverless it would be the same, and it's actually even more valuable because you have less context for serverless because things just fail and then things die and you aren't really left with much. Ignaz asks, can you set this up with Slack, email, and Discord? Exactly. Email, it comes out of the box. Slack, you can go ahead and configure it, and you'll get alerts, as you mentioned here. I believe we have a Discord plug-in as well. And you can go ahead. If you go here, test entry integrations, we can see exactly all the different things.
How does it work with server-side rendering? So for server-side rendering, you would have to include all of our – the SDKs that you would need, so whether it's the JavaScript SDK or Node SDK, and then you would upload the source maps, both for the server-side and client-side stuff. I don't have all of the information regarding that, but I can follow up with you, Steven. It just involves a little bit more configuration.
Santiago asked, does Sentry provide an interface to create synthetic events or a mechanism that I can use to create kernel events to Sentry? Synthetic events, not quite. We don't create synthetic loads and send that to our service, but in regards to a mechanism that creates custom events and reports them to Sentry, Sentry all-in-all is like an event ingestion engine and you can actually create your own SDK or hit our API directly to get that done. If you go ahead into here and then go Usage, there's Sentry.captureException, which takes in an error object. There's Sentry.captureMessage as well, and you can go ahead and use that to send a fan to Sentry, which will then aggregate into issues. And then for transactions, anything that we don't automatically instrument on, you can go ahead and start a transaction and specify spans as well, so we give you quite a bit of control there.
Yeah, no problem, Santiago. Any other questions at this point in time? Hopefully, I was able to show everyone how you all can use Sentry and not have to, you know, deal with this anymore and can then get in front of these problems, know about them, and, you know, help put out better releases or respond to releases.
Comments