Show HN: Errorship, use datadog as an error tracker

Why not use distributed tracing? You get the context of entire request in addition to the exception.

How does this compare to Datadog&#x27;s APM[0]? APM looks like it has far more features and is already integrated with Datadog.<p>[0] <a href="https:&#x2F;&#x2F;www.datadoghq.com&#x2F;apm&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.datadoghq.com&#x2F;apm&#x2F;</a>

For Java I&#x27;d written a Logback exception sender[0] that creates metrics tagged by level, class, exception class, cause classes. I&#x27;ll say that it is a quick and convenient way to see changes in system error characteristics. I had used a similar setup for Graphite but didn&#x27;t work as well without tags.<p>Since DataDog charges by number of metrics and each tag combination counts as one, actual exception messages should only be included in tags if they don&#x27;t have instance-varying text.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;karmakaze&#x2F;logback-metrics-datadog" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;karmakaze&#x2F;logback-metrics-datadog</a>

Hey HN!<p>errorShip is a python library that sends exceptions&#x2F;errors generated by your application to your datadog account.<p>Are you tired of looking at metrics in datadog and then switching over to another website to track your applications exceptions? errorship exists to solve that context-switching problem, among others. It&#x27;s a bit like sentry, bugsnag, rollbar etc; except implemented in your own datadog account.<p>I&#x27;m happy to receive any feedback or just chat about it.

Incredibly dumb question, but doesn&#x27;t datadog monitor errors out of the box?

I’m going to make the classic engineer mistake and assume that it’s almost as easy to implement this myself. My understanding is that errorship does something like:<p>- register a global exception handler, probably tweaked to hook into framework specific exception mechanisms.<p>- make the exceptions “pretty”<p>- send the exceptions to the datadog event log.<p>The benefits of rolling my own is avoiding a soft dependency on errorship and that I can tweak exception aggregation and reporting. Is the primary defense that errorship only costs $10 per month or is there additional complexity I’ve missed?

Can you resolve exceptions like in Sentry? Having to look at the list of all exceptions and figure out which ones are of interest wouldn’t be ideal. (In the demo I did notice the level&#x2F;priorities filters, but nothing resembling an unresolved filter.)<p>Also, nitpick: it’s 2020, maybe update the front page screenshot to Python 3? My immediate reaction seeing that py27 screenshot: is this even maintained?

Doesn&#x27;t sending the exception as tags increase metrics cardinality slowing down other queries?

Benefits over sentry?

The library calls back home to validate the key (URL: <a href="https:&#x2F;&#x2F;errorship.com&#x2F;api&#x2F;?errorshipLicensekey={errorship_license_key}" rel="nofollow">https:&#x2F;&#x2F;errorship.com&#x2F;api&#x2F;?errorshipLicensekey={errorship_li...</a>). If it fails it raises an Exception. I don&#x27;t think that this is the correct way to do this.<p>If your server is down, my application would crash too. Just cut the license validation out of the library. If I wanted to use the library without an license I could do so anyway.<p>edit: as noted by the author below, this is not the case :). If the server is not available, it won&#x27;t raise an exception. I did miss that part somehow.