best practices with expvar

190 views
Skip to first unread message

pkae...@launchdarkly.com

unread,
Apr 29, 2016, 9:00:44 PM4/29/16
to golang-nuts
The expvar package seems amazingly useful in giving me more visibility into the running state of my application.  However, I'm not clear on the best way to use it.

At its core, it looks like I should publish a Var that knows how to get the value, and serialize it to a string.  That is, when I hit /debug/vars, it will calculate the value on the fly.  My application code just needs to set it up during initialization.

However, there are a lot of helpers in the expvar package that make it easy to publish non-string values.  It seems that they are static values, though, and my application needs to refresh the values periodically.  Eg, I can publish a NewInt during initialization, and then either Add or Set it in my application code.

I can see performance and maintenance tradeoffs to both approaches. If a value is expensive to calculate, then I might not want to trigger its calculation whenever someone happens to hit /debug/vars.  On the other hand, if I otherwise ensure that nefarious users cannot hit /debug/vars, calculating on-demand will give me more accurate results, and I can only incur the cost of calculation when I need the value.

Is there a reason to prefer one way over the other?  Or does it just depend on the tradeoffs I listed?  If it depends on the tradeoffs I listed, is there a reason that I cannot easily publish a value with a closure that can calculate it?

Thanks!
Reply all
Reply to author
Forward
0 new messages