Re: Promulgated charms (production readiness)

On Mon, May 16, 2016 at 2:49 PM, Tim Van Steenburgh wrote: > Right, but NRPE can be related to any charm too. My point was just that the > charm doesn't need to explicitly support monitoring. It totally does, IMO. process count, disk, mem usage are all

Re: Promulgated charms (production readiness)

I agree with a lot of that, I don't puport to be a monitoring expert, but at the same time, as a service writer I know what ports it functions on, I know what services it provides and I know how to tell if it falls over. Similarly as a consumer, I'd also like to TFDI and draw some lines and have

Re: Promulgated charms (production readiness)

Just bringing in a bit of work I've been doing with a few monitoring (/logging) solutions such as Zabbix, Telegraf, Fluentd... I have taken the opposite approach as what is mostly proposed here. I'm from a more ops background, which means my devs usually had no clue whatsoever of how I would

Re: Promulgated charms (production readiness)

I think a layer:nrpe isn't the right choice, but a layer:monitoring might be. Esp with the layer/interface/subordinate model now, it seems that we could actualize an abstract means to declare what to monitor and have nrpe/zabbix-agent/promethous translate that. Marco On Mon, May 16, 2016 at

Re: Promulgated charms (production readiness)

On Mon, May 16, 2016 at 11:06:32AM +, Charles Butler wrote: > > If we can enable this to be a short-story for every charm author, we should > run this down and tackle it, throw money at it, and make it the best > experience for "instant monitoring" ever. I'd like to provide a bit of

Re: Promulgated charms (production readiness)

I think this is a strong argument for creating an interface:nrpe layer to make supporting this as easy as possible. There was also discussion a long time ago about creating a translation layer of sorts for supporting multiple different monitoring solutions (like in the Puppet example). I think

Re: Promulgated charms (production readiness)

NRPE can be related as well, this is true. Maybe I misstated it a bit, I'll blame the jetlag ;) Put it this way, if a user is implementing a to-be promulgated charm, as a minimum (for those who expose such a thing) why not ensure the port is up and listening, not just the host ping, for those who

Re: Promulgated charms (production readiness)

I love it when you support my arguments and I'm too dense to pick up on it Tim :D -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

Right, but NRPE can be related to any charm too. My point was just that the charm doesn't need to explicitly support monitoring. On Mon, May 16, 2016 at 9:35 AM, Charles Butler < charles.but...@canonical.com> wrote: > Thats only monitoring the host's ssh connection/heartbeat. If you want >

Re: Promulgated charms (production readiness)

Thats only monitoring the host's ssh connection/heartbeat. If you want application specific monitoring, you'll need the NRPE agent or to implement it on the charm so it knows what to check. It does the bare minimum by default which i believe to be: "is the host still alive?" On Mon, May 16, 2016

Re: Promulgated charms (production readiness)

Dunno, if you write a charm that provides service X, how would Nagios know what to monitor? -- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart

Re: Promulgated charms (production readiness)

On Mon, May 16, 2016 at 6:44 AM, Tom Barber wrote: > I should be able to say "hey, I'm gonna install this new charm" and know > that I can hook it into our monitoring infrastructure without doing > anything too crazy. > > Isn't this already true? After seeing this

Re: Promulgated charms (production readiness)

I agree its a bit of an ask, but that also being said, if you turned round to a sys admin and said "hey look at this tomcat charm, you can scale it to 100 nodes" and they say "how do I monitor it?" and you reply "well you can't", they'll say, "I'll use x,y,z other tool instead then thanks". First

Re: Promulgated charms (production readiness)

> should it not be a requirement for all promulgated charms to have a monitoring endpoint A bit of a nit, but i strongly disagree with the verbiage here. This should be a best practice. Not every charm developer is going to know Nagios, and its unlikely they are going to spend the time figuring

Promulgated charms (production readiness)

There was a chat we had over dinner at ApacheCon that I figure would be worth bringing up on the list, which was todo with what makes charms "production ready" Charms that have been signed off in the review queue are generally accepted to be of higher quality than ones that haven't(or at least