brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Corbett <sam.corb...@cloudsoftcorp.com>
Subject Re: Machine Metrics
Date Thu, 16 Jun 2016 09:41:21 GMT
I share your concern that the placement of the feed is wrong. I feel 
like we would be bending Brooklyn's abstractions to fit the case rather 
than working out a better abstraction. Of course, deciding what data 
reflects a software process is subjective and as you point out we 
already break the encapsulation in a variety of places. Was the plan not 
always to make locations into entities too? This would be trivial if 
that were the case.

I also think we're continually making SoftwareProcess too important. 
Svet's suggestion of an enricher is a good one - I want to explicitly 
mix the capability in to entities, not enable it with a flag.

Sam


On 16/06/2016 09:13, Andrew Kennedy wrote:
> Hi.
>
> For the project I am working on, we would like to use the CPU utilization
> as one of the metrics for scaling a cluster. The existing `MachineEntity`
> has a sensor feed that produces this data, along with uptime and memory
> usage information. The feed works on Linux VMs only, currently, as is uses
> SSH commands on the host to generate the values i.e. the `uptime` command,
> or the contents of files in `/proc/`.
>
> I would like to propose moving the feed to `SoftwareProcess` so that it is
> available to all entities. It would be disabled normally, set by a
> `ConfigKey<Boolean>` flag. This would be named "metrics.machine.retrieve"
> to correspond to "metrics.usage.retrieve" which enables sensors in feeds
> that return application or process specific information. The
> `MachineEntity` would obviously have the default value set to "true", to
> maintain current behaviour.
>
> The only issue with this change is that the placement of the sensor feed
> feels slightly wrong. These are returning data about the _machine_ but the
> entity represents a _process_ on that machine, and there may in fact be
> multiple entities sharing a single machine, via `SameServerEntity`. The
> `MachineEntity` is used to represent a VM without any applications running
> on it, and would not normally be part of a blueprint, so these sensors are
> not normally accessible. There is some precedent for placing machine data
> on an entity, such as the `HOSTNAME` sensor, so I think the break in
> encapsulation is quite small.
>
> The PR containing the change is here:
>
> - https://github.com/apache/brooklyn-server/pull/204
>
> I'd appreciate any comments on whether this is a useful change, as well as
> a review of the pull request...
>
> Thanks,
> Andrew.


Mime
View raw message