[#222]:MCP edits

[Maskoff0]

Having to improve the MCP from a simple Prometheus query string adapater to a real MCP metrics server.

This are the changes made:

1. config instead of hardcoded URL
2. typed responses
3. real error handling
4. query_range support with start, end, and step fields

Important shifting to giving time series reponse.

Any recommendations or criticsm welcomed...

[LorenzoTettamanti]

Hi @Maskoff0, I found a potential issue related to this part of the code. I tested this patch with both k8s (minikube) and Docker, and while using Kubernetes, this line turns out to be a problem because the attached metadata are {command,job,container_id,k8s_pod_name,tgid} while in Docker environments we have the following metadata: {command,job,container_id,container_name,tgid}

For example:

• cortexbrain_enter_mem_alloc{command="storage-provisi",container_id="cb8e239f-7384-4f6a-a61a-f4ef71baddb3",job="cortexflow/cortexflow-metrics",k8s_pod_name="storage-provisioner",tgid="53748"}
  while with Docker the metadata is the following:
• cortexbrain_bytes_alloc_events_total{command="node",container_id="13b64ce3bcd6bac01fb2ce7d6478692c77d80638f665b86b58a21faa90ae5c1e",container_name="skyops-dashboard-app",job="unknown_service:cortexflow-metrics",tgid="573376"}

You can handle these cases by checking whether the Kubernetes API returns a response. If the kubernetes api returns a response, you can use the k8s_pod_name in the Prometheus query instead; if the kubernetes api doesn’t return a response, you can use the container name.

I used the same logic in the service_cache.rs file in the populate_map_with_pod_info function. With Client::try_default().await.is_ok() you can try to establish the connection to the API and from here you can handle the cases

What do you think?

[LorenzoTettamanti]

In case you can't access the service_cache.rs file you need to sync your main branch :)