Monitoring & Observability

[00:00:00]
>> Steve Kinney: Some other things that kind of come up, observability and like how do you know this stuff happens beforehand, right? Like, there are tools like Sentry and, you know, Bugsnag and a bunch of others that will install them and like try to catch the errors and report it, like having like thinking about like how do you know when things go wrong before something actually happens. I wish I still had access to like a giant data set that I used to have like at my old job.

[00:00:31]
I don't have access to that anymore, and it's really hard to like simulate users having a problem, but like, how do you catch the errors and like what is that flow looking like? Because that also informs like where are the problems in your codebase, right? And so like, there are a whole bunch of them. Sentry, Bugsnag, whatever, but like, effectively giving you the ability to kind of like run them alongside your code and like, should an uncaught error bubble up or should various things happen like what becomes super interesting with tools like this is you get interesting real user metrics, right?

[00:01:12]
Like, it is interesting to see how your application performs to like largest contentful paint in Brazil versus the UK, right? Like, do you have a CDN problem that you need to fix, right? Or Safari, right? Like you get to find out all the weird ways that your application breaks in Safari that you forgot because some of us are lucky to have one person who works in the org who uses Safari all the time and they'll tell you about it.

[00:01:45]
But if you don't have that, you know, having the ability to kind of like pull in a lot of that data and like a lot of these are very little setup, right? Obviously they're in a lot of cases like not free, right, but like some version of like the ability, like to actually see a recording of what went down when the bug happened, and like why I think that it is usually better to throw a little bit of money at the problem than to try to hand roll it.

[00:02:23]
Could you hand roll it? Of course you could, you know you could. We all know that, you know, you could do it. What's really great about some of these tools are like, the things that come slightly after that, right, which is, for instance, when you see the recording, it will have like blocked out all of the like actual data on the page, right, so like, you know, things I do never. I have made some mistakes in my life.

[00:03:00]
For instance, I was like, I had a rule that all like UI state should be also like captured in the URL, right? So if we're going to have a search or a filter, like we should count it as a, you know, query param for like what the search words. So if I like filter a whole list and stuff like that, and I send it to you, you should see the same filtered list. Unlike every banking app you've ever used, where it's just one URL and if you send anything, it's like the homepage no matter what.

[00:03:29]
Not that I'm sending banking URLs, but you know, banks are the worst in that case, and there's a whole bunch of other apps where it's just like you can't send a link. And at the time I was working on an email editor. And, you know, somebody on my team was following my rules. And they were working on the contacts page. Where you could search by email. Which was then in the URL. Which was then going to Segment.

[00:04:00]
Which was definitely PII. And then I had to spend a week of my life on the phone with Segment, getting all the PII that I had sent scrubbed so that we were not in violation of the European Union's laws on privacy, right? And so, could you roll all of these things yourself? You could. Should you? Probably not, right? It's like rolling your own auth. So like, a lot of these tools, it doesn't really, I've used Sentry in the past, it's fine, it's good, right?

[00:04:31]
I know people who use some of the other ones, they're fine, they're good, but like, are you getting the error reporting in this case, right? Like, and all of these are like you drop one thing, like either like if you're just working on the client set up, you could drop it, honestly, it's a script tag in the index.html file, if you're using something like Next or SvelteKit and you want to get both the server-side and the client-side, you can drop it in like the kind of like root, like data loader, like handler piece and have those things in place, but like making sure that you are collecting that data, like Vercel, for instance, has like an observability thing you can buy for like $10 a month or something like that, that will show you like both the error logs as well as like where you're more or less performant, right?

[00:05:24]
It's usually not particularly expensive, but like I, having messed it up in past lives before, I don't do it by hand anymore, so I will not recommend that you do it by hand, even though we all know you probably could, but like finding some service for the, and again, tracking those things. If it's going into the system and it's not like getting like boiled down to either Jira tickets or, you know, some of the things that like, some of these tools will do really well is like, because the problem with frontend code.

[00:05:57]
Did that blow up? Because your code is bad. Or did that blow up because halfway through downloading the JavaScript file, they went into a tunnel. You know what I mean? And so like one blow up is not something I want to get paged over. And it'll do things like, oh, there was a spike of the same error from a lot of different people at the same time that I want to know about and get paged.