Hi Lukas, Not sure I follow. The Marvel plugin has to be installed on all nodes in cluster A and on nodes in cluster B (with the agent disabled). To view the data you would open http://node_from_cluster_B:9200/_plugin/marvel , so if something goes wrong with A, you still have access to the data.
Makes sense? Cheers, Boaz On Thursday, January 30, 2014 8:27:32 AM UTC+1, Lukáš Vlček wrote: > > Hi, > > first of all, congrats for Marvel release. Step in the right direction. > > I have some questions: If I understand correctly, as of now Marvel has to > run in the cluster that it collects metrics from (as a plugin). Let's call > this cluster A. It is recommended for production env to have the Marvel > store the metrics to a different cluster. Let's call it B. Now, does it in > fact mean that in order to browse collected metrics (that are stored in B) > the client has to have an access to at least one node of A? (I assume this > is necessary to download the Kibana based web app?). Or let me put it this > way: in case of critical state of cluster A client has to know which nodes > of A are responsive and able to serve the web app prior to investigating > historical data stored in B? If yes, is there any plan to get just the web > app as a standalone package (like zip, war ...) so that client does not > have to rely on cluster A to serve it? Am I misunderstanding the concept? > > Regards, > Lukas > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/fd46420c-2c72-43b7-9b95-0d8b7e81ed14%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
