fuel-dev team mailing list archive

[Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>]

Yes, in use case #4 we are not deploying Zabbix server itself, but
configuring existing remote Zabbix instead.

--
Roman Zhnichkov



On Wed, Feb 19, 2014 at 11:34 PM, Dmitry Borodaenko <
dborodaenko@xxxxxxxxxxxx> wrote:

> David,
>
> As far as I understand the difference between #4 and #1 is that in the
> case of #4 Zabbix server is not deployed by Fuel (pre-existing
> monitoring server), so our job is to collect the server details from
> the operator and configure Zabbix agents to report to that server.
>
> -DmitryB
>
> On Wed, Feb 19, 2014 at 6:56 AM, David Easter <deaster@xxxxxxxxxxxx>
> wrote:
> > Use cases 1 & 2 are fine for MVP in the first release, yes.
> >
> > Would the mechanism for deploying use case #4 be the same as use case #1
> –
> > just configuring the server to monitor agents in multiple clouds?
> >
> > Thanks,
> >
> > - David J. Easter
> >   Product Line Manager,  Mirantis
> >
> > From: Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>
> > Date: Wednesday, February 19, 2014 at 4:30 AM
> > To: David Easter <deaster@xxxxxxxxxxxx>
> > Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> > Subject: Re: [Fuel-dev] Zabbix feature review request
> >
> > Guys,
> >   in other words there are several use cases for Zabbix server placement:
> >
> > Zabbix server as separate role on dedicated hardware
> > Zabbix server role combined with some other role (compute or storage,
> since
> > Zabbix uses MySQL, so we don't want to mix OpenStack and Zabbix data in
> the
> > same DB)
> > Zabbix server on fuel-master
> > Remote Zabbix server outside of OpenStack environment
> > Combination of any of 4 previous items (for example, we have Zabbix
> server
> > on fuel-master monitoring all existing environments and some other Zabbix
> > servers monitoring particular OpenStack environments)
> >
> > Also we have general requirements:
> >
> > HA for Zabbix server
> > Dynamic configuration (automatic node deletion when removing node from
> the
> > environment, requires orchestration patching)
> >
> > As MVP I propose to have use cases 1 and 2 implemented (Zabbix server as
> > separate role ans Zabbix server role combined with compute or storage)
> with
> > dynamic configuration requirement.
> >
> > Use cases 3-5 as well as HA for Zabbix are subject to further
> > implementation.
> >
> > We'll update the specification according with that.
> >
> > Any comments or suggestions?
> >
> >
> > --
> > Roman Zhnichkov
> >
> >
> >
> > On Tue, Feb 18, 2014 at 8:21 PM, David Easter <deaster@xxxxxxxxxxxx>
> wrote:
> >>
> >> On 2/18/14, 4:23 AM, "Bogdan Dobrelya" <bdobrelia@xxxxxxxxxxxx> wrote:
> >>
> >> >On 02/18/2014 12:05 PM, Dmitry Nikishov wrote:
> >> >> From this conversation we got following points:
> >> >> 1. It should be possible to install zabbix as a separate role
> >> >> 2. Combining zabbix role with other roles should be supported as well
> >> >> 3. There should be support for configuring zabbix agents to point
> them
> >> >> to the remote zabbix server
> >> >> 4. Possible zabbix installation on fuel-master?
> >> >> 5. In case of one zabbix server monitoring multiple environments,
> nodes
> >> >> should be separated into hostgroups.
> >> >>
> >> >> Concerns:
> >> >> 1. perfomance when alot of nodes are being monitored by single server
> >>
> >> True.  We’d need to publish the maximum number of nodes that can be
> >> monitored efficiently by one server.  If the number of monitored nodes
> >> goes above that number, we’d recommend a dedicated server within the
> >> largest deployed cloud (for example) to split the burden.
> >>
> >> >> 2. if zabbix agents were configured to connect to the remote server
> >> >> (outside the environment), once this env gets deleted, it's nodes
> will
> >> >> be rebooted into bootstrap. However, they won't be deleted from
> zabbix.
> >> >> It's not clear how to remove them from zabbix server.
> >>
> >> We’d have to build in automation to do that for the user.  I.e. if a
> >> remote node is deleted, update the corresponding zabbix server’s info.
> >>
> >> >>
> >> >> Open question: if there will be support for zabbix on fuel-master,
> >> >> there
> >> >> should be an option either to enable or disable it somewhere in the
> >> >>fuelmenu
> >> >>
> >> >> Any thoughts?
> >>
> >> Configuration of the “local” zabbix server would need to be an option,
> >> yes.  It’s very possible that you’d have a situation where the “local”
> >> zabbix server is watching some clouds while a dedicated zabbix server
> >> within one of the deployed clouds is watching only the nodes within that
> >> cloud.  I.e. there can be a mixture.  Fuel would need to keep track of
> >> which nodes were being monitored by which server(s).
> >>
> >> >Looks like "2 - Can Zabbix be set up in HA (even in active/passive)?"
> >> >wasn't addressed by either of the points, e.g.:
> >> >- How can we configure HA zabbix in case of:
> >> >* one of the zabbix nodes is a master node?
> >> >* some of the zabbix nodes were externally configured by the user
> >> > himself?
> >> >* some of the zabbix nodes belong to the different envs and combined
> >> >with the another roles.
> >> >>
> >> >>
> >> >> 2014-02-15 1:16 GMT+04:00 Andrew Woodward <xarses@xxxxxxxxx
> >> >> <mailto: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
> >> >>     <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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_PC1Z
> >> >>>>>>>JD
> >> >>         >>>>>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
> >> >>         <mailto: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
> >> >><http://bogdando_at_yahoo.com>
> >> >>         >>>>> Irc #bogdando
> >> >>         >>>>
> >> >>         >>>>
> >> >>         >>>>
> >> >>         >>>>
> >> >>         >>>> --
> >> >>         >>>> Regards
> >> >>         >>>> Dmitry Nikishov
> >> >>         >>>
> >> >>         >>>--
> >> >>         >>>Mailing list: https://launchpad.net/~fuel-dev
> >> >>         >>>Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> >>         <mailto: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
> >> >>         <mailto: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
> >> >>         <mailto: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!
> >> >>
> >> >>     --
> >> >>     Mailing list: https://launchpad.net/~fuel-dev
> >> >>     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> >>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >> >>     Unsubscribe : https://launchpad.net/~fuel-dev
> >> >>     More help   : https://help.launchpad.net/ListHelp
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards
> >> >> Dmitry Nikishov
> >> >>
> >> >>
> >> >> This body part will be downloaded on demand.
> >> >>
> >> >
> >> >
> >> >--
> >> >Best regards,
> >> >Bogdan Dobrelya,
> >> >Skype #bogdando_at_yahoo.com
> >> >Irc #bogdando
> >> >
> >> >--
> >> >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
> >
> >
> >
> > --
> > 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
>