fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

Based on the way the data-points appear to be collected, there is
definitely a point where monitoring the nodes will become too intense for a
node sharing roles (or even a single node) (I've personally overloaded most
monitoring systems in default configurations with ~200 nodes.) However a
single pane of glass to view all clusters is extremely important to the
operations teams. It is therefor necessary for us to be able to specify an
existing Zabbix server that may be deployed elsewhere, or even completely
outside the scope of fuel.

So to get down to it. we should be able to (1) install Zabbix as a role (2)
separately of the Zabbix role configure Zabbix agents on nodes inside a
cluster to point to a Zabbix node. (3) if a Zabbix role is defined in the
cluster assume that it should be used to configure (2) but allow it to be
replaced anyway.



On Fri, Feb 14, 2014 at 11:42 AM, David Easter <deaster@xxxxxxxxxxxx> wrote:

> Good observation!  For a situation where the tenant for each cloud were
> the same, that would certainly make sense, yes.  Perhaps that should even
> be the default if it doesn’t impact the abilities of the Fuel Master node.
>  I.e. install the Zabbix server on the Fuel Node by default and the Zabbix
> agents pointing back to the Fuel Master Node by default.  If the operator
> decides that a given environment needs its own dedicated Zabbix server,
> the operator could add a role on an existing node, or a standalone node,
> for a Zabbix server and all agents in the environment would then point to
> that deployed server.  Then the URL for the deployed Zabbix server would
> properly appear when the environment were opened.
>
> In answer to your question, though; were a service provider (or large IT
> organization) to create clouds for its customers, it may make more sense
> to provide a monitoring service that the customer could draw from
> independently of other customers.  Or in instances where the clouds are
> highly separated from each other in terms of data content or internal
> departments.  By creating a Zabbix server per environment, this would
> address issues of ensuring isolation of access and data.
>
> Thanks,
>
> - David J. Easter
>   Product Line Manager
>
>
>
> On 2/14/14, 11:32 AM, "Dmitry Borodaenko" <dborodaenko@xxxxxxxxxxxx>
> wrote:
>
> >What about deploying Zabbix on the Fuel node itself?
> >
> >In a scenario where a large number of OpenStack environments is
> >deployed from the same Fuel node, I'm struggling to come up with a
> >scenario where operator would prefer to have a separate monitoring
> >server for each environment, instead of monitoring all environments
> >from a single pane of glass.
> >
> >-DmitryB
> >
> >
> >On Fri, Feb 14, 2014 at 9:08 AM, David Easter <deaster@xxxxxxxxxxxx>
> >wrote:
> >> Correct.  Just to understand, there’s growing concern from our customer
> >> base about how many servers they need in an OpenStack environment that
> >> don’t add to the compute power of the environment.  We already require
> >>the
> >> Fuel Master Node on its own server, so _requiring_ a Zabbix node of its
> >> own will be more difficult to justify - especially in small environments
> >> (5-10 servers).
> >>
> >> While it is completely proper to point out that individual services
> >>_can_
> >> (and perhaps should) be installed on their own nodes for performance
> >> reasons, the option to combine them with other roles on the same server
> >> needs to be an option when performance is not an issue.  In other
> >>words, I
> >> should be able to have a Zabbix server running on the same server as my
> >> compute or controller function.  I should also be able to install it on
> >> its own standalone server if I’m concerned about performance.
> >>
> >> Thanks,
> >>
> >> - David J. Easter
> >>   Product Line Manager,  Mirantis
> >>
> >>
> >> On 2/13/14, 7:49 AM, "Matthew Mosesohn" <mmosesohn@xxxxxxxxxxxx> wrote:
> >>
> >>>Dmitry,
> >>>
> >>>I think it would be logical to say that it should be trivial to
> >>>reinstall a separate Zabbit node since it doesn't contain any data
> >>>critical to the production environment. I think if you can remove and
> >>>add a new zabbix server to a deployed environment, it would meet a lot
> >>>of our users' needs.
> >>>
> >>>
> >>>On Thu, Feb 13, 2014 at 6:54 PM, Dmitry Nikishov <nikishov.da@xxxxxxxxx
> >
> >>>wrote:
> >>>> Matthew,
> >>>> It should be possible to install Zabbix alongside with OpenStack
> >>>>components
> >>>> on a controller, compute etc. However, Zabbix isn't an OpenStack
> >>>>component,
> >>>> it does not directly affect cluster. So there's no need to combine it
> >>>>with
> >>>> other roles or making it high-available. It makes sense to install it
> >>>>on a
> >>>> separate node.
> >>>>
> >>>> Bogdan,
> >>>> I like the idea of combining metering, monitoring and logging on one
> >>>>node.
> >>>> However, I think it would be better to have separate roles for all
> >>>>three of
> >>>> them. But these roles should not conflict with each other. This way it
> >>>>will
> >>>> be more customizable.
> >>>>
> >>>> 2014-02-13 16:07 GMT+03:00 Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>:
> >>>>
> >>>>> On 02/13/2014 02:33 PM, Matthew Mosesohn wrote:
> >>>>> > Dmitry,
> >>>>> >
> >>>>> > I have two questions:
> >>>>> > 1 - Can Zabbix Server Role be combined with any other role? (like
> >>>>> > controller)
> >>>>> > 2 - Can Zabbix be set up in HA (even in active/passive)? What are
> >>>>>the
> >>>>> > obstacles?
> >>>>> >
> >>>>>
> >>>>> And even if it cannot, I believe the good point is to use it as
> >>>>> Monitoring & Metering & Logging node, see my comments inside the doc.
> >>>>>
> >>>>> > On Thu, Feb 13, 2014 at 4:28 PM, Дмитрий Никишов
> >>>>><nikishov.da@xxxxxxxxx>
> >>>>> > wrote:
> >>>>> >> Hello everyone.
> >>>>> >>
> >>>>> >> I've been working on Zabbix integration for a while now, and I'd
> >>>>>like
> >>>>> >> know
> >>>>> >> what do you guys think about it.
> >>>>> >>
> >>>>> >> The specification:
> >>>>> >>
> >>>>> >>
> >>>>>
> https://docs.google.com/document/d/1g9xtBrgwgpeNV5YYxTMFu2h-yIK_PC1ZJD
> >>>>>mw
> >>>>>84RquJk
> >>>>> >>
> >>>>> >> Changes to fuel-library so far:
> >>>>>https://review.openstack.org/#/c/73254/
> >>>>> >> Changes to fuel-main and fuel-web will be coming soon.
> >>>>> >>
> >>>>> >> There is an open question related to UI - parameter validation:
> >>>>> >> - there should be only one zabbix-server node
> >>>>> >> - "Install Zabbix" checkbox should only be available if there is a
> >>>>>node
> >>>>> >> with
> >>>>> >> "zabbix-server" role
> >>>>> >>
> >>>>> >> --
> >>>>> >> Regards
> >>>>> >> Dmitry Nikishov
> >>>>> >>
> >>>>> >> --
> >>>>> >> Mailing list: https://launchpad.net/~fuel-dev
> >>>>> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>>>> >> Unsubscribe : https://launchpad.net/~fuel-dev
> >>>>> >> More help   : https://help.launchpad.net/ListHelp
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>> Bogdan Dobrelya,
> >>>>> Skype #bogdando_at_yahoo.com
> >>>>> Irc #bogdando
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Regards
> >>>> Dmitry Nikishov
> >>>
> >>>--
> >>>Mailing list: https://launchpad.net/~fuel-dev
> >>>Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>>Unsubscribe : https://launchpad.net/~fuel-dev
> >>>More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> --
> >> Mailing list: https://launchpad.net/~fuel-dev
> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~fuel-dev
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >--
> >Dmitry Borodaenko
>
>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
If google has done it, Google did it right!