CzyerChen commented on PR #12109: URL: https://github.com/apache/skywalking/pull/12109#issuecomment-2059351595
> > > > > That rule should base on k8s deployment. Not VM. > > > > > > > > > > > > ActiveMQ agent side set Tags.MQ_BROKER = raw IP address:port, rather than hostname:port > > > > in K8S: ACTIVEMQ-SERVER(ip:port) -> VIRTUAL_MQ( ip:port ) : support service hierarchy VIRTUAL_MQ( ip:port ) -> ACTIVEMQ cluster monitoring(activemq.skywalking-showcase) : can not support service hierarchy ACTIVEMQ cluster monitoring(activemq.skywalking-showcase) -> K8S_SERVICE(skywalking-showcase::activemq.skywalking-showcase): support service hierarchy > > > > > > > > > About this, in k8s, > > > > > > * VIRTUAL_MQ( ip:port ) could be service name, is the activeMQ plugin(Java agent) resolving the Domain name and gets the IP? > > > * `ACTIVEMQ cluster monitoring(activemq.skywalking-showcase)` should be k8s service name, right? > > > > > > yes > > Let's separate this in two ways. > > 1. Service hierarchy is still working if you are building ActiveMQ server monitoring with K8s service monitoring. The hierarchy between those two isn't affected by the agent use case. > 2. About the agent is reporting the service IP, is this a good practice? I am thinking this because usually virtual MQ should be a logic concept, if the MQ is restarted by k8s, the IP could change, but DNS name would not. Nowadays, k8s deployment is very popular, and it is the key use case of the hierarchy feature, we only need to focus on that. How about add `remote.ip` tag for the actual IP, and use `peer` for domain name? Now part1 supported:  part2 agent side needs to upgrade    -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@skywalking.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
