[DOCS] Update monitoring diagrams with metricbeat #119
Conversation
|
|
||
| If you have at least a Gold license, you can route data from multiple production | ||
| clusters to a single monitoring cluster: | ||
| If you are not using {metricbeat} to collect the {kib} data, you might want to |
There was a problem hiding this comment.
I wouldn't say there is a causality between the usage of metricbeat and having a dedicated kibana instance. I think the previous wording is more accurate over here:
If Kibana is a regular part of your stack, you might want to create a dedicated Kibana instance for monitoring, rather than using a single Kibana instance to access both your production cluster and monitoring cluster:
There was a problem hiding this comment.
Though when you're using Kibana with Metricbeat, you're not accessing the production cluster, are you?
There was a problem hiding this comment.
In a setup where Metricbeat is being used to monitor Kibana:
- Kibana has two connections: one to the production ES cluster (to visualize data in the cluster and administer the cluster) and another to the Monitoring ES cluster (to display the Monitoring UI). Of course, the two clusters might actually be the same, single cluster.
- Metricbeat has one connection: to the monitoring ES cluster.
Does this answer your question or did I just make it more confusing :)?
There was a problem hiding this comment.
Thanks, I've updated that paragraph, since it hadn't been clear to me what was meant by being "a regular part of the stack".
There was a problem hiding this comment.
Brilliant, this explanation is much clearer IMO. Thanks!
| activities from impacting the performance of your production cluster. | ||
| activities from impacting the performance of your production cluster. | ||
|
|
||
| beta[] In 6.5 and later, you can use {metricbeat} to collect and ship data about |
There was a problem hiding this comment.
I like that we are flagging this as a "beta" section, including the diagram that follows it. What do you think about also keeping the original non-beta way of doing things, including the diagram? Do you think it might be too much information and could lead to confusion?
There was a problem hiding this comment.
I have added back the first simple diagram and refreshed the preview. I think the diagram with two clusters is unnecessary.
| If {kib} is a regular part of your stack, you might want to create a dedicated | ||
| {kib} instance for monitoring, rather than using a single {kib} instance to | ||
| If {kib} is a regular part of your stack, you might want to create a dedicated | ||
| {kib} instance for monitoring, rather than using a single {kib} instance to | ||
| access both your production cluster and monitoring cluster: | ||
|
|
||
| image::monitoring/images/architecture3.jpg[A monitoring environment with separate {kib} instances] |
There was a problem hiding this comment.
Looking at the preview URL, this image only shows one Kibana instance. Maybe this ought to reference a different image file?
There was a problem hiding this comment.
The last image has the write and read coming from separate "instances" within the Kibana box, but if that's not clear, I can add a second Kibana box.
There was a problem hiding this comment.
Ugh, indeed it does. Sorry about that, I just missed the second instance. No need to change anything here, sorry about the noise again.
Related to elastic/beats#7035
This PR replaces the architectural diagrams with one that includes Metricbeat. It also adds text to describe the beta behaviour.