Repository navigation
[doc] Logstash Kubernetes - Stack Monitoring docs - #14696
Conversation
|
jenkins test this please |
robbavey
left a comment
There was a problem hiding this comment.
Nice work - I have a couple of questions on structure and formatting
| To enable {logstash-ref}/monitoring-with-metricbeat.html[Stack Monitoring] for {ls}, you need Metricbeat to collect {ls} metrics, {es} to store the metrics and Kibana to view the result. | ||
|
|
||
| Follow these steps to configure monitoring: | ||
| Assuming you have installed ECK, the example modifies the link:https://github.com/elastic/cloud-on-k8s/blob/main/config/recipes/beats/stack_monitoring.yaml[recipe] of Beats stack monitoring. The recipe has initiated a production {es} cluster, a monitoring {es} cluster, {filebeat}, {metricbeat}, a production Kibana and a monitoring Kibana. It monitors {es} and Kibana and send metrics to monitoring cluster. |
There was a problem hiding this comment.
I wonder if we should call out ECK explicitly, but have an intro section, explaining what we are doing here with these examples:
Something like,
For these examples, we will be modifying the Beats stack monitoring link:https://github.com/elastic/cloud-on-k8s/blob/main/config/recipes/beats/stack_monitoring.yaml[recipe] from the ECK examples, which initiate ...
And then have
=== Stack Monitoring with ECK
Or something along those lines.
Thoughts @karenzone ?
There was a problem hiding this comment.
we can add a note of prerequisites of installing ECK which links to the Quick start set up environment
| An important step to making your environment production ready is to configure stack monitoring. Monitoring metrics can be sent to an external resource, such as {ess} or {eck}, so that in the event that any components of your environment become unresponsive, your monitoring data is available. | ||
|
|
||
| An important step to making your environment production ready is to configure stack monitoring. Monitoring logs and metrics data can be sent to an external resource, such as {ess} or {eck}, so that in the event that any components of your environment become unresponsive, your monitoring data is available. | ||
| To enable {logstash-ref}/monitoring-with-metricbeat.html[Stack Monitoring] for {ls}, you need Metricbeat to collect {ls} metrics, {es} to store the metrics and Kibana to view the result. |
There was a problem hiding this comment.
I wonder if we should start with some prerequisites - for the elastic cloud or external cluster options, we require that the elastic CRD's are installed ahead of time, to ensure that the Beat CRD is available. Maybe call it out ahead of time before we have sections for ECK/Elastic Cloud/External Elasticsearch?
There was a problem hiding this comment.
agree, will do it
|
|
||
| <2> {metricbeat} scans for the pods with label `app: ls` to collect {ls} metrics. | ||
|
|
||
| <3> {metricbeat} logstash module calls metric endpoint from port `9600` for every `10` seconds. |
There was a problem hiding this comment.
Does it call each logstash every 10 seconds? Or round robin between them, so for 3 logstashes, every 30 seconds?
There was a problem hiding this comment.
it calls each logstash every 10 seconds
| ... | ||
| -- | ||
|
|
||
| Provide the `cluster_uuid` of the production {es} cluster to `monitoring.cluster_uuid` in logstash.yml. |
There was a problem hiding this comment.
Do we have a link anywhere on how to do that?
There was a problem hiding this comment.
I added instructions of getting uuid
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
add instruction of getting cluster_uuid
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
| [[ls-k8s-monitor-external]] | ||
| ==== Ship metrics to external {es} cluster | ||
|
|
||
| NOTE: The prerequisite of the example is having ECK installed. Checkout <<qs-set-up>> |
There was a problem hiding this comment.
Is it a prerequisite to have ECK installed? Or just the CRDs?
There was a problem hiding this comment.
The example involves the deployment of stack, so it is ECK
There was a problem hiding this comment.
I think I get confused between Metrics can be sent to an {es} cluster that is not managed by ECK, and the prerequisite of ECK for this - one use case is for a new logstash cluster sending to a pre-existing monitoring cluster, not migrated to ECK
There was a problem hiding this comment.
You are right, to config the external ES we just need CRDs. I mess up with another example.
| [[ls-k8s-monitor-elastic-cloud]] | ||
| ==== Ship metrics to Elastic Cloud | ||
|
|
||
| NOTE: The prerequisite of the example is having ECK installed. Checkout <<qs-set-up>> |
There was a problem hiding this comment.
Is it a prerequisite to have ECK installed? Or just the CRDs?
There was a problem hiding this comment.
I am not sure how much the operator has been involved in associating Beat with Elasticsearch. I am hesitant to suggest users install CRD only. So, the prerequisite is ECK.
There was a problem hiding this comment.
Do you mean from the perspective of whether the Beats CRD can be used in isolation, without any of the other components of the stack?
It feels like it might be a common use case to not want to install any of the other stack elements, and just use K8s as a container for Logstash (and metricbeat to monitor it), and to send to Elastic Cloud. In which case we'd need only the sections with metadata.name: metricbeat sections, and not any of the filebeat, elasticsearch or kibana sections. And we wouldn't need the elasticsearch and kibana modules in the metricbeat definition.
And it might make sense to add this as a recipe to refer back to, to reduce the confusion with the rest of the file?
WDYT?
There was a problem hiding this comment.
I probably mess up the example when I replied. This should be valid to say CRDs as a prerequisite.
My understanding of ECK includes two parts. 1. CRD 2. operator. In order to have CRDs work with full functionality, we need both. The part I was uncertain is which features/configs need operator to work, so hesitate to just suggest installing CRD. But in this feature connecting to Elastic Cloud, I think we are safe to require CRD only.
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
…oc_k8s_stack_monitoring # Conflicts: # docsk8s/administering/ls-k8s-stack-monitoring-cloud.asciidoc
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
Co-authored-by: Karen Metts <35154725+karenzone@users.noreply.github.com>
…oc_k8s_stack_monitoring
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
| [[ls-k8s-monitor-config-ls]] | ||
| ===== Configure {ls} | ||
|
|
||
| Add label `app: ls` to `Deployment` for autodiscover. |
There was a problem hiding this comment.
Do we need to mention StatefulSet here too?
There was a problem hiding this comment.
I think it is optional
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
Co-authored-by: Rob Bavey <rob.bavey@elastic.co>
|
📃 DOCS PREVIEW ✨ https://logstash_14696.docs-preview.app.elstc.co/diff |
karenzone
left a comment
There was a problem hiding this comment.
I revamped a suggestion from the previous review based on the clarification you provided (that "it" means "Metricbeat." Other than adding/committing that one, LGTM! 🚀
|
|
||
| NOTE: The prerequisite of the example is having CRDs installed. Checkout <<qs-set-up>> | ||
|
|
||
| Metrics can be sent to an {es} cluster that is not managed by ECK. To configure it, remove the `elasticsearchRef` from the specification and include an output configuration in the `spec.config`. |
There was a problem hiding this comment.
Thanks for the info. I updated the suggestion to clarify. :-)
For agent/metricbeat monitoring logstash, we have a recipe in beats for stack monitoring while agent is missing this part. Also, we have "Elasticsearch Metrics" integrations for beats but not agent. Agent can monitor Logstash with limitation. If users want to monitor multiple logstashes, they need to assign different service name for each logstash which is not practical. So, in this doc, agent is not mentioned as a solution.
I wanna have stack monitoring in multiple pages as the following structure without success. They are on the same page now. If you know how to split it, please let me know.
Fixes: #14572