Hi Akila,
On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <raviha...@wso2.com
> wrote:
> Hi Raj,
>
> We can use the same CEP stream to publish cartridge agent health stats. We
> can identify the instance type (container or VM type) by retrieving member
> properties from the topology. But I don't think we should be doing that.
>
Current stream definition is as below,
<streamDefinition name="cartridge_agent_health_stats" version="1.0.0">
<description>agent health stats</description>
<nickName>agent health stats</nickName>
<metaData>
</metaData>
<correlationData>
</correlationData>
<payloadData>
<property name="cluster_id" type="String" />
<property name="network_partition_id" type="String"/>
<property name="member_id" type="String" />
<property name="partition_id" type="String" />
<property name="health_description" type="String"/>
<property name="value" type="double"/>
</payloadData>
</streamDefinition>
We don't have partition id and network partition id in docker scenario. If
we use the same stream, are we going to publish dummy values for these two
attributes? Also, if we are using the same stream, we need to introduce
another attribute to distinguish whether the data is coming from a docker
cluster or vm cluster. Then, we need to use that attribute in the execution
plans to process the stream in different ways based on the type of cluster
(docker or vm).
In future, we may need to publish some additional attributes from docker
containers to the CEP. If we use the same stream, we will be always
publishing some unwanted attributes in both scenario.
WDYT?
>
> IMO, we should not publish cartridge agent health stats from each and
> every container. It's better if we can have a global agent per Kubernetes
> host instance to monitor the health of every container and also in host
> instance itself. We can use a container monitoring agent like cAdvisor to
> collect container health stats.
>
> +1 for having a separate CEP execution plan for handling Docker containers
> scenario.
>
> As for the ContainerClusterMonitor, we should clearly outline the
> responsibilities of container monitor and VM monitor. Because since we are
> using Kubernetes for managing the life-cycle of containers, most of the
> tasks are already taken care of. For eg - we don't need to start a new
> container if an existing containers fails since Kubernetes will handle that
> failure.
>
> WDYT?
>
--
Rajkumar Rajaratnam
Software Engineer | WSO2, Inc.
Mobile +94777568639 | +94783498120
