<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1187">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #011892}
p.p4 {margin: 0.0px 0.0px 0.0px 12.0px; font: 16.0px Helvetica; color: #011892; min-height: 19.0px}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}
span.s1 {text-decoration: underline}
</style>
</head>
<body>
<p class="p1">I'm not sure what you mean by defensive code, but just to be sure:</p>
<p class="p2"><br></p>
<p class="p1">You should never let error reporting influence how you handle faults in your software.<span class="Apple-converted-space"> </span>Defensive code is a code smell in Erlang.</p>
<p class="p2"><br></p>
<p class="p1">What you coucld do is to have a error logger handler that matches certain often occuring errors and ignores it.<span class="Apple-converted-space"> </span>Even better it should count them (the count of something unineresting is often interesting).</p>
<p class="p2"><br></p>
<p class="p1">For counting and other metrics you might want to have a look at folsom https://github.com/boundary/folsom</p>
<p class="p2"><br></p>
<p class="p1">-- Peer</p>
<p class="p2"><br></p>
<p class="p2"><br></p>
<p class="p1">On 2013-06-03 17:29:54 +0000, ANTHONY MOLINARO said:</p>
<p class="p2"><br></p>
<p class="p3">I'd recommend addressing the other crashes with "defensive code". By capturing and categorizing certain types of errors and clearing those from your logs you'll be able to better see true errors. I usually have a two phase approach. First phase, I capture and log the types of errors. Second, once I see certain types are regular I replace those with metrics (via mondemand). Once you have a stream of errors you can then monitor the rates, plus uncaught errors will make it into your logs which should remain very sparse.</p>
<p class="p4"><br></p>
<p class="p3">-Anthony</p>
<p class="p4"><br></p>
<p class="p3">On Jun 3, 2013, at 9:11 AM, Ransom Richardson <<a href="mailto:ransomr@talko.com"><span class="s1">ransomr@talko.com</span></a>> wrote:</p>
<p class="p3">Are there tools/procedures that are recommended for processing crash reports from a service running at scale?</p>
<p class="p4"><br></p>
<p class="p3">Currently we have a limited deployment and I look through all of the crash reports by hand. Some are very useful for finding actual bugs in our code. But other crashes are the result of client's sending bad data, strange timing issues (mostly not in our code), etc and are not actionable. As we prepare to scale up our service, I'm wondering how to continue to get the value from the interesting crash reports without having to look through all of the uninteresting ones. </p>
<p class="p4"><br></p>
<p class="p3">I haven't found rb to be very useful for finding the new/interesting crashes. Are there effective ways that peopler are using it?</p>
<p class="p4"><br></p>
<p class="p3">Are there other tools for parsing and grouping crash reports to make it easy to find new/interesting ones?</p>
<p class="p4"><br></p>
<p class="p3">thanks,</p>
<p class="p3">Ransom</p>
<p class="p4"><br></p>
<p class="p3">_______________________________________________</p>
<p class="p3">erlang-questions mailing list</p>
<p class="p3"><span class="s1"><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></span></p>
<p class="p3"><span class="s1"><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></span></p>
<p class="p5"><br></p>
</body>
</html>