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
