Multicluster metrics

I’m testing the multicluster mesh (multiple control plane configuration) and noticed that requests leaving the origin cluster mesh are tagged as destination_workload:unknown and request entering the destination cluster mesh are tagged with source_workload:unknown. (As well as all the source/destination tags.)

Is there some way to get the real source/destination to pass across the gateway?

Can you post which version of Istio you are testing with? And can you confirm the config for your kubernetesenv adapter?

Testing with 1.1.0-snapshot.6.

The kubernetesenv adapter is unchanged from the generated config:

kind: handler
  name: kubernetesenv
  namespace: istio-system
    app: mixer
    chart: mixer
  compiledAdapter: kubernetesenv

(Hopefully that’s what you were looking for?)

Also, cluster local services show up as expected in the tags.

Can you try adding the multicluster config params to that spec?

Ah, wait… you specified multiple control plane configuration, corrrect?

If you aren’t configuring API Server access to all API Servers in your multi-cluster setup, then each adapter is not going to be able to lookup information on workloads outside of its own cluster. That means labels on pods, and deployment info, etc. I think we can improve on that in the future, but there isn’t a good way to easily workaround that at the moment.


This is what I was guessing from understanding the architecture.

What’s the best way to move forward with this? I’d love to see this area improved. As it stands now, the multiple control plane configuration handles the communication ok but it’s missing a lot of what the mesh can provide.

Raise an issue at the P&T WG meeting and follow-up with an issue in Github. Improving multi-cluster support, in all of its different flavors, is definitely an area that we’d like to focus on post-1.1. We should coordinate with the environments folks a bit too, to properly prioritize.