All,
I would like add here that I did have two distinct, but related needs here;
1. Make PCP useful in an an elastic computing environment, where hosts
startup and die without an prior arrangement. This is true of any
virtual environment with an automated orchestration layer - AWS,
RackSpace, OpenStack, RHE, to name a fw.
2. Make PCP a bit more open. Currently, PCP is a complete echo system,
form the collection of data to its consumption via tools like pmie,
pmchart, pmlogsummary, etc;. I believe there is a need for PCP to
provide an easy hookup for others to consume the data collected by PCP.
A model where each host monitored by exports it's data to a defined
location, where an arbitrary listener/collector can consume it will
provide the opportunity for other tools to access this stream of data
online, and and use it as they see fit. In an AWS world, re-exporting
this data to CloudWatch is one such use case.
This can also be used to collate data exported from the automatically
instantiated hosts, and process/aggregate them for use in such a pseudo
cluster environment. For example in AWS, the data gathered from
instances within an Autoscaling group can be aggregated and exported to
CloudWatch, which can then make decision on scaling up or down based on
this data.
Regards
Chandana
On 18/04/13 08:58, Nathan Scott wrote:
3. Amazon Web Services [Chandana]
PCP model of remote loggers which explicitly know about all of the
hosts they need to log is mismatched to the needs of monitoring in
the AWS space. Here, hosts can be spun up and down in relatively
short time spans, and the remote pmlogger "pull" model is not what
is wanted - a "push" model where the host starts up and starts to
broadcast out data (including its hostname) to something listening
for such traffic is offered by collectd and is better suited.
|