brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Macartney <>
Subject Re: Machine Metrics
Date Thu, 16 Jun 2016 10:53:02 GMT
I agree with Sam and Svet, + 1 to making it an enricher, if possible, or at least somehow keeping
it separate from SoftwareProcess.

Gnu PGP key -

> On 16 Jun 2016, at 10:41, Sam Corbett <> wrote:
> 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:
>> -
>> I'd appreciate any comments on whether this is a useful change, as well as
>> a review of the pull request...
>> Thanks,
>> Andrew.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message