+0.5 Hi Andrew. While I see the benefit of moving those sensors to the `SoftwareProcess` (which I quite like), that can lead to incorrect policies' trigger when multiple `SoftwareProcess` will grouped into a `SameServerEntity`. That's my only concern about this change.
Now, the question is: what is the most common use-case? If using a policy watching those sensors on multiple entities grouped into a `SameServerEntity` is (or will be?) an edge case, then OK. Otherwise, @Svet suggestion might be the way to go. My £0.02. Best. On Thu, 16 Jun 2016 at 09:35 Svetoslav Neykov < [email protected]> wrote: > +1 > > I think attaching an enricher would be a better approach than activating > the polling through a config key, but not sure how feasible that is. > > Svet. > > > > On 16.06.2016 г., at 11:13, Andrew Kennedy < > [email protected]> 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. > > -- > > > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > > -- Thomas Bouron • Software Engineer @ Cloudsoft Corporation • http://www.cloudsoftcorp.com/ Github: https://github.com/tbouron Twitter: https://twitter.com/eltibouron
