Hi Jing, I recently joined Ververica and started looking into FLIP-102. I'm trying to figure out how we would implement the proposal on the backend side. I looked into the proposal for the REST API response and a few questions popped up: - Is there a reason for us to introduce a nested structure TaskManagerMetricsInfo in the response object? I would rather keep it consistent in a flat structure instead, i.e. having all the members of TaskManagerResourceInfo being members of TaskManagerMetricsInfo. Alternatively, one could think of grouping the metrics collecting the different values (i.e. max, used, committed) per metric in a JSON object. But this would apply for all the other metrics of TaskManagerMetricsInfo as well. - metrics.resource.managedMemory and metrics.resource.networkMemory have counterparts in metrics.networkMemory[Used|Total] and metrics.managedMemory[Used|Total]: Is this redundant data or do they have different semantics? - Is metrics.resource.totalProcessMemory a basic sum over all provided values? I see the necessity to have this member if we decide to not provide the memory usage for all memory pools (e.g. providing Metaspace but leaving Code Cache and Compressed Class Space as Non-Heap pools out of the response). Otherwise, would it be worth it to remove this member from the response for simplicity reasons since we could sum up the memory on the frontend side?
Best, Matthias -- Sent from: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/
