You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Martin Harris <ma...@cloudsoftcorp.com> on 2015/07/08 16:37:50 UTC
Brooklyn server monitoring
Hi Folks,
I hit an issue with a customer installation where the disk had filled up as
the nohup.out file created by the launch command in the docs had grown
until it filled the disk. I've created a PR here[1] for this issue
It was also suggested that it would be nice to have some way to indicate
the issue (or other potential issue) in the GUI. I've did a quick spike
here [2] of a mechanism for making this available via the REST API
I was discussing it with @aledsage, and he suggested that some work had
been done at some point to represent the Brooklyn server itself as an
Entity. This would then allow us to follow the sensor-effector-policy
pattern that we use for deployed blueprints. Anyone have any thoughts on
this?
As for how it would be displayed in the GUI, I think that simply adding it
to the 'Application' list would be confusing, but we could add another
top-level tab for 'Server', which would then have the usual 'Summary',
'Sensors', 'Effectors' etc tabs. Hopefully we could re-use some of the GUI
code (@samcorbett, would this be practical?) and we could follow the same
pattern for the API. Again, anyone have any thoughts on this?
[1]: https://github.com/apache/incubator-brooklyn/pull/739
[2]: https://github.com/nakomis/incubator-brooklyn/tree/server-monitor
Cheers
M
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: Brooklyn server monitoring
Posted by Adrián Nieto <ad...@lcc.uma.es>.
Hello,
This was pointed as an open issue by myself some time ago,
https://issues.apache.org/jira/browse/BROOKLYN-7 as I found very
interesting to be able to monitor Brooklyn Server by using the existing
code on Brooklyn to monitor the entities.
I would like to share with you a remark about adding the monitoring view
(which is already planed in the new dashboard proof of concept) to
Brooklyn (not only to monitor the server but the applications). Brooklyn
provides a very generic "Sensor" concept which mixes the sensors that
output metrics with the ones who don't.
In SeaClouds Project we already filter the sensors manually, but it
would be nice to allow Brooklyn to differentiate between the sensors
which outputs metrics and other kind of sensors. This will let
eventually Brooklyn to save even historical data and show them with nice
plots.
El 08/07/2015 a las 16:46, Alex Heneveld escribió:
>
> Martin-
>
> Super idea.
>
> I think we could show a few more things in the Server tab -- including
> the persistence subsystem status and any rebind issues -- but following
> the pattern you describe where these individual components have a
> sensor/effector api and use the same gui representation.
>
> Best
> Alex
>
>
> On 08/07/2015 15:37, Martin Harris wrote:
>> Hi Folks,
>>
>> I hit an issue with a customer installation where the disk had filled
>> up as
>> the nohup.out file created by the launch command in the docs had grown
>> until it filled the disk. I've created a PR here[1] for this issue
>>
>> It was also suggested that it would be nice to have some way to indicate
>> the issue (or other potential issue) in the GUI. I've did a quick spike
>> here [2] of a mechanism for making this available via the REST API
>>
>> I was discussing it with @aledsage, and he suggested that some work had
>> been done at some point to represent the Brooklyn server itself as an
>> Entity. This would then allow us to follow the sensor-effector-policy
>> pattern that we use for deployed blueprints. Anyone have any thoughts on
>> this?
>>
>> As for how it would be displayed in the GUI, I think that simply
>> adding it
>> to the 'Application' list would be confusing, but we could add another
>> top-level tab for 'Server', which would then have the usual 'Summary',
>> 'Sensors', 'Effectors' etc tabs. Hopefully we could re-use some of the
>> GUI
>> code (@samcorbett, would this be practical?) and we could follow the same
>> pattern for the API. Again, anyone have any thoughts on this?
>>
>> [1]: https://github.com/apache/incubator-brooklyn/pull/739
>> [2]: https://github.com/nakomis/incubator-brooklyn/tree/server-monitor
>>
>> Cheers
>>
>> M
>>
>
>
Re: Brooklyn server monitoring
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
Martin-
Super idea.
I think we could show a few more things in the Server tab -- including
the persistence subsystem status and any rebind issues -- but following
the pattern you describe where these individual components have a
sensor/effector api and use the same gui representation.
Best
Alex
On 08/07/2015 15:37, Martin Harris wrote:
> Hi Folks,
>
> I hit an issue with a customer installation where the disk had filled up as
> the nohup.out file created by the launch command in the docs had grown
> until it filled the disk. I've created a PR here[1] for this issue
>
> It was also suggested that it would be nice to have some way to indicate
> the issue (or other potential issue) in the GUI. I've did a quick spike
> here [2] of a mechanism for making this available via the REST API
>
> I was discussing it with @aledsage, and he suggested that some work had
> been done at some point to represent the Brooklyn server itself as an
> Entity. This would then allow us to follow the sensor-effector-policy
> pattern that we use for deployed blueprints. Anyone have any thoughts on
> this?
>
> As for how it would be displayed in the GUI, I think that simply adding it
> to the 'Application' list would be confusing, but we could add another
> top-level tab for 'Server', which would then have the usual 'Summary',
> 'Sensors', 'Effectors' etc tabs. Hopefully we could re-use some of the GUI
> code (@samcorbett, would this be practical?) and we could follow the same
> pattern for the API. Again, anyone have any thoughts on this?
>
> [1]: https://github.com/apache/incubator-brooklyn/pull/739
> [2]: https://github.com/nakomis/incubator-brooklyn/tree/server-monitor
>
> Cheers
>
> M
>
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.