# Marvel architecture question

**URL:** <https://discuss.elastic.co/t/marvel-architecture-question/15490>\
**Category:** Elasticsearch\
**Created:** [January 30, 2014, 7:27am UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490 "2014-01-30T07:27:32Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Lukas\_Vlcek1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lukas_vlcek1/32/819_2.png) [@Lukas\_Vlcek1](https://discuss.elastic.co/u/Lukas_Vlcek1)\
**Post date:** [January 30, 2014, 7:27am UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490/1 "2014-01-30T07:27:32Z")

</div>

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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaRZ2sO-tcFNGcikzDX4qKK4jBKeYiY5CVNUxGP4CAc3g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaRZ2sO-tcFNGcikzDX4qKK4jBKeYiY5CVNUxGP4CAc3g%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Boaz\_Leskes](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/boaz_leskes/32/723_2.png) [@Boaz\_Leskes](https://discuss.elastic.co/u/Boaz_Leskes)\
**Post date:** [January 30, 2014, 10:32am UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490/2 "2014-01-30T10:32:47Z")

</div>

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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/fd46420c-2c72-43b7-9b95-0d8b7e81ed14%40googlegroups.com](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](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Lukas\_Vlcek1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lukas_vlcek1/32/819_2.png) [@Lukas\_Vlcek1](https://discuss.elastic.co/u/Lukas_Vlcek1)\
**Post date:** [January 30, 2014, 12:15pm UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490/3 "2014-01-30T12:15:36Z")

</div>

Ah, so the plugin needs to be installed on both clusters, I missed that  
part. Thanks for clarification.

BTW, is it required to have the plugin on both sides because the plugin on  
cluster B does more than just serving the web app in this case? Say, I want  
to monitor cluster A and store data into cluster B - thus I install plugin  
on cluster A and configure accordingly, but do not install the plugin on B,  
instead I just keep copy of the web app locally in case I would want to  
access the data in cluster B? Hope my question makes sense...

Regards,  
Lukas

On Thu, Jan 30, 2014 at 11:32 AM, Boaz Leskes [b.leskes@gmail.com](mailto:b.leskes@gmail.com) wrote:

> 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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/fd46420c-2c72-43b7-9b95-0d8b7e81ed14%40googlegroups.com](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](https://groups.google.com/groups/opt_out).

--  
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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaKBMZo\_zOEEczFqcHf7PndH%3DfOMOfbHM1\_G5Aq347z\_A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaKBMZo_zOEEczFqcHf7PndH%3DfOMOfbHM1_G5Aq347z_A%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [January 30, 2014, 8:17pm UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490/4 "2014-01-30T20:17:39Z")

</div>

My understanding is that the jar file that is part of the plugin is only  
needed on cluster A, while the \_site content is only needed on cluster B.

Without the jar file on cluster B, the agent does not need to be disabled  
since there is no code to disable. Cluster B should be able to continue  
ingesting content if Marvel is indeed using the standard API.

--  
Ivan

On Thu, Jan 30, 2014 at 4:15 AM, Lukáš Vlček [lukas.vlcek@gmail.com](mailto:lukas.vlcek@gmail.com) wrote:

> Ah, so the plugin needs to be installed on both clusters, I missed that  
> part. Thanks for clarification.
> 
> BTW, is it required to have the plugin on both sides because the plugin on  
> cluster B does more than just serving the web app in this case? Say, I want  
> to monitor cluster A and store data into cluster B - thus I install plugin  
> on cluster A and configure accordingly, but do not install the plugin on B,  
> instead I just keep copy of the web app locally in case I would want to  
> access the data in cluster B? Hope my question makes sense...
> 
> Regards,  
> Lukas
> 
> On Thu, Jan 30, 2014 at 11:32 AM, Boaz Leskes [b.leskes@gmail.com](mailto:b.leskes@gmail.com) wrote:
> 
> > 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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/fd46420c-2c72-43b7-9b95-0d8b7e81ed14%40googlegroups.com](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](https://groups.google.com/groups/opt_out).
> 
> --  
> 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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaKBMZo\_zOEEczFqcHf7PndH%3DfOMOfbHM1\_G5Aq347z\_A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAO9cvUaKBMZo_zOEEczFqcHf7PndH%3DfOMOfbHM1_G5Aq347z_A%40mail.gmail.com)  
> .
> 
> For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

--  
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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQA3bsiy5gQPZr37%2BFij1GOBjv8S%2BzMfWXp-zO\_0mp0ocw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CALY%3DcQA3bsiy5gQPZr37%2BFij1GOBjv8S%2BzMfWXp-zO_0mp0ocw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 1:53am UTC](https://discuss.elastic.co/t/marvel-architecture-question/15490/5 "2017-07-06T01:53:53Z")

</div>


