summaryrefslogtreecommitdiff
path: root/posts/2013-01-10-carbons-manhole.md
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--posts/2013-01-10-carbons-manhole.md (renamed from content/post/2013-01-10-carbons-manhole.md)5
1 files changed, 0 insertions, 5 deletions
diff --git a/content/post/2013-01-10-carbons-manhole.md b/posts/2013-01-10-carbons-manhole.md
index 1bafd97..5dead70 100644
--- a/content/post/2013-01-10-carbons-manhole.md
+++ b/posts/2013-01-10-carbons-manhole.md
@@ -1,8 +1,3 @@
----
-date: 2013-01-10T00:00:00Z
-title: Carbon's manhole
----
-
We're rolling out Graphite and statsd at [work](http://saymedia.com), and I've spend some time debugging our setup. Most of the time, the only thing I need is ``tcpdump`` to verify that a host is sending correctly the various metrics.
But today, thanks to a [stupid reason](http://if.andonlyif.net/blog/2013/01/the-case-of-the-disappearing-metrics.html), I've learned about another way to debug [carbon](http://graphite.readthedocs.org/en/latest/carbon-daemons.html): the manhole. The idea of the manhole is to give you a access to a REPL attached to the live process. When my boss told me about it, I was at first surprised to see this in a Python application. I've already been exposed to this kind of debugging thanks to Clojure, where it's not uncommon to connect a REPL to your live application (for example, Heroku [document how to connect to a remote live REPL in your application](https://devcenter.heroku.com/articles/debugging-clojure)). When I first heard of that I was very skeptical (give access to a *live* environment, and let the developer mess with the process ?!). But I've learned to love it and I feel naked when I'm working in an environment where this is not available. So I was happy to jump and take a look at that feature.