Learn some best practices for upgrading your production Elasticsearch clusters without service outages for your users.

<p>Many users need their Elasticsearch clusters to <strong>always be available</strong>. And a lot of these same users also want to upgrade their Elasticsearch environment when a new version is released, so they can take advantage of all the new features and functionality. The result is that admins end up upgrading the Elasticsearch engine while it is operating at full capacity in production. Sound too good to be true? Well, <strong>Elasticsearch was designed for zero downtime upgrades</strong>, but upgrading the engine while going full steam ahead does require some knowledge and preparation.
</p>
<p>In this blog, we're going to walk through the steps for upgrading an Elasticsearch environment with zero downtime. We will provide guidelines and strategies to minimise risk while running the upgrade on an active production environment. Here are the items&nbsp;we'll go through:
</p>
<ol>
	<li>Version considerations</li>
	<li>Defining an upgrade strategy</li>
	<li>Common deployment strategies for fast regression</li>
	<li>Monitoring the upgrade</li>
	<li>A/B testing</li>
	<li>Automatically deploying</li>
</ol>
<h2>1. Version considerations</h2>
<p>Your upgrade path will depend on your <code>To</code> and <code>From</code> versions. So as a first step, a comparison between the existing deployment version and the prospected version should be made. Here are a few things we recommend:
</p>
<ol>
	<li><a href="https://www.elastic.co/guide/en/elastic-stack/7.10/elastic-stack-breaking-changes.html">Review the breaking changes</a> for each product you use and make the necessary changes so your code is compatible with the new version (e.g.&nbsp;<a href="https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/_breaking_changes.html">Elasticsearch .NET client</a> breaking changes).</li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/logging.html#deprecation-logging"><strong>Enable </strong>deprecation logging</a> to validate that no deprecated features are in use.</li>
	<li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/reindex-upgrade.html">Reindex before upgrading</a>!<strong> </strong>Elasticsearch can only read indices created in the previous major version. If the cluster contains indices which were written in the previous major version it would need to be reindexed to be supported in the newer version. (e.g. - Elasticsearch 7.x can not read indices created in 5.x). The list of the indices can be found in the <a href="https://www.elastic.co/guide/en/kibana/7.10/upgrade-assistant.html">Upgrade Assistant</a>.</li>
	<li>Use the <a href="https://www.elastic.co/guide/en/kibana/7.10/upgrade-assistant.html">Upgrade Assistant</a> to target the changes needed to make to your cluster configuration.</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1c7eaecaac29ff6b/5fdcf4a8a00f8977b7233816/blog-zero-down-up-1.jpg" data-sys-asset-uid="blt1c7eaecaac29ff6b" alt="" style="display: block; margin: auto;">
</p>
<ol start="5">
	<li>Review all stored entities (<a href="https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high-put-stored-script.html">stored scripts</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/search-template.html#pre-registered-templates">stored search templates</a>, <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/watcher-getting-started.html">watchers</a> etc.) to ensure they are compatible with the new version.</li>
	<li><strong>(Recommended) </strong><a href="https://www.elastic.co/guide/en/elastic-stack/master/elastic-stack-breaking-changes.html"><strong>Review future version breaking changes.</strong></a> - To simplify future major upgrades, now would be a good time to review the next major version breaking changes.&nbsp;</li>
</ol>
<p>For the full list of things to review please read <a href="https://www.elastic.co/blog/upgrading-the-elastic-stack-planning-for-success">Upgrading the Elastic Stack: Planning for success</a> (blog) and <a href="https://www.elastic.co/guide/en/elastic-stack/7.10/upgrading-elastic-stack.html">Upgrading the Elastic Stack</a> (documentation).
</p>
<h2>2. Defining an upgrade strategy</h2>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6c480a0879825cac/5fdcf4b3a703d10ab87e8255/blog-zero-down-up-2.png" data-sys-asset-uid="blt6c480a0879825cac" alt="" style="display: block; margin: auto; width:750px;">
</p>
<h3>2.0 Snapshot backups</h3>
<p>Before running a cluster upgrade, it is recommended to take <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/snapshot-restore.html">snapshots</a> as part of the rollback strategy. This is because once a node from a newer version joins the cluster, downgrading the cluster may no longer be possible. At this point, if a downgrade is needed this will only be possible using a snapshot. Apart from upgrades, backups are also important for recovering data in case of failure or accident therefore it is <strong>always a best practice for snapshots to be captured</strong>.
</p>
<h3>2.1. Rolling upgrade (minor or single major)</h3>
<p>The quickest upgrade path would be a <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/rolling-upgrades.html">rolling upgrade</a>. A rolling upgrade allows an Elasticsearch cluster to be upgraded one node at a time so it provides zero downtime.
</p>
<p>Rolling upgrades are supported between:
</p>
<ul>
	<li>Minor versions (for example - from 7.0 to 7.10).</li>
	<li>Latest minor to the next major (from 5.6 to 6.8 or from 6.8 to 7.10.0).</li>
</ul>
<p>While a rolling upgrade is supported in the above scenarios, a rolling upgrade on a production environment will always carry some risk, as something <em>could</em> go wrong during the process. Aside from unexpected issues, another factor to bear in mind is that your rolling upgrade will roll one node at a time. This means you'll have one less node to accept search and index requests while you upgrade. If an overload risk is too high, the better alternative would be to deploy a new cluster as described in section 2.2.
</p>
<h4>2.1.1.&nbsp; Elasticsearch is running the latest minor</h4>
<p>As Elasticsearch is backward compatible between the latest minor and the next major (meaning full functionality support, including with client apps),&nbsp; you<strong> </strong>must still<strong> upgrade the client library to the matching major and recompile your client application</strong> so it works with the new version. Furthermore, it is always recommended to perform a <strong>build verification on a dev environment</strong> prior to a production upgrade.&nbsp;
</p>
<h4>2.1.2.&nbsp; Elasticsearch is not running the latest minor</h4>
<p>In this scenario, it is possible to perform rolling upgrades with two phases. The first step would be to upgrade for the latest minor and the second step would be between major versions. For example, first from 6.1 to 6.8 and second from 6.8 to 7.10.&nbsp;
</p>
<p>This solution would be suitable <strong>only if </strong>the client application can communicate with both Elasticsearch versions and all breaking changes in the application code have successfully been resolved. You will also need to <strong>upgrade the client library to the matching major and recompile the client application</strong>. Otherwise, you can deploy a new cluster on the proposed version, apply change code in accordance, and define a deployment strategy as described in section 3.
</p>
<h3>2.2. New cluster deployment (multi-major)</h3>
<p>If the upgrade will be between multiple versions (for example 5.x to 7.x), the client application will need to be upgraded and a deployment strategy needs to be applied. It is also possible to perform a series of rolling upgrades, however it is likely to be more effort than deploying a new cluster, as the dataset would need to be reindexed fully in either case.&nbsp;
</p>
<h4>2.2.1. Backend: Elasticsearch</h4>
<p>If the client application can communicate with both Elasticsearch versions and there are no breaking changes in the application, deploy a new cluster aside the existing one with no application changes apart from client upgrade.
</p>
<p>In this scenario the application would navigate traffic to both existing and new clusters simultaneously using a <em>blue-green</em> or <em>canary</em> deployment (more details in section 3).
</p>
<ul>
	<li>Elasticsearch <strong>Vx</strong></li>
	<li>Elasticsearch <strong>Vy</strong></li>
</ul>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd8b182f3817fc36f/5fdcf4dae7fdff751b7922a5/blog-zero-down-up-3.png" data-sys-asset-uid="bltd8b182f3817fc36f" alt="" style="display: block; margin: auto; width:500px;">
</p>
<h3></h3>
<h4>2.2.2. Backend and frontend: Elasticsearch + application</h4>
<p>Alternatively, if there are breaking changes in the client library, a new release would be necessary and the deployment strategy would need to<strong> </strong>be <strong>applied on both Elasticsearch and the client application as a bundle,</strong> meaning that at the same time there would be two deployments:&nbsp;
</p>
<ul>
	<li>Client application <strong>V1</strong> along with Elasticsearch <strong>Vx</strong></li>
	<li>Client application <strong>V2</strong> along with Elasticsearch <strong>Vy</strong></li>
</ul>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6e821358c2175108/5fdcf4d3b529867fcec24aa6/blog-zero-down-up-4.png" data-sys-asset-uid="blt6e821358c2175108" alt="" style="display: block; margin: auto; width:750px;">
</p>
<h2>3.Common deployment strategies for fast regression</h2>
<p>Preparation and testing should minimize the risk of an upgrade. Having said that, in most cases, a testing environment would typically not simulate a one-to-one real world scenario. Therefore, it is <strong>always recommended to have a regression path</strong> in case something goes wrong.
</p>
<h3>3.1 Blue-green</h3>
<p>In a blue-green deployment, the blue environment would serve 100% of the traffic at each point, while the green would be ready to take place. To migrate, the traffic would be switched all at once between environments.
</p>
<p>In the blue-green route, a few things should be taken into consideration:&nbsp;
</p>
<ol>
	<li>At each point there will be two live environments, meaning double the resources and cost.</li>
	<li>The green deployment must be highly tested as the migration process is abrupt. If an issue rises, all users would be instantly influenced.</li>
</ol>
<h3>3.2 Canary</h3>
<p>In a canary deployment, at each point we will have the legacy environment serving the majority of users and the new environment would be initially tested with a small group of users.
</p>
<ol>
	<li>This approach would be more cost efficient as at each point the resources could be split across environments.</li>
	<li>Moderate user effect, as only a small group is affected.</li>
	<li>Potentially a lower priority group could be picked for trial. For example, internal users group as opposed to external.</li>
</ol>
<h2>4. Monitoring the upgrade</h2>
<p>During the upgrade the environment should be monitored to assure it’s healthy.&nbsp;
</p>
<h3>4.1 Dedicated monitoring cluster</h3>
<p>In production, you should always send the data to a <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/monitoring-production.html">separate monitoring cluster</a>.&nbsp;The monitoring should ideally populate all pillars of observability for both the client application and Elasticsearch:&nbsp;
</p>
<ol>
	<li><a href="https://www.elastic.co/log-monitoring">Logs</a></li>
	<li><a href="https://www.elastic.co/infrastructure-monitoring">Metrics</a></li>
	<li><a href="https://www.elastic.co/apm">Application performance monitoring</a> (APM)</li>
</ol>
<p>You can use this existing monitoring deployment to watch your upgrade as well. Otherwise, consider setting one up for at least the length of the upgrade.
</p>
<h3>4.2 Defining&nbsp;success criteria</h3>
<p>To validate the new deployment, define success criteria. For example, gather statistics from the running environment to analyze its normal behaviour. For that you can use the current environment monitoring dashboards or create dedicated dashboards. This will help you to prepare for the testing phase and validate a successful testing operation by comparing between the current and new deployment statistics. Possible indicators can be low latency, no CPU or memory pressure, no bottlenecks or lags, similar error rate&nbsp; and other factors that are relevant to your application.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbdfd1225f5c7f9b1/5fdcf4e3b47cdf7fc7d69491/blog-zero-down-up-5.jpg" data-sys-asset-uid="bltbdfd1225f5c7f9b1" alt="" style="display: block; margin: auto;">
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc76a4fd99f3e03b0/5fdcf53ea00f8977b723381e/blog-zero-down-up-6.jpg" data-sys-asset-uid="bltc76a4fd99f3e03b0" alt="" style="display: block; margin: auto;">
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt19da8e923b0d6502/5fdcf5496aab641cd100bbb3/blog-zero-down-up-7.png" data-sys-asset-uid="blt19da8e923b0d6502" alt="" style="display: block; margin: auto;">
</p>
<h2><strong>5. A/B testing</strong></h2>
<p>Before running in production, the new environment should be tested and the changes should be isolated by keeping the test environment as close as possible to reality.
</p>
<p>Possible factors to consider:&nbsp;
</p>
<ul>
	<li>Same hardware type</li>
	<li>Same data type</li>
	<li>Same queries</li>
	<li>Same indexing to search ratios</li>
	<li>If it is affordable, maintain similar sizing. Otherwise, use the same ratio between a subset of data and the incoming/outcoming traffic to the production deployment sizing.</li>
	<li>Compare environment KPIs before and after the upgrade. Validate that any change is statistically valid by running the <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/search-aggregations-metrics-ttest-aggregation.html">T-test aggregation</a> on the monitoring data.</li>
</ul>
<h3>5.1. Smoke testing: Build verification</h3>
<p>Perform build testing to verify that all of the critical functionalities are working as expected with the new version. The smoke test main goal is to verify the initial stability of the system. Common things to check are that the GUI is up and running, the application is able to integrate and login to Elasticsearch and other third party applications, all application workflows are working as expected, all query or indexing requests are successful, etc.
</p>
<h3>5.2. Benchmark testing</h3>
<p>As we can not run a benchmark in production, an environment that's as similar as can be to production is a great opportunity to run benchmark tests for gathering statistics for future capacity planning. A great tool for running benchmark tests on Elasticsearch is <a href="https://www.elastic.co/blog/announcing-rally-benchmarking-for-elasticsearch">Rally</a>. This is the same tool we use at Elastic to test Elasticsearch builds.
</p>
<h2>6. Automatically deploying</h2>
<p>Once everything has been done the only step left would be to apply! The final step is to make sure you have an automatic procedure to minimize human errors. If you’re running on <a href="https://www.elastic.co/elasticsearch/service">Elastic Cloud</a>, the Elasticsearch upgrade can be done with a single click! Along with a wide <a href="https://www.elastic.co/guide/en/cloud/current/ec-restful-api.html">RESTful API</a> to apply on automations. Once the process is completed, the deployment should be automatic and repeatable for future successful updates.
</p>
<h2>Finishing up</h2>
<p>That's it! The upgrade is done and your users barely noticed! When running an operation such as an upgrade, <strong>planning in key</strong>. Now that this upgrade is complete, you can take your lessons learned and use them to&nbsp; prepare a tailored deployment strategy for your next upgrade. Doing so will ensure that each future upgrade should be easier than the last. And by thoroughly documenting the entire process, you'll know that you won't have to worry about the next upgrade (even if you're on vacation)!&nbsp;
</p>If you're interested in learning more, check out our <a href="https://www.elastic.co/webinars/expert-tips-when-upgrading-elk-stack">Expert Tips when Upgrading</a> webinar. If you have any questions, reach out on our <a href="https://discuss.elastic.co">Discuss forums</a>. And as always, the easiest upgrades are on Elastic Cloud, so <a href="https://www.elastic.co/cloud">give it a try for free</a> if you haven't already.

blog-banner-elasticsearch-gears-light-blue.png

blog-thumb-elasticsearch-gears-light-blue.png

How to perform a zero-downtime upgrade of Elasticsearch in production

Learn how to orchestrate and operate the Elastic Stack using Red Hat OpenShift and Elastic Cloud on Kubernetes (ECK). And then learn how to use your deployment to monitor your OpenShift logs and metrics.

<p>Managing hundreds or thousands of containers has quickly become the standard for many organizations. With infrastructures growing more complex, we want every user to find value with Elastic (regardless of where or how they operate). We created <a href="https://www.elastic.co/elastic-cloud-kubernetes">Elastic Cloud on Kubernetes (ECK) </a>— the official Operator — to simplify setup, upgrades, scaling, and more for running Elasticsearch and Kibana on Kubernetes. When you use ECK on OpenShift, Red Hat's Kubernetes container platform, you can fully orchestrate and manage a stateful Elastic Stack deployment in minutes, as well as take advantage of ECK's built-in best practices well beyond day 1.
</p><p>Of course, with diverse infrastructures, monitoring becomes both more challenging and more critical. With <a href="https://www.elastic.co/observability">Elastic Observability</a>, you can store and analyze the logs and metrics from your OpenShift ecosystem alongside your other infrastructure monitoring data for a unified view. In this blog post we're going to see how easy it is to get the Elastic Stack up and running on OpenShift with ECK, as well as how to start monitoring OpenShift.
</p><p>You will learn to:
</p><ol>
	<li>Set up Elasticsearch and Kibana on OpenShift using ECK.</li>
	<li>Ship OpenShift logs and metrics to Elasticsearch using Beats (also on ECK).</li>
</ol><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3b44b1229005fccf/5fb534c26f82405d9a4ad566/blog-openshift-monitoring-eck.jpg" data-sys-asset-uid="blt3b44b1229005fccf" alt="Monitoring OpenShift with Elastic Observability" style="display: block; margin: auto;">
</p> <strong><h2>Prerequisites</h2></strong><p>To run the following instructions, you must first:
</p><ol>
	<li>Be a <code>system:admin</code> user or a user with the privileges to create Projects, CRDs, and RBAC resources at the cluster level.</li>
	<li>Set virtual memory settings on the Kubernetes nodes (as described in Step 1 below).</li>
</ol> <strong><h2>Part 1: Set up an Elasticsearch deployment</h2></strong><p>In this first part, we're going to walk through deploying Elasticsearch and Kibana on OpenShift using ECK. By the end of this section, you'll have a fully functional Elastic Stack deployment up and running.
</p> <strong><h3>Step 1: Increase your virtual memory (recommended)</h3></strong><p>Elasticsearch uses a mmapfs directory by default to efficiently store its indices. The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions. For production workloads, it is strongly recommended to increase the kernel setting <code>vm.max_map_count</code> to <code>262144</code>. The kernel setting <code>vm.max_map_count=262144</code> can be set on the host either directly or by a dedicated init container, which must be privileged.
</p><pre class="prettyprint">echo 'vm.max_map_count=262144' &gt;&gt; /etc/sysctl.conf
</pre> <strong><h3>Step 2: Create new project</h3></strong><p>Create an <code>elastic</code> OpenShift project:
</p><pre class="prettyprint">oc new-project elastic
</pre> <strong><h3>Step 3: Install the ECK operator</h3></strong><pre class="prettyprint">oc apply -f &lt;a href="https://download.elastic.co/downloads/eck/1.3.0/all-in-one.yaml"&gt;https://download.elastic.co/downloads/eck/1.3.0/all-in-one.yaml&lt;/a&gt;
</pre> <strong><h3>Step 4: Deploy Elasticsearch</h3></strong><p>Create an Elasticsearch monitoring cluster with an OpenShift route.
</p><pre class="prettyprint">cat &lt;&lt;EOF | oc apply -n elastic -f - 
# This sample sets up an Elasticsearch cluster with an OpenShift route 
apiVersion: elasticsearch.k8s.elastic.co/v1 
kind: Elasticsearch 
metadata: 
  name: monitoring 
spec: 
  version: 7.10.0 
  nodeSets: 
  - name: default 
    count: 3 
    config: 
      node.store.allow_mmap: false 
--- 
apiVersion: route.openshift.io/v1 
kind: Route 
metadata: 
  name: monitoring 
spec: 
  #host: elasticsearch.example.com # override if you don't want to use the host that is automatically generated by OpenShift (&lt;route-name&gt;[-&lt;namespace&gt;].&lt;suffix&gt;) 
  tls: 
    termination: passthrough # Elasticsearch is the TLS endpoint 
    insecureEdgeTerminationPolicy: Redirect 
  to: 
    kind: Service 
    name: monitoring-es-http 
EOF
</pre> <strong><h3>Step 5: Deploy Kibana</h3></strong><pre class="prettyprint">cat &lt;&lt;EOF | oc apply -n elastic -f - 
apiVersion: kibana.k8s.elastic.co/v1 
kind: Kibana 
metadata: 
  name: kibana 
spec: 
  version: 7.10.0 
  count: 1 
  elasticsearchRef: 
    name: "monitoring" 
  podTemplate: 
    spec: 
      containers: 
      - name: kibana 
        resources: 
          limits: 
            memory: 1Gi 
            cpu: 1 
--- 
apiVersion: v1 
kind: Route 
metadata: 
  name: kibana 
spec: 
  #host: kibana.example.com # override if you don't want to use the host that is automatically generated by OpenShift (&lt;route-name&gt;[-&lt;namespace&gt;].&lt;suffix&gt;) 
  tls: 
    termination: passthrough # Kibana is the TLS endpoint 
    insecureEdgeTerminationPolicy: Redirect 
  to: 
    kind: Service 
    name: kibana-kb-http 
EOF
</pre> <strong><h3>Step 6: Collect ES admin password</h3></strong><p>To extract the Elasticsearch <code>elastic</code> admin user, run the following command:
</p><pre class="prettyprint">PW=$(oc get secret "monitoring-es-elastic-user" -o go-template='{{.data.elastic | base64decode }}')
</pre> <strong><h2>Part 2: Monitoring OpenShift using Metricbeat and Filebeat on ECK</h2></strong><p>Now that the Elastic Stack is deployed, we can start using it to monitor OpenShift. We'll deploy <a href="https://www.elastic.co/beats/metricbeat">Metricbeat</a> and <a href="https://www.elastic.co/beats/filebeat">Filebeat</a> on ECK to ingest observability data directly from OpenShift, and then we'll be able to easily monitor system health right from <a href="https://www.elastic.co/observability">Elastic Observability</a>.
</p> <strong><h3>Step 1: Setup Beats</h3></strong><p>Download the Beats manifests:
</p><pre class="prettyprint">curl -L -O https://raw.githubusercontent.com/liladler/eck-on-openshift/main/filebeat_openshift.yaml
</pre><pre class="prettyprint">curl -L -O https://raw.githubusercontent.com/liladler/eck-on-openshift/main/metricbeat_openshift.yaml
</pre><h3>Step 2: Add permissions to the Beats service accounts</h3><p>Now that the Beats are configured, they're going to need proper access to OpenShift.
</p><pre class="prettyprint">oc adm policy add-scc-to-user privileged system:serviceaccount:openshift-monitoring:metricbeat 
oc adm policy add-scc-to-user privileged system:serviceaccount:openshift-monitoring:filebeat
</pre> <strong><h3>Step 3: Patch node-selector</h3></strong><p>Override the default node selector for the openshift-monitoring namespace (or your custom namespace) to allow for scheduling on any node:
</p><pre class="prettyprint">oc patch namespace openshift-monitoring -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'
</pre> <strong><h3>Step 4: Enable network between projects</h3></strong><pre class="prettyprint">oc adm pod-network join-projects --to=elastic openshift-monitoring
</pre> <strong><h3>Step 5: Deploy the Beats</h3></strong><pre class="prettyprint">oc apply -f filebeat_openshift.yaml
oc apply -f metricbeat_openshift.yaml
</pre> <strong><h2>Monitor OpenShift with Elastic Observability</h2></strong><p>Now that we have Filebeat and Metricbeat shipping OpenShift logs and metrics to Elasticsearch, we can open up Kibana and start monitoring system health from Elastic Observability.
</p><div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/Xx5Ttsr5DpBKzu9vNfbR5L.jpg" data-uuid="Xx5Ttsr5DpBKzu9vNfbR5L" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1">
</div><p><strong></strong>
</p><h2><strong>Wrapping up</strong></h2><p>Congratulations! You’ve provisioned a monitored OpenShift environment with&nbsp; maintainable and reusable manifests! If you'd like to take your system observability even further, you can <a href="https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-apm-server.html">deploy Elastic APM Server on ECK</a> and <a href="https://www.elastic.co/blog/using-elastic-apm-java-agent-on-kubernetes-k8s">bundle your application with the Elastic APM Agent</a>.&nbsp;
</p><p>With logs, metrics, and APM you can easily correlate it all into a single view allowing you to observe and troubleshoot your production environment in a single tool. Try it yourself <a href="https://elastic.co/cloud">free for 14-days on Elastic Cloud</a>. And if you'd like to learn more about Elastic Observability, we'd recommend watching the <a href="https://www.elastic.co/webinars/elastic-observability-a-single-pane-of-glass-for-all-your-observability-data">Elastic Observability: A single pane of glass for all your observability data</a> webinar.
</p>

Articles by Lilach Adler

How to perform a zero-downtime upgrade of Elasticsearch in production

How to deploy the Elastic Stack using ECK to monitor OpenShift

Products & Solutions

Company

Resources

Solutions

Elastic (ELK) Stack

Register Today

Featured topics

News

Articles by Lilach Adler

How to perform a zero-downtime upgrade of Elasticsearch in production

How to deploy the Elastic Stack using ECK to monitor OpenShift