[GitHub] gamefundas commented on issue #1364: Recommended architecture for micro services

[GitBox <gi...@apache.org>]

gamefundas commented on issue #1364: Recommended architecture for micro services
URL: https://github.com/apache/incubator-skywalking/issues/1364#issuecomment-397936584
 
 
   By APM infrastructure I meant, skywalking modules comprised of Zk, Collector and ES. I am getting a good feel about how these components can discover themselves and form the quorum. This is perfect.
   
   However the common problem that we have come across in our AWS VPC is that every hosted component is ephemeral in nature. They don't retain any state and in case of redeployments or failover they tend to come up as a new host, including new IP's. Now when we deploy the APM modules they are bound to have the same ephemeral nature. In case of a tear down/infra rebuild, due from datacenter failover, maintenance or upgrades, in some cases new hosts for Zk, Collector etc will be created and they are bound to have brand new IP's assigned.
   
   Now all of a sudden the 100 odd skywalking java agents are going to freak out as there is no known Collectors available. Cant discover either as IP's of all Collectors have changed. At this point I don't see any other way than restart all my 100 applications (use puppet or ansiable) so that they register the new Collector IP's in the agent.conf.
   
   If only we had a light weight stateless collector agent on each of these application hosts, they could have been restarted instead and the application is always configured to talk to this local collector agent. Sorry if I haven't been able to provide enough context on this issue.
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services