How to group pods data with namespace?

Justin

Hello,

I have some observations and questions about the lpar2rrd on Kubernetes.

- I see that the pods(and containers) data are just all displayed under "pods" in webpage.
   Usually there are multiple namespaces in the cluster.
   Could lpar2rrd add a layer of namespace, then display pods under each namespace?

- In our lab we have multiple namespaces and total pod number is 700+.
   After about 45 hours, the stored data size is about 124G Bytes. The data size increased really too fast.
   I'm not sure how can we utilize it effectively to monitor clouds in long duration, such as for weeks or months?
   Could you share some ideas? 


Kind Regards,
Justin

Matej

Hi Justin,

we are working on adding namespaces.  

What version of the LPAR2RRD do you have? You can disable containers monitoring in Kubernetes configuration. (Containers statistics can occupy 30% of data space). We are also working on the possibility of monitoring only nodes and namespaces.

Regards,

Matěj

Justin

Hi Matej,

Thanks for your answers and nice supports! 

I used the LPAR2RRD docker image downloaded from https://hub.docker.com/r/xorux/lpar2rrd,
with the tag of "7.3.0".

Kind Regards,
Justin

Justin

Hi Matej,

I think of the option to disable containers. Yes it can help reduce the stored data size,
but the container statistics is usually an important part of the metrics.

Is it possible to add one option for users to select which namespaces to monitor?
It would be much more friendly, and I expect the store data size can also be reduced.

Kind Regards,
Justin

Justin

Hello Matej,

I'd like to raise another observation about how to configure Kubernetes in LPAR2RRD.
Currently it provides input of protocol and endpoint, and endpoint format is "ip:port".
But there could be some API path suffix such as "ip:port/proxy/apiserver".

Is it possible to add the API path suffix in the endpoint?

Kind Regards,
Justin

Matej

Hi Justin,

the idea of ​​selecting namespaces in the configuration is good and will be implemented.

We haven't tried API path suffix yet, but if the request responds to the "ip:port/suffix/api/v1/nodes", it will work.

Regards,

Matěj