<div dir="ltr">On Fri, Nov 21, 2014 at 4:48 PM, Justin Lloyd <span dir="ltr"><<a href="mailto:jllwyd@gmail.com" target="_blank">jllwyd@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yes, if a relay becomes unavailable, metrics from certain hosts would get lost until the relay was restored. It's not ideal but it's an improvement over our current architecture. This is in AWS and I'm using Salt for configuration management, so ideally I'd be able to spin up a replacement relay pretty quickly in the event of a complete relay failure.<div><br></div></div></blockquote><div><br><div>My goal is to lose as few metrics as possible (a single poll-cycle or two) during an infrastructure blip, so the receiving layer must be redundant/resilient.<br><br> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I am still considering a possible way to use a load balancer (ELB since this is in AWS) but, as I mentioned, I have other considerations that may limit my ability to do that.</div></div></blockquote><div><br></div><div>FWIW, I'm using ELB to front pairs of relays, and have an issue I haven't yet been able to solve where restarting/stopping one of the relays does not lead to a graceful reconnection of clients; they remain stuck in CLOSE_WAIT for a while, until restarted. There is apparently a brief history of other services fronted with ELBs with clients ending up in this state, so I'm still looking for a fix and/or alternate configurations.<br></div><br><div><br>-tt<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 21, 2014 at 1:11 PM, Tom Throckmorton <span dir="ltr"><<a href="mailto:throck@gmail.com" target="_blank">throck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span>On Fri, Nov 21, 2014 at 3:36 PM, Justin Lloyd <span dir="ltr"><<a href="mailto:jllwyd@gmail.com" target="_blank">jllwyd@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Load balancing and/or round-robin DNS were not appropriate for our situation given other architectural and application considerations in our environment.<div><br></div><div>My solution turned out to be simpler than I expected once I put two and two together with the muti-node capability of the write_graphite plugin combined with a PostCacheChain, like <a href="https://gist.github.com/anonymous/b3c1cd692632216c4c35" target="_blank">https://gist.github.com/anonymous/b3c1cd692632216c4c35</a>.</div></div></blockquote><div><br><br></div></span><div>Ah, cool - like this -> <a href="https://collectd.org/wiki/index.php/Match:Hashed/Config" target="_blank">https://collectd.org/wiki/index.php/Match:Hashed/Config</a> So you're making collectd send some metrics to one relay, some to another etc. What happens when one of the relays goes unavailable? Not trying to poke holes, but to understand your viewpoint - couple of ways to achieve distribution/redundancy here, and always good to hear other ideas...<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>-tt<br></div></font></span><span><div><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 6:26 PM, Tom Throckmorton <span dir="ltr"><<a href="mailto:throck@gmail.com" target="_blank">throck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, Nov 20, 2014 at 2:33 PM, Justin Lloyd <span dir="ltr"><<a href="mailto:jllwyd@gmail.com" target="_blank">jllwyd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>I'm looking for a way to have Collectd be able to send to a set of Graphite relays. Basically right now I have a three-layered Graphite setup, with a layer of four relays (for load distribution and server redundancy) sending to a layer of four aggregators that send to a set of carbon-cache processes on the cache server. I need my Collectd agents to be able to send to any of the four relays but I can't figure out how to accomplish this.</div></div></blockquote><div><br></div></span><div>Hi Justin;</div><div><br></div><div>If you want clients to truly send to <b>any</b> of the relay nodes, then maybe you want to look at fronting your relays with load-balancing, or maybe even round-robin DNS? Each have their benefits and tradeoffs, of course, but in either case the collectd config is as simple as having a single relay destination.</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> I was hoping the <a href="http://collectd.org/documentation/manpages/collectd.conf.5.shtml#filter_configuration" target="_blank">filtering</a> capability would help but I don't see a way to specify a relay-specific write_graphite plugin per rule.</div></div></blockquote><div><br></div></span><div>In that case, would you be sending to <b>all</b> of the relays? (vs. any)</div><div><br></div><div>-tt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir="ltr"><div><br></div><div>Any suggestions? I did come across <a href="https://github.com/obfuscurity/backstop" target="_blank">backstop</a> but I didn't want to introduce a Rack app into the mix.</div><div><br></div><div>Thanks,</div><div>Justin</div><div><br></div></div>
<br></span>_______________________________________________<br>
collectd mailing list<br>
<a href="mailto:collectd@verplant.org" target="_blank">collectd@verplant.org</a><br>
<a href="http://mailman.verplant.org/listinfo/collectd" target="_blank">http://mailman.verplant.org/listinfo/collectd</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>