top of page

Make the most of Datadog and Sentry Introduction



I have been exploring these for a while and I wanted to share the thought process through a blog article. At the moment, “we” (developers) are facing the following challenges:


Production issues are difficult to trace and visualise.

There are many factors involved in production issues and many cross-team communications address the real problem or defect. I would like to narrow it down to engineering only for the moment and help us place the tools at the right spot.

The thought process would then be converted to an ADR for the further steps needed to bring this into action.


This blog is to offload my ideas into a document.


Let’s begin. Before we address the main problem, let us cover the top-level differences between the two, which collectively solve the bigger problem of “addressing engineering issues“.

We’ll be using StackShare (https://stackshare.io/stackups/datadog-vs-sentry ) to help us get to the bottom of it


StackShare provides online software for displaying and sharing your technology stack, which is made up of the software that you use. We're an online community that features comparisons, ratings, reviews, recommendations, and discussions of the best software tools and software infrastructure services.


What is Datadog?

Developers describe Datadog as "Unify logs, metrics, and traces from across your distributed infrastructure".

Datadog is the leading service for cloud-scale monitoring. It is used by IT, operations, and development teams who build and operate applications that run on dynamic or hybrid cloud infrastructure.

Start monitoring in minutes with Datadog!

200+ turn-key integrations for data aggregation

Clean graphs of StatsD and other integrations


"Monitoring for many apps (databases, web servers, etc)""Easy setup" and "Powerful UI" are the key factors why developers consider Datadog


What is Sentry?

Sentry is detailed as "Cut time to resolution for app errors from five hours to five minutes".

Sentry is an open-source platform for workflow productivity, aggregating errors from across the stack in real-time.

500K developers use Sentry to get the code-level context they need to resolve issues at every stage of the app lifecycle.

Real-Time Updates: For the first time, developers can fix code-level issues anywhere in the stack well before users even encounter an error.

Complete Context: Spend more time where it matters, rather than investing in low-impact issues.

Integrate Everywhere: Drop-in integration for every major platform, framework, and language -- JavaScript, Python, PHP, Ruby, Node, Java, .NET, and mobile.


"Consolidates similar errors and makes resolution easy""Email Notifications" and "Open source" are the primary reasons why Sentry is favoured.


How do I see us using both?

Datadog can help us address monitoring and alerts. This is more from a high-level angle and an entry point to debug larger issues. (birds-eye)

Sentry can help the developers address code problems and update only if needed. This is more from a micro detailed, to the line in code, level insight for debugging (fish eye).

Sentry takes a huge overhead of logging best practices and gives an amazing UI to the devs for identifying, addressing, escalating, grouping and narrowing down the issues and sorting them on priority.

The issues identified could be then converted to Jira tickets for us to address, based on the severity we can then put them across in the respective sprints.

Datadog (DevOps, devs sometimes), Sentry (devs, DevOps (sometimes)).

This would also reduce the number of alerts on the respective Slack channels and help us be more productive in addressing those issues.


Summary

Logging has been identified as a pain point and according to me, just the optimal use of our tools could help us level up our logging and give it a structure.

We could start by adding sentry logs to our dev environment and get more insights on errors, clean up the code let the code address business problems, and let the sentry worry about the logs.

While we are at it, a parallel effort runs to identify the issues and convert them to Jira tickets based on priorities.

0 views0 comments

Recent Posts

See All

コメント


bottom of page