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.

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.

There’s a tool called LeakCanary that was built by the team at Square. It detects memory allocations and can spot when this scenario is occurring. LeakCanary has been billed as a memory leak detection library for #Android (and you’ll be happy to know there’s a Bugsnag integration for it as well!).

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).

Which #APM / #Infrastructure #Monitoring solution to use?

The 2 major players in that space are New Relic and Datadog Both are very comparable in terms of pricing, capabilities (Datadog recently introduced APM as well).

In our use case, keeping the number of tools minimal was a major selection criteria.

As we were already using #NewRelic, my recommendation was to move to the pro tier so we would benefit from advanced APM features, synthetics, mobile & infrastructure monitoring. And gain 360 degree view of our infrastructure.

Few things I liked about New Relic: - Mobile App and push notificatin - Ease of setting up new alerts - Being notified via email and push notifications without requiring another alerting 3rd party solution

I've certainly seen use cases where NewRelic can also be used as an input data source for Datadog. Therefore depending on your use case, it might also be worth evaluating a joint usage of both solutions.

Our primary source of monitoring and alerting is Datadog. We’ve got prebuilt dashboards for every scenario and integration with PagerDuty to manage routing any alerts. We’ve definitely scaled past the point where managing dashboards is easy, but we haven’t had time to invest in using features like Anomaly Detection. We’ve started using Honeycomb for some targeted debugging of complex production issues and we are liking what we’ve seen. We capture any unhandled exceptions with Rollbar and, if we realize one will keep happening, we quickly convert the metrics to point back to Datadog, to keep Rollbar as clean as possible.

We use Segment to consolidate all of our trackers, the most important of which goes to Amplitude to analyze user patterns. However, if we need a more consolidated view, we push all of our data to our own data warehouse running PostgreSQL; this is available for analytics and dashboard creation through Looker.

Data science and engineering teams at Lyft maintain several big data pipelines that serve as the foundation for various types of analysis throughout the business.

Apache Airflow sits at the center of this big data infrastructure, allowing users to “programmatically author, schedule, and monitor data pipelines.” Airflow is an open source tool, and “Lyft is the very first Airflow adopter in production since the project was open sourced around three years ago.”

There are several key components of the architecture. A web UI allows users to view the status of their queries, along with an audit trail of any modifications the query. A metadata database stores things like job status and task instance status. A multi-process scheduler handles job requests, and triggers the executor to execute those tasks.

Airflow supports several executors, though Lyft uses CeleryExecutor to scale task execution in production. Airflow is deployed to three Amazon Auto Scaling Groups, with each associated with a celery queue.

Audit logs supplied to the web UI are powered by the existing Airflow audit logs as well as Flask signal.

Datadog, Statsd, Grafana, and PagerDuty are all used to monitor the Airflow system.

There’s a tool called LeakCanary that was built by the team at Square. It detects memory allocations and can spot when this scenario is occurring. LeakCanary has been billed as a memory leak detection library for #Android (and you’ll be happy to know there’s a Bugsnag integration for it as well!).