by
Join the DZone community and get the full member experience.
Join For Freehere at takipi we're in the error tracking business. each day we track more than 500,000 errors coming from hundreds of different companies. errors across different machines, multithreaded errors, errors involving 3rd party libraries, you name it. our goal building takipi was to track code that led to errors and slowdowns. we dreamed of a place where we could view information that was not available before, even in log files.
dreams do come true - our new errors viewer
takipi records variable values as they were in each frame of the stack. we were looking for a way to allow users to easily scan the stack and spot the variables that caused the error. how cool would it be, we thought, if we could scan the code that led to an error with a single scroll? pretty cool. so we built it - a new way to view server errors:
looking inside the monster
on the left of this new screen you can see the call stack that led to an exceptions or a logged error (screenshot below). frames with a glasses icon represent frames with recorded variables. to reduce noise, takipi only records variable values that might have led to the error. frames marked with a pencil icon contain code that was recently modified. since new bugs often crawl out of new code, highlighting these parts can help tracking them. if one machine invoked an api call on another machine which caused an error, you'll be able to see the entire path. the cross-machine analysis works if you're sending an http request using java’s standard apis or any popular 3rd party library.
the prime suspects
scooting over to the right - the prime suspects. here you can see your code and get the exact variable values that led to each error as they were when it happened. quickly scroll over all the methods that led to the error. recorded variables are highlighted and when hovering you can see the variable value as it was at the moment of the error. if it's a complex object with fields, you can view them as well. how do we display code? to provide max security for source code, takipi encrypts the user’s code using a 256-bit secret aes key that can be generated locally.
the rest is history
if this exception happened more than once you can toggle between different recordings and compare the stack and variable values. for exceptions that happen dozens, hundreds, thousands or millions of times, we limit the recordings to a few dozen in order to keep the overhead minimal.
to salute your awesomeness and interest in our new concept, we are offering an
extended two-month trial
for users who register from this post on dzone. what about slowdowns? good thing you asked. we're currently designing takipi slowdown analysis: building a new concept for highlighting code which led to slowdowns. if you’d like to review it in a closed beta and give us some feedback, contact us at
hello@takipi.com
. it’s super interesting - promise!
Opinions expressed by DZone contributors are their own.
Comments