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 at least some functional monitoring in place for services I don't understand. which is more than "is my node active", but I agree, its not necessarily the complete solution, but its better than nothing especially on stuff im unfamiliar with but need to deploy. But there is also a clear need for users to be able to tweak and deploy their own monitoring out of band, which for me introduces an interesting juju design quirk... the platform is designed for users to be able to design services quickly and "easily". If I were deploying puppet modules for example, you just git clone everything you need to a modules directory, hack it around to fit your needs and deploy, Juju doesn't follow that paradigm where stuff stays in the charm store apart from local deployment copies, unless you want to fork it. So you are right there needs to be a way of doing this that is separate to charms. But I also think there should be a "preferred way" of rolling this stuff out, because to people who don't understand how it works fully, rolling some custom script, when everything else is controlled by juju gui seems to break away from what Juju is good at. So I guess in summary, I agree about out of band changes and extensions to logging, but I still think charms should provide "extended logging" because the developers understand the services they are building. Tom -------------- Director Meteorite.bi - Saiku Analytics Founder Tel: +44(0)5603641316 (Thanks to the Saiku community we reached our Kickstart <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> goal, but you can always help by sponsoring the project <http://www.meteorite.bi/products/saiku/sponsorship>) On 17 May 2016 at 09:42, Samuel Cozannet <samuel.cozan...@canonical.com> wrote: > 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 manage their stuff. Also, even if they did most > of the job, I would probably need my own ops features. > So I had a bunch of questions for them, would deploy their stuff for them, > add the magic ingredient, and everyone would be happy. > > My point is if I was a CTO somewhere using Juju right now, I wouldn't > expect my developers to actively write monitoring or logging entry points. > Also, I would expect an ops team to redo it anyway. > So I would rather create a "mynamespace-basic-layer", essentially > extending the base layer with the tooling I need (eventually even > incorporating Config management). > At this point I would expect my monitoring and logging **installed** > > Then I use a "self assessment" listing the charms installed locally > function like : > > function charm::lib::self_assessment() { > [ -z ${JUJU_CONTEXT_ID+x} ] && \ > echo 0 || \ > { > METADATA="$(find "${JUJU_CHARM_DIR}/../.." -name "metadata.yaml")" > for FILE in ${METADATA} > do > CHARM+=" $(cat "${FILE}" | grep 'name' | head -n1 | cut -f2 -d' ')" > done > } > echo "${CHARM}" > } > > Essentially, I'm giving my supporting charms the ability to understand the > local environment at the unit level and adapt, even without an explicit > relation. > > I store all monitoring/logging templates centrally which gives me the > ability to update them out of band, as you would for an antivirus DB. If I > was to store them in-charm, I'd need a charm upgrade to update them, which > can be cumbersome, especially if that is in the application charm. > > In the end, I am building very intelligent supporting charms for > monitoring and logging, that understand the target logic based on their own > knowledge of the charm world, and adapt and evolve over time. > Anyone and everyone can then improve the templates, so it's even more > goodness even from people not using Juju. > > My first experiment with Zabbix just used self assessment, added that to > the agent metadata, and the server would have a specific list of templates, > react to auto-discovery of the agents by looking up the metadata and > associate the proper templates automagically. It would also create groups > of machines, and eventually autoscaling rules. > > Now I'm doing the same with fluentd (logging), storing the list of > templates in github and the agent downloads the templates it needs at > install time, and also for Telegraf (InfluxDB) > > From a user perspective, it's really "let's add monitoting", creating a > "juju add-relation all" feature like : > > juju status --format json | jq '.services | keys[]' | tr -d '"' | xargs -I > '{}' juju add-relation ntp {} > > and off you go... > > Thoughts? > > ++ > Sam > > > > > > > > > > > > > > > -- > Samuel Cozannet > Cloud, Big Data and IoT Strategy Team > Business Development - Cloud and ISV Ecosystem > Changing the Future of Cloud > Ubuntu <http://ubuntu.com> / Canonical UK LTD <http://canonical.com> / > Juju <https://jujucharms.com> > samuel.cozan...@canonical.com > mob: +33 616 702 389 > skype: samnco > Twitter: @SaMnCo_23 > [image: View Samuel Cozannet's profile on LinkedIn] > <https://es.linkedin.com/in/scozannet> > > On Mon, May 16, 2016 at 10:10 PM, Marco Ceppi <marco.ce...@canonical.com> > wrote: > >> 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 11:19 AM Cory Johns <cory.jo...@canonical.com> >> wrote: >> >>> 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 with layers and layer APIs that's now more possible than ever. >>> >>> Once we have a simplified interface, I do think that the review process >>> should strongly recommend that monitoring support be included, though I >>> don't think we'll be able to make it a hard requirement. >>> >>> On Mon, May 16, 2016 at 10:06 AM, Tom Barber <t...@analytical-labs.com> >>> wrote: >>> >>>> 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 have capability >>>> already in Nagios for a more in depth NPRE make sure its available for >>>> those who want to monitor it, procrunning as well for alarms. >>>> >>>> My point being, I guess, is considering how much Juju tries to do at an >>>> application level for sys admins, why shouldn't monitors.yaml be required >>>> OOTB? >>>> >>>> Don't get me wrong this was just a brief convo we had and I'm sure >>>> there are plenty of reasons against it, but monitoring, which is more than >>>> just "is my box alive" type monitoring, would seem pretty important and >>>> having people tack stuff on manually to a NPRE setup seems to get away from >>>> the Juju ethos somewhat. >>>> >>>> Tom >>>> >>>> -------------- >>>> >>>> Director Meteorite.bi - Saiku Analytics Founder >>>> Tel: +44(0)5603641316 >>>> >>>> (Thanks to the Saiku community we reached our Kickstart >>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/> >>>> goal, but you can always help by sponsoring the project >>>> <http://www.meteorite.bi/products/saiku/sponsorship>) >>>> >>>> On 16 May 2016 at 14:52, Charles Butler <charles.but...@canonical.com> >>>> wrote: >>>> >>>>> 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 >>>> >>>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
