Sentry

Sentry

DevOps / Monitoring / Exception Monitoring
Avatar of johnnyxbell
Senior Software Engineer at StackShare·

For my portfolio websites and my personal OpenSource projects I had started exclusively using React and JavaScript so I needed a way to track any errors that we're happening for my users that I didn't uncover during my personal UAT.

I had narrowed it down to two tools LogRocket and Sentry (I also tried Bugsnag but it did not make the final two). Before I get into this I want to say that both of these tools are amazing and whichever you choose will suit your needs well.

I firstly decided to go with LogRocket the fact that they had a recorded screen capture of what the user was doing when the bug happened was amazing... I could go back and rewatch what the user did to replicate that error, this was fantastic. It was also very easy to setup and get going. They had options for React and Redux.js so you can track all your Redux.js actions. I had a fairly large Redux.js store, this was ended up being a issue, it killed the processing power on my machine, Chrome ended up using 2-4gb of ram, so I quickly disabled the Redux.js option.

After using LogRocket for a month or so I decided to switch to Sentry. I noticed that Sentry was openSorce and everyone was talking about Sentry so I thought I may as well give it a test drive. Setting it up was so easy, I had everything up and running within seconds. It also gives you the option to wrap an errorBoundry in React so get more specific errors. The simplicity of Sentry was a breath of fresh air, it allowed me find the bug that was shown to the user and fix that very simply. The UI for Sentry is beautiful and just really clean to look at, and their emails are also just perfect.

I have decided to stick with Sentry for the long run, I tested pretty much all the JS error loggers and I find Sentry the best.

READ MORE
17 upvotes·405.6K views

At FundsCorner, we are on a mission to enable fast accessible credit to India’s Kirana Stores. We are an early stage startup with an ultra small Engineering team. All the tech decisions we have made until now are based on our core philosophy: "Build usable products fast".

Based on the above fundamentals, we chose Python as our base language for all our APIs and micro-services. It is ultra easy to start with, yet provides great libraries even for the most complex of use cases. Our entire backend stack runs on Python and we cannot be more happy with it! If you are looking to deploy your API as server-less, Python provides one of the least cold start times.

We build our APIs with Flask. For backend database, our natural choice was MongoDB. It frees up our time from complex database specifications - we instead use our time in doing sensible data modelling & once we finalize the data model, we integrate it into Flask using Swagger UI. Mongo supports complex queries to cull out difficult data through aggregation framework & we have even built an internal framework called "Poetry", for aggregation queries.

Our web apps are built on Vue.js , Vuetify and vuex. Initially we debated a lot around choosing Vue.js or React , but finally settled with Vue.js, mainly because of the ease of use, fast development cycles & awesome set of libraries and utilities backing Vue.

You simply cannot go wrong with Vue.js . Great documentation, the library is ultra compact & is blazing fast. Choosing Vue.js was one of the critical decisions made, which enabled us to launch our web app in under a month (which otherwise would have taken 3 months easily). For those folks who are looking for big names, Adobe, and Alibaba and Gitlab are using Vue.

By choosing Vuetify, we saved thousands of person hours in designing the CSS files. Vuetify contains all key material components for designing a smooth User experience & it just works! It's an awesome framework. All of us at FundsCorner are now lifelong fanboys of Vue.js and Vuetify.

On the infrastructure side, all our API services and backend services are deployed as server less micro-services through Zappa. Zappa makes your life super easy by packaging everything that is required to deploy your code as AWS Lambda. We are now addicted to the single - click deploys / updates through Zappa. Try it out & you will convert!

Also, if you are using Zappa, you can greatly simplify your CI / CD pipelines. Do try it! It's just awesome! and... you will be astonished by the savings you have made on AWS bills at end of the month.

Our CI / CD pipelines are built using GitLab CI. The documentation is very good & it enables you to go from from concept to production in minimal time frame.

We use Sentry for all crash reporting and resolution. Pro tip, they do have handlers for AWS Lambda , which made our integration super easy.

All our micro-services including APIs are event-driven. Our background micro-services are message oriented & we use Amazon SQS as our message pipe. We have our own in-house workflow manager to orchestrate across micro - services.

We host our static websites on Netlify. One of the cool things about Netlify is the automated CI / CD on git push. You just do a git push to deploy! Again, it is super simple to use and it just works. We were dogmatic about going server less even on static web sites & you can go server less on Netlify in a few minutes. It's just a few clicks away.

We use Google Compute Engine, especially Google Vision for our AI experiments.

For Ops automation, we use Slack. Slack provides a super-rich API (through Slack App) through which you can weave magical automation on boring ops tasks.

READ MORE
Patterns for infinitely scaling & cost effective serverless microservices — Part 3 (medium.com)
16 upvotes·667.5K views

This is my stack in Application & Data

JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

My Utilities Tools

Google Analytics Postman Elasticsearch

My Devops Tools

Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

My Business Tools

Slack

READ MORE
10 upvotes·1 comment·1.3M views
Avatar of yonasb
CEO at StackShare·

One of the challenges we've had to deal with as our product surface area has grown, is identifying and reproducing bugs. We use Sentry for exception monitoring, however, it's usually difficult to try to reproduce bugs. I first heard about FullStory from our friends over at Flexport (check out the Stack Story and you'll hear them mention it: https://stackshare.io/posts/how-flexport-builds-software-to-move-over-1-billion-dollars-in-merchandise). FullStory let's you record user sessions, and play them back to help you identify bugs and UX issues. You're even able to view the console errors live as they happen during the sessions!

We were pretty blown away at how comprehensive the product was at first, and it seems to be getting better every time I use it. Only complaint is that it's super expensive once you're in the hundreds of thousands of sessions so we had to stop trying to record logged out sessions, we only use it for auth'd sessions. We also started out using it via Segment but once we needed to watch out for the number of sessions we were recording we realized that it was impossible to restrict FullStory recordings on a per-page basis without ripping it out of Segment, so we ended up just using their JS snippet and putting that in the Rails views that we wanted to monitor closely.

The ability to share specific portions of sessions, speed them up, skip inactivity, and all sorts of other little features all add up to a really solid product that helps both our PMs and engineers improve our own product much quicker. I officially requested a Sentry + FullStory integration a while back https://twitter.com/yonasbe/status/871987738777616384, still waiting on this! #UserFeedbackAsAService #reproducing-bugs #sessionrecording #bug-squashing

READ MORE
10 upvotes·281.7K views
Avatar of Scrayos
CEO at Scrayos UG (haftungsbeschränkt)·

We primarily use MariaDB but use PostgreSQL as a part of GitLab , Sentry and Nextcloud , which (initially) forced us to use it anyways. While this isn't much of a decision – because we didn't have one (ha ha) – we learned to love the perks and advantages of PostgreSQL anyways. PostgreSQL's extension system makes it even more flexible than a lot of the other SQL-based DBs (that only offer stored procedures) and the additional JOIN options, the enhanced role management and the different authentication options came in really handy, when doing manual maintenance on the databases.

READ MORE
7 upvotes·171.2K views

A huge part of our continuous deployment practices is to have granular alerting and monitoring across the platform. To do this, we run Sentry on-premise, inside our VPCs, for our event alerting, and we run an awesome observability and monitoring system consisting of StatsD, Graphite and Grafana. We have dashboards using this system to monitor our core subsystems so that we can know the health of any given subsystem at any moment. This system ties into our PagerDuty rotation, as well as alerts from some of our Amazon CloudWatch alarms (we’re looking to migrate all of these to our internal monitoring system soon).

READ MORE
How Mixmax Uses Node and Go to Process 250M Events a day - Mixmax Tech Stack (stackshare.io)
5 upvotes·479.3K views
Avatar of liveweird
CTO at Shedul/Fresha·

Regarding Continuous Integration - we've started with something very easy to set up - CircleCI , but with time we're adding more & more complex pipelines - we use Jenkins to configure & run those. It's much more effort, but at some point we had to pay for the flexibility we expected. Our source code version control is Git (which probably doesn't require a rationale these days) and we keep repos in GitHub - since the very beginning & we never considered moving out. Our primary monitoring these days is in New Relic (Ruby & SPA apps) and AppSignal (Elixir apps) - we're considering unifying it in New Relic , but this will require some improvements in Elixir app observability. For error reporting we use Sentry (a very popular choice in this class) & we collect our distributed logs using Logentries (to avoid semi-manual handling here).

READ MORE
4 upvotes·486.8K views
Avatar of michaelmota
Founder at AlterEstate·
Shared insights
on
SentrySentry
at
()

We use Sentry because in order to keep track the errors caused on the frontend and on the backend we use Sentry. It's not secret that the user can have errors and never report it to your team, which makes it an "invisible" bug because you never notice it. With Sentry we were able to reduce a lot of errors that on the early dev phase we thought were good but on production turn out to be wrong. Keeping track on what's not working it's awesome because that gives you the opportunity to fix it so your customers can have a better UX.

READ MORE
3 upvotes·1.6K views
Shared insights
on
SentrySentry
at

Sentry has been very useful for me and my team. I caught a bug in staging — just as one example — which I wouldn't have caught before deploying to production. That's the sort of thing that happens on a regular basis with Sentry.

I didn't personally make the decision to use Sentry since I'm part of a very large organization that chose it before I joined company. But we've been more than happy enough with Sentry that we use it across most of our teams, regardless of their stack.

READ MORE
2 upvotes·20.2K views
Avatar of kunthar
General Manager at Zetaops·
Shared insights
on
SentrySentry
at

Backend apps using Sentry to trace undetected bugs and strange behaviour of code. Sentry

READ MORE
1 upvote·470 views