juju and monitoring systems

I like juju (and already use it to provide predefined vps with wordpress etc) and i like prometheus monitoring system. Does juju devs have any plans to export metrics to prometheus? Or somebody who use juju and prometheus? Also does juju running on machines or on the state server have ability

Unit number is increasing in latest juju version.

Hi, We have found in juju 1.25.0.1 version that each time service gets deployed unit number is increased like below. "service-name/1, service-name/2, service-name/n.." Earlier juju versions everytime we would deploy unit number would be same as "service-name/0". Due to this change our

Re: Unit number is increasing in latest juju version.

Hi Sunitha, I believe you can do the following: unit_manager_0 = self.d.sentry["ibm-mobilefirst-server"][0] Does that resolve the problem? Many thanks Matty On Fri, Nov 13, 2015 at 9:50 AM, Sunitha Radharapu wrote: > Hi, > > We have found in juju *1.25.0.1* version

Re: Unit number is increasing in latest juju version.

OK. So I suspect the tests were written to reuse the environment because bootstrapping takes time. The good news is, we'll shortly get instant environment creation, so a clean environment will be cheap and fast. :) Mark On 13/11/15 10:02, Matthew Williams wrote: > Hi Mark, Sunitha, > > My

Re: Unit number is increasing in latest juju version.

Hi Sunitha, The bug is closed, it was fixed and released in juju 1.25. There are some docs at the below link that summarise the behaviour: https://jujucharms.com/docs/1.25/reference-numbering If you'd like to have a talk about this I'd be very happy to. I'm mattyw on irc in #juju and #juju-dev

Re: Unit number is increasing in latest juju version.

This is something I raised with Marco, Matt and Chuck while in the Charmers Summit. There are several mixed opinions with regards to this, some say it's logical because each unit in an environment is unique, however it's not how Juju used to behave, hence breaking most of the tests in the store,

Re: Unit number is increasing in latest juju version.

On 13 November 2015 at 15:02, Matthew Williams wrote: > Hi Mark, Sunitha, > > My apologies, I should have included the explanation in the original email. > > This was a change to address a long standing bug: > https://bugs.launchpad.net/juju-core/+bug/1174610 Ah -

Re: juju and monitoring systems

As promised, here's the Zabbix bits along with some additional info: Start from here : https://github.com/thomnico/juju-nfv-clearwater-restcomm https://www.youtube.com/watch?v=IF7bUgDCYMM https://github.com/SaMnCo/ob-zabbix Direct commentary from the developer(s): the ob-zabbix is important

Re: Unit number is increasing in latest juju version.

Hi Mark, Sunitha, My apologies, I should have included the explanation in the original email. This was a change to address a long standing bug: https://bugs.launchpad.net/juju-core/+bug/1174610 There's a discussion in the bug report, but the summary is that in most cases it's desirable to have

Re: Unit number is increasing in latest juju version.

Hi Matt, I am a little bit confused here, bug description says it should be as unique id. If it is a bug and you are going to fix in future juju releases then we no need to change our amulet tests. If it is a new feature then we will change our upcoming charms accordingly, Thanks, Sunitha.

Re: Unit number is increasing in latest juju version.

Regardless of the outcome of the bug, the proper syntax for accessing units is as follows: self.d.sentry["ibm-mobilefirst-server"][0] This is because, our new testing environment and soon to be normal testing procedure for all charms while we wait for multi-model environments recycles the

[Review Queue] - Nuage VSRG

I took some time to look at the Nuage VSRG charm today, it is a solid first round submissino but needs additional work. -1 for now but i'm confident it will be ready soon https://bugs.launchpad.net/charms/+bug/1510672 Charles Butler - Juju Charmer Come see the

Announcing Ubuntu at Google Code-In!

Hello everyone, You may have seen me asking some stuff re: Google Code-In (GCI for short) on the IRC channel lately. Ubuntu applied to be one of the mentor organizations this year, and we just got the great news that we have been accepted into the contest! Here, the organization publishes

Re: juju and monitoring systems

Vasilily, I've been taking a deep look at prometheus lately - namely due to the claim of their top end benchmark of 360 thousand metric ingests per second on a beefy modern host. This intrigued me as to the use cases for prometheus. And seeing it being baked into the k8s apiserver for metric

Re: juju and monitoring systems

2015-11-13 17:33 GMT+03:00 Charles Butler : > Vasilily, > > I've been taking a deep look at prometheus lately - namely due to the claim > of their top end benchmark of 360 thousand metric ingests per second on a > beefy modern host. This intrigued me as to the use

Re: juju and monitoring systems

On Fri, Nov 13, 2015 at 9:42 AM, Vasiliy Tolstov wrote: > May be the best look at https://github.com/prometheus/node_exporter > for by default enabled metrics. > This sounds like a prime case for a charm, and then wrapping your business logic for scaling into a charm that

Re: Musings around environments, cloud credentials, and the new Juju Controllers

On 13 November 2015 at 12:58, Rick Harding wrote: > The goal is to get the user onto 'best practices' out of the box and > deploying into the controller environment isn't best practice since it's no > longer as easily transient. If you bootstrap, deploy something to

Re: juju and monitoring systems

Awesome to hear you're enjoying Juju Vasiliy. We don't currently have plans to build monitoring directly into Juju. We've found most places have their preferred tool for that, zabbix, munin, nagios, etc. We love that folks have built charms that allow integration of their preferred tool through