← Back to team overview

fuel-dev team mailing list archive

Re: Zabbix feature review request

 

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_PC1ZJDmw
>>>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




Follow ups

References