Opster https://opster.com/ Taking Care of Your Entire Search Operation Thu, 02 Mar 2023 10:50:43 +0000 en-US hourly 1 https://wordpress.org/?v=6.1.1 https://opster.com/wp-content/uploads/2019/10/cropped-Favicon-new-v1-32x32.png Opster https://opster.com/ 32 32 Opster AutoOps Now Listed on Amazon Web Services Marketplace https://opster.com/blogs/aws-marketplace-autoops-listing/ https://opster.com/blogs/aws-marketplace-autoops-listing/#respond Mon, 13 Feb 2023 15:17:13 +0000 https://opster.com/?p=36621 Opster has announced today that AutoOps is now listed on the Amazon Web Services (AWS) Marketplace. Opster AutoOps is designed specifically for organizations that rely on Elasticsearch and OpenSearch for their mission-critical applications. AutoOps improves...

The post Opster AutoOps Now Listed on Amazon Web Services Marketplace appeared first on Opster.

]]>

Opster has announced today that AutoOps is now listed on the Amazon Web Services (AWS) Marketplace.

Opster AutoOps is designed specifically for organizations that rely on Elasticsearch and OpenSearch for their mission-critical applications. AutoOps improves performance, automates routine database operations and reduces the time and cost associated with managing Elasticsearch and OpenSearch.

Being listed on AWS Marketplace opens up new opportunities for customers looking for search solutions and support. This listing makes it easier for organizations to discover, purchase, and manage the solutions they need to optimize their Elasticsearch and OpenSearch databases. AWS customers have a smoother billing process without needing to set up a separate procurement plan, and also have the ability to use committed spend. 

For those using AWS OpenSearch service, the AutoOps listing is an amazing chance to gain additional capabilities, visibility and support for their OpenSearch clusters.

“We’re excited to be part of the AWS Marketplace community,” said Ziv Segal, CEO and Co-Founder of Opster. “As more and more organizations turn to Elasticsearch and OpenSearch for their applications, it’s essential that they have the right tools to manage and optimize their databases. Our listing on AWS Marketplace makes it easier for AWS customers to use Opster, and we’re grateful for the opportunity to help more and more organizations reach their goals.”

To visit Opster’s listing on AWS Marketplace, click here.

The post Opster AutoOps Now Listed on Amazon Web Services Marketplace appeared first on Opster.

]]>
https://opster.com/blogs/aws-marketplace-autoops-listing/feed/ 0
Opster’s OpenSearch Kubernetes Operator – New Features! https://opster.com/blogs/opensearch-snapshot-manager-monitoring/ https://opster.com/blogs/opensearch-snapshot-manager-monitoring/#respond Sun, 12 Feb 2023 13:19:16 +0000 https://opster.com/?p=36608 Opster’s OpenSearch Kubernetes Operator, licensed Apache V2, simplifies spinning up and scaling clusters, optimizing configuration, upgrading versions, security and more. Whether you’re managing your own K8s cluster or going the hosted route, you can deploy...

The post Opster’s OpenSearch Kubernetes Operator – New Features! appeared first on Opster.

]]>

Opster’s OpenSearch Kubernetes Operator, licensed Apache V2, simplifies spinning up and scaling clusters, optimizing configuration, upgrading versions, security and more. Whether you’re managing your own K8s cluster or going the hosted route, you can deploy the OpenSearch Operator and benefit from its abilities on all cloud environments.

In addition to the many existing features, the Operator has recently gained two new features – the Snapshot Manager and Monitoring for OpenSearch environments. 

Operator Snapshot Manager

The Snapshot Manager is an extremely useful feature that allows users to define snapshot repositories with very simple definitions in the CRD of their OpenSearch cluster. This enables users to centrally configure roles and permissions for the backend cloud, and a scheduled job will be triggered each time a new snapshot is configured or existing snapshot settings are changed.

This feature also spares users the time and effort of having to work with the OS API or Kibana in order to configure and manage snapshots. Furthermore, it is compatible with all OS versions, making it highly convenient to use.

Operator Monitoring 

The new monitoring feature provides built-in monitoring for OpenSearch environments. The monitoring stack is provided out-of-the-box by Aiven Prometheus exporter plugin for OS and is also compatible with all OS versions.

The benefits of using this feature are immense. Firstly, compared to regular installations, users can now easily set up a monitoring stack that is up-to-date with the latest metrics and visualizations. Secondly, the Grafana dashboard provided with this feature is highly customizable and allows users to generate metrics based on their specific requirements and use cases. In addition to the Grafana dashboard, the Aiven plugin also includes a set of PrometheusRules to help manage OpenSearch clusters in real-time.

In other words, with one simple action you can install the full monitoring bundle for every OpenSearch cluster that is managed by the Operator.

Overall, the new features added to the OpenSearch Kubernetes Operator are extremely useful for users who want to make their OpenSearch management as efficient and convenient as possible. Both new features provide users with a great deal of control over their data and allow them to configure and manage their clusters with ease and accuracy.

To get started with the Operator, click here.

The post Opster’s OpenSearch Kubernetes Operator – New Features! appeared first on Opster.

]]>
https://opster.com/blogs/opensearch-snapshot-manager-monitoring/feed/ 0
How CoreView Optimized their Elasticsearch with Opster https://opster.com/case-studies/how-coreview-optimized-elasticsearch-with-opster/ https://opster.com/case-studies/how-coreview-optimized-elasticsearch-with-opster/#respond Mon, 16 Jan 2023 12:32:18 +0000 https://opster.com/?p=34137 About CoreView CoreView is a cloud-based management platform that provides administrators and IT professionals with tools to manage and optimize their Microsoft 365 and Office 365 environments. It offers a range of features including user...

The post How CoreView Optimized their Elasticsearch with Opster appeared first on Opster.

]]>
About CoreView

CoreView is a cloud-based management platform that provides administrators and IT professionals with tools to manage and optimize their Microsoft 365 and Office 365 environments. It offers a range of features including user provisioning, license management, adoption tracking, and security and compliance management.

Main takeaways

  • Improved search & indexing performance
  • Optimized resource utilization to reduce costs
  • Configured direct alerts and receive proactive support from Opster

Searching for better ways to manage Elasticsearch

CoreView has been using Elasticsearch for several years. Though they engaged with the primary managed service support to maintain their deployments, they grew frustrated with the “break-fix” mindset.

“Whenever we had an issue, we had to turn to our provider’s support team and wait a really long time for them to respond,” said Alessandro Lombardi, Senior System Architect at CoreView. “When they did answer, they didn’t always know how to solve the problem.”

The CoreView team was experiencing several challenges with their Elasticsearch deployment, including slow searches, slow indexing and more. They began looking for better solutions to manage their operations.

“We found Opster’s free tools and decided to give it a go,” said Lombardi. “We uploaded a JSON of our infrastructure and were so impressed with the insights we got. We knew it was time to contact the Opster team to learn more. Opster was our first choice for managing Elasticsearch once we started experiencing issues in our system.”

“Opster was our first choice for managing Elasticsearch once we started experiencing issues.”

Alessandro Lombardi | Senior System Architect at CoreView

Alessandro Lombardi | Senior System Architect at CoreView

Optimizing Elasticsearch with Opster’s expert support team

The CoreView and Opster teams began to work on optimizing CoreView’s Elasticsearch clusters. “Opster provided us with so many incredible optimizations for our operation,” said Lombardi. “They had our system working so smoothly, so quickly.”

“Opster provided us with so many incredible optimizations for our operation. They had our system working so smoothly, so quickly.”

Alessandro Lombardi | Senior System Architect at CoreView

Alessandro Lombardi | Senior System Architect at CoreView

Together the teams optimized performance, improved configurations, increased resource utilization for the correct scale and set up all needed notifications and automations. 

“Our new reality is that we don’t discover issues once they’re already issues,” said Lombardi. “We use AutoOps to check our metrics and we actually get pinged proactively by the Opster team, who simply take care of everything.”

“Our new reality is that we don’t discover issues once they’re already issues. We get pinged by the Opster team, who simply take care of everything.”

Alessandro Lombardi | Senior System Architect at CoreView

Alessandro Lombardi | Senior System Architect at CoreView

“The Opster team is just incredible,” Lombardi continued. “They always give us more value than we think we’ll get. If it’s a new feature we need, an analysis of our system’s performance which helps us track our progress, or just answering questions so we can make sure we understand what’s going on.”

Thanks to Opster’s products and support, the CoreView team has complete peace of mind with Elasticsearch. “Honestly, the best part is the response time. Whenever we need something form the Opster team, we just write to them on Microsoft Teams and they answer us within a few minutes,” said Lombardi. “They are always available, always ready to help.”

“Honestly, the best part is the response time. The Opster team is always available, always ready to help.”

Alessandro Lombardi | Senior System Architect at CoreView

Alessandro Lombardi | Senior System Architect at CoreView

“Opster is the complete solution we were looking for,” said Lombardi. “Our performance is constantly improving, we spend less time and less money on our deployment, and the support team is so responsive and amazing.”

The post How CoreView Optimized their Elasticsearch with Opster appeared first on Opster.

]]>
https://opster.com/case-studies/how-coreview-optimized-elasticsearch-with-opster/feed/ 0 Alessandro Lombardi | Senior System Architect at CoreView Alessandro Lombardi | Senior System Architect at CoreView Alessandro Lombardi | Senior System Architect at CoreView Alessandro Lombardi | Senior System Architect at CoreView
Opster’s Q4-2022 Product Feature Highlights & What’s Ahead https://opster.com/blogs/opsters-q4-2022-product-feature-highlight/ https://opster.com/blogs/opsters-q4-2022-product-feature-highlight/#respond Mon, 02 Jan 2023 11:46:02 +0000 https://opster.com/?p=32850 As we kick off 2023, we’re happy to share some of Opster’s highlights from the last quarter of 2022 and some of our upcoming features that will be released this year.  At the end of...

The post Opster’s Q4-2022 Product Feature Highlights & What’s Ahead appeared first on Opster.

]]>

As we kick off 2023, we’re happy to share some of Opster’s highlights from the last quarter of 2022 and some of our upcoming features that will be released this year. 

At the end of 2022 we introduced tons of exciting new functionalities that help our customers and answer their needs. If you want to try them out for yourself, you can start a free trial here.

Here’s a few of the most exciting features we added:

Q4-2022 Feature Highlights 

  1. Visualize shard activity over time in Shard View
  2. AutoOps advanced analysis capabilities
  3. Easily locate noisy neighbors in multi-tenant clusters
  4. API access for AutoOps
  5. One Login integration
  6. Grafana integration for AutoOps
  7. Advanced abilities with Opster Management Console
  8. New AutoOps Reports
  9. Automatic Template Analyzer analysis

Visualize hotspots and resolve bottlenecks thanks to enhancements to Shard View

With Shard View, you can view the system’s activities over time and track how shard activity has changed and affected node load. You can “play” the activity of different time windows and see how the heat map evolved. This helps users see how hotspots formed and resolve bottlenecks.

Drill down issues in your system with the latest events improvements

We improved the drill down of events in AutoOps by taking users directly to the relevant section in Shard View. This way you get a clear picture of the event content and can see the relevant screen already sorted according to the event parameters.

Easily locate noisy neighbors in multi-tenant clusters with sorting of search and indexing latency

A completely unique feature that does not exist in any other system outside of Opster. AutoOps detects which indices were experiencing the highest latency and enables you to sort accordingly, so you can instantly see which indices are experiencing the issues. This way you can easily locate noisy neighbors in multi-tenant clusters or which application/use case is experiencing the burst.

Easily integrate your own automations and internal systems with API access

We’ve opened API access to get AutoOps insights, events and more. This allows easy integration into your own automations and internal systems, both to get insights and act on the recommendations provided in the API. For the full API documentation and instructions on how to use the tokens, see here.

Improved security and access control with One Login Integration

Security and access control are very important to our customers, so we added the ability to integrate the One Login authentication method into AutoOps. This security feature allows you to control who has access to AutoOps in an easier and simpler fashion.

Coming Soon

Integrate open-source tools with Grafana integration for AutoOps

You will be able to integrate the open-source tools you’re used to using with your Opster tools and dashboards. The Grafana dashboard will provide advanced metrics compiled by AutoOps and the events + insights from the AutoOps analysis.

Advanced cluster management abilities with the Opster Management Console

With the newest version of the OMC, we added:
– Scaling of nodes
– Easy steps to change resourcing
– Easy management of admin credentials
– Support for new OpenSearch versions

More insights, metrics and visuals to see your cluster’s health with the new AutoOps Reports

To provide further value on how the system has improved thanks to Opster, we’ve added more insights, metrics and visuals. You can see the full picture of your clusters’ health and the cost of the deployments in the new redesign of the Reports screen in AutoOps, with advanced statistics and KPIs.

No need to run the Template Analyzer manually – AutoOps will do it automatically for you

Introducing: template events in AutoOps. You don’t have to run the Template Analyzer manually anymore – AutoOps does it automatically. We’ve added an event to track the creation of new templates, as well as events to show changes in existing templates that mat require your attention. AutoOps will analyze all the templates to identify fields that need to be adjusted in order to improve performance, and a report is compiled and made available to users automatically.

As always, there’s more coming soon.

Here’s to another great year – happy 2023!

Want to start using AutoOps? You can sign up for a free trial here, or contact us here!

The post Opster’s Q4-2022 Product Feature Highlights & What’s Ahead appeared first on Opster.

]]>
https://opster.com/blogs/opsters-q4-2022-product-feature-highlight/feed/ 0 Frame-2-1 Frame-11 Frame-3 Frame-4 Frame-6 Group-3706 image Frame-5
How Backblaze Optimized and Manage OpenSearch with Opster https://opster.com/case-studies/how-backblaze-optimized-manage-opensearch-with-opster/ https://opster.com/case-studies/how-backblaze-optimized-manage-opensearch-with-opster/#respond Sun, 27 Nov 2022 10:46:16 +0000 https://opster.com/?p=31328 About Backblaze Backblaze is an American cloud storage and data backup company. They went public in 2021, and have since increased their investment in the development of their Storage Cloud platform and the B2 Cloud...

The post How Backblaze Optimized and Manage OpenSearch with Opster appeared first on Opster.

]]>
About Backblaze

Backblaze is an American cloud storage and data backup company. They went public in 2021, and have since increased their investment in the development of their Storage Cloud platform and the B2 Cloud Storage and Computer Backup services that run on it.

Main takeaways

  • Improved search & indexing performance
  • Optimized resource utilization to reduce costs
  • Configured direct alerts and receive proactive support from Opster

Searching for help with OpenSearch 

Backblaze has been using OpenSearch ever since it launched, after switching out several other logging systems. “When we started using OpenSearch, I discovered that I had way more control over everything in the system, but there was a lot less built in for us. That’s part of why I was so happy to find Opster,” said Billy McCarthy, Senior SysAdmin at Backblaze. “I felt like I was in over my head a lot of the time, especially when the online community wasn’t really there yet and there wasn’t a lot of information out there.”

Backblaze’s primary use case is log analysis, both application logs and system logs, as well as observability. They now manage several on-prem OpenSearch clusters. “Prior to beginning to work with Opster, I was spending about 50% of my time trying to manage OpenSearch,” said McCarthy. “I was doing everything on my own and just trying to keep my head above water.”

“Opster was our first choice for managing Elasticsearch once we started experiencing issues.”

Alessandro Lombardi | Senior System Architect at CoreView

Alessandro Lombardi | Senior System Architect at CoreView

When McCarthy began looking for services to help him manage OpenSearch on-premises, he found very few options. “I couldn’t find resources, no one would even talk to us about helping us manage OpenSearch. Opster’s the only company I found offering a complete solution for OpenSearch.”

McCarthy originally looked to expand the team by hiring someone to be Backblaze’s internal OpenSearch expert, but employees with the right type of experience are hard to find. He ended up bringing on some junior team members, and engaging with the Opster team to conduct training sessions on all things OpenSearch. “It comes out cheaper in the long run.”

“By using the Opster AutoOps system and getting training for my team, I’m able to save so much time and effort that I used to spend on handling OpenSearch.”

Billy McCarthy | Senior SysAdmin at Backblaze

Billy McCarthy | Senior SysAdmin at Backblaze

“At first I was just looking for on-prem tools to help us, and I came across Opster’s free Template Optimizer. I was so impressed with what Opster was offering the community. I ended up in conversation with Ziv Segal, Opster’s CEO, and realized I’d found the solution I’d been looking for. By using the Opster AutoOps system and getting training for my team, I’m able to save so much time and effort that I used to spend on handling OpenSearch.”

Opster – The complete solution for managing and optimizing OpenSearch 

Backblaze began using Opster AutoOps to optimize their system. First, they defined notification to be alerted by the system before any issues arise, to be able to completely prevent production incidents. “With AutoOps and the Opster team’s help, we completely optimized our sharding strategy and improved our slow queries and search performance,” McCarthy said. “Our overall performance has improved so much since we started working with Opster.”

“With AutoOps and the Opster team’s help, we completely optimized our sharding strategy and improved our slow queries and search performance,” McCarthy said. “Our overall performance has improved so much since we started working with Opster.”

“We’re so impressed with AutoOps. It’s a beautiful system, really easy to navigate and configure according to the issues that matter to us. Our whole configuration is easier now.”

The Backblaze team proceeded to start a training course provided by Opster. “One of the amazing things we’re getting out of these learning sessions is understanding the context and the bigger picture. There’s documentation out there, but it’s really hard to understand how it all comes together, what’s actually important and what isn’t. The more we learn, the easier it is for us to do our jobs the right way.”

“Opster is the only company that provides what it does. Others may offer you monitoring, or consultation, but Opster covers absolutely everything you need to successfully run your search deployment. From the set-up to the follow-through, Opster even always makes sure your team has the skills they need to get their jobs done.”

“Opster is the only company that provides what it does. Others may offer you monitoring, or consultation, but Opster covers absolutely everything you need to successfully run your search deployment.”

Billy McCarthy | Senior SysAdmin at Backblaze

Billy McCarthy | Senior SysAdmin at Backblaze

The post How Backblaze Optimized and Manage OpenSearch with Opster appeared first on Opster.

]]>
https://opster.com/case-studies/how-backblaze-optimized-manage-opensearch-with-opster/feed/ 0 Alessandro Lombardi | Senior System Architect at CoreView Billy McCarthy | Senior SysAdmin at Backblaze Billy McCarthy | Senior SysAdmin at Backblaze
OpenSearch Monitoring Tools https://opster.com/blogs/opensearch-monitoring-tools/ Thu, 17 Nov 2022 12:09:38 +0000 https://opster.com/?p=30598 Monitoring tools serve as the first and most basic layer in system observability. This blog post will explore 4 popular open-source tools for OpenSearch tracking, their defining features, and their key differences. It will also explain where such standard monitoring tools are lacking.

The post OpenSearch Monitoring Tools appeared first on Opster.

]]>
Quick Links

Which open-source/free tools should you use for OpenSearch monitoring?

Published on: November 2022

Observability is a critical aspect of operating any system, exposing its inner workings, and facilitating the detection and resolution of problems. Monitoring tools serve as the first and most basic layer in system observability. In OpenSearch, the search engine that powers so many of today’s applications, reliable monitoring is an absolute must and is the primary building block of a successful operation.

OpenSearch infrastructure can be quite complex, requiring the monitoring of many performance parameters that are often interlinked. These include memory, CPU, cluster health, node availability, indexing rates, and JVM metrics (e.g., heap usage, pool size, and garbage collection). There are multiple open-source monitoring tools available for OpenSearch, each with its advantages and limitations. While these tools can be extremely useful, as operations scale, it is common to encounter issues that aren’t easily resolved with the standard tools.

This blog post will explore four popular open-source tools for OpenSearch tracking, their defining features, and their key differences. It will also explain where such standard monitoring tools are lacking and how Opster can help you achieve optimal OpenSearch performance.

Monitoring OpenSearch with open source tools

1. Cerebro

An open-source MIT-licensed web admin tool, Cerebro enables OpenSearch users to monitor and manipulate indexes and nodes, while also providing an overall view of cluster health. It has over a million downloads on Docker and 5k stars on GitHub. Cerebro is similar to Kopf, an older monitoring tool that was installed as a plugin on earlier OpenSearch versions. When web applications could no longer run as plugins on OpenSearch, Kopf was discontinued and replaced by Cerebro, a standalone application with similar capabilities and UI.

Built with Scala, AngularJS, Framework, and Bootstrap, Cerebro can be set up easily, in just a few steps. It also boasts built-in capabilities to conveniently track and oversee operations in OpenSearch, including resyncing corrupted shards to another node, a dashboard showing the replication process in real-time, configuring backup using snapshots, and activating a selected index with a single click.

The Cerebro community is relatively small, resulting in less frequent updates and fewer features. Its documentation is sparse and it doesn’t support data from logs. In addition, while it is an excellent tool for tracking real-time processes, Cerebro does not provide graphs with historic/time-based node statistics and, thus, doesn’t offer anomaly detection or troubleshooting capabilities.

2. Prometheus and Grafana

Prometheus is a powerful metric-collection system capable of scraping metrics from OpenSearch. Grafana is a tool that, when coupled with Prometheus, can be used to visualize OpenSearch data. Both Prometheus and Grafana have larger communities and more contributors than Cerebro and, therefore, provide more features and capabilities. Prometheus and Grafana have 46k stars and 53.1k stars on GitHub respectively, and both have over 10 million downloads on Docker.

Able to display data over long periods of time, Grafana features versatile visual capabilities, including flexible charts, heat maps, tables, and graphs. It also provides built-in dashboards that can display information taken from multiple data sources. There are a large number of ready-made dashboards created by the Grafana community, which can be imported and used in your environment. For example, Grafana’s OpenSearch time-based graphs can display meaningful statistics on nodes. These capabilities make Grafana a good solution for visualizing and analyzing metrics, enabling users to add conditional rules to dashboard panels that can trigger notifications.

A major drawback of Grafana is that it doesn’t support full-text data querying. Moreover, it doesn’t support data from logs.

3. Opster Management Console (OMC)

Opster Management Console (OMC) provides the orchestration, monitoring and management capabilities that are offered by managed services, completely for free. By using the OMC, a single interface, users can: upgrade versions automatically, scale cluster resources, manage certificates & back-ups, monitor resources & costs, and more.

In addition, OMC routinely analyzes the connected system and provides alerts when there are signs of performance degradation. It offers recommendations on how to improve configuration & resolve issues, optimize templates, improve search performance & resource utilization, and reduce needed hardware.

OMC easily runs on any Kubernetes environment (on cloud and on-premise) and supports all versions of OpenSearch. Although the tool is relatively new, it has gained popularity among OpenSearch users due to its capabilities and ease of use. You can install the OMC from here.

So which tool should you choose?

Before you go straight for the OpenSearch monitoring tool with the greatest functionality, there are a few things to consider.

First, Cerebro is easy to set up and operate. Nevertheless, it has fewer its documentation is sparse, it doesn’t support data from logs, and does not provide graphs with historic/time-based node statistics.

Second, as generic monitoring tools, Prometheus and Grafana enable you to monitor everything, but they aren’t tailored to OpenSearch specifically. This can be quite limiting. Although users can plot many different kinds of graphs in Grafana, they cannot display which nodes are connected to the cluster and which have been disconnected. In addition, Grafana does not support an index or shard view, making it impossible to see where shards are located or to track the progress of shard relocation.

Finally, Opster Management Console (OMC) is relatively new but shows great promise and has gained popularity among OpenSearch users due to its advanced capabilities and ease of use.

Why standard monitoring tools aren’t enough

When it comes to OpenSearch, even with reliable monitoring tools in place, you may still encounter sudden, unexpected, and serious downtime episodes. Let’s take a closer look at why this is the case.

There are several reasons monitoring tools alone aren’t enough. For starters, it’s bad practice to install a monitoring tool and forget about it. Rather, you should keep up with the latest configuration guidelines and best practices and know how to implement them correctly.

Second, choosing which metrics to monitor and knowing how to analyze them is no small feat, as OpenSearch infrastructure can become quite complex. With so many metrics interacting with each other, even the smallest change can adversely impact performance. A monitoring tool may indicate you’ve run out of memory, for example, but this information alone isn’t enough to identify the underlying cause, let alone to resolve the issue and prevent recurrence.

Also, while traditional commercial monitoring tools are useful for event correlation and providing alerts, they still lack the capabilities needed to truly get to the bottom of your OpenSearch issues. Despite claims of providing root-cause analysis, these solutions generally provide basic event correlation analysis while failing to identify the root cause, which is critical for forecasting and avoiding future issues.

OpenSearch performance is crucial, especially as operations scale or when applications that affect end users are on the line. Successfully operating OpenSearch requires much more than improved monitoring and alerts: Teams must have access to tools with advanced prediction and problem-solving capabilities in order to tackle the complicated issues that may arise.

Conclusion

Ensuring visibility is critical for successfully managing complex systems. While there are many tools available for monitoring OpenSearch, not all are created equal. Most standard tools offer only basic analysis and do not get to the heart of the problem. Given the complexity of OpenSearch, this is inadequate in production, especially for operations at scale or those affecting customer experience.

No matter which monitoring tool you decide to use and how you’re hosting your OpenSearch deployment, you can benefit from Opster’s complete solution for OpenSearch. With an Opster AutoOps subscription, your database administration will be taken care of from start to finish, including advanced monitoring with proactive incident prevention. You’ll benefit from complete resolution of issues in your infrastructure & data layers, end-to-end support, and constant optimization of your clusters. Try Opster AutoOps for free.

The post OpenSearch Monitoring Tools appeared first on Opster.

]]>
How to solve 8 common OpenSearch errors https://opster.com/blogs/how-to-solve-8-common-opensearch-errors/ https://opster.com/blogs/how-to-solve-8-common-opensearch-errors/#respond Thu, 17 Nov 2022 12:06:36 +0000 https://opster.com/?p=30624 In this blog post, we’ll explain why some OpenSearch errors and exceptions occur and how to avoid them. We'll also review some general best practices that can help you identify, minimize, and handle these issues with greater efficiency.

The post How to solve 8 common OpenSearch errors appeared first on Opster.

]]>
Last updated: November 2022

Developer forums are riddled with questions about OpenSearch errors and exceptions. Although never a pleasant topic, errors and exceptions can serve as a powerful tool, illuminating deeper issues in your OpenSearch infrastructure that need to be fixed. Getting acquainted with some of the prevalent failures will not only save you time and effort, but also help ensure the overall health of your OpenSearch cluster.

At Opster, we have analyzed a wide range of OpenSearch problems to understand what caused them. In this blog post, we’ll explain why some OpenSearch errors and exceptions occur and how to avoid them, and review some general best practices that can help you identify, minimize, and handle these issues with greater efficiency.

Let’s start by taking a look at some of the recurring errors and exceptions that most OpenSearch users are bound to encounter at one point or another.

1. Mapper_parsing_exception 

OpenSearch relies on mapping, also known as schema definitions, to handle data properly, according to its correct data type. In OpenSearch, mapping defines the fields in a document and specifies their corresponding data types, such as date, long, and string.

In cases where an indexed document contains a new field without a defined data type, OpenSearch uses dynamic mapping to estimate the field’s type, converting it from one type to another when necessary. If OpenSearch fails to perform this conversion, it will throw the “mapper_parsing_exception failed to parse” exception. Too many of these exceptions can decrease indexing throughput, causing delays in viewing fresh data.

To avoid this issue, you can specify the mapping for a type immediately after creating an index. Alternatively, you can add a new mapping with the /_mapping endpoint. Note that while you can add to an existing mapping, you cannot change existing field mappings. This would cause the data that is already indexed to be unsearchable. Rather, to make the change properly, you need to reindex the entire index. 

2. BulkIndexError

It’s often more efficient to index large datasets in bulk. For example, instead of using 1,000 index operations, you can execute one bulk operation to index 1,000 docs. This can be done through the bulk API. However, this process is prone to errors and requires you to carefully check for possible problems, such as mismatched data types and nulls.

When it comes to bulk APIs, you need to be extra vigilant, as even if there were hundreds of positive responses, some of the index requests in the bulk may have failed. So, in addition to setting up your bulk API with all the proper conditions ahead of time, go through the list of responses and check each one to make sure that all of your data was indexed as expected.

3. Search Timeout Errors: ConnectionTimeout, ReadTimeoutError, RequestTimeout, and More

If a response isn’t received within the specified search time period, the request fails and returns an error message. This is called a search timeout. Search timeouts are common and can occur for many reasons, such as large datasets or memory-intensive queries.

To eliminate search timeouts, you can increase the OpenSearch request timeout (the default is 30 seconds), reduce the number of documents returned per request, reduce the time range, tweak your memory settings, and optimize your query, indices, and shards. You can also enable slow search logs in order to monitor search run time, scan for heavy searches, and more.   

4. All Shards Failed

When searching in OpenSearch, you may encounter an “all shards failed” error message. This happens when a read request fails to get a response from a shard. The request is then sent to a shard copy. After multiple request failures, there may be no available shard copies left. This can happen when the data is not yet searchable because the cluster or node is still in an initial start process, or when the shard is missing or in recovery mode and the cluster is red.

Many issues can cause this: the node may be disconnected or rejoined; the shards being queried may be in recovery and, therefore, not available; the disk may have been corrupted; a search may have been poorly written (for example, referring to a field with the wrong field type); or a configuration error may be causing an operation to fail.

5. Process Memory Locking Failed: “memory locking requested for OpenSearch process but memory is not locked”

For your node to remain healthy, you must ensure that none of the JVM memory is ever swapped out to disk. You can do this by setting bootstrap.memory_lock to true. In addition, ensure that you’ve set up memory locking correctly by consulting the OpenSearch documentation.

If OpenSearch is unable to lock memory, you will encounter this error message: “memory locking requested for OpenSearch process but memory is not locked.” This can happen when a user running OpenSearch doesn’t have the right permissions. These permissions can be granted by setting unlimit -1 to unlimited as root before starting OpenSearch, or by setting memelock to unlimited in /etc/security/limits.conf. Afterward, set MAX_LOCKED_MEMORY to unlimited and LimitMEMLOCK to infinity. This will prevent OpenSearch from becoming non-responsive and help avoid large GC pauses.

6. OpenSearch Bootstrap Checks Failed

Bootstrap checks inspect various settings and configurations before OpenSearch starts to make sure it will operate safely. If bootstrap checks fail, they can prevent OpenSearch from starting (if you are in production mode) or issue warning logs in development mode. It’s recommended to familiarize yourself with the settings enforced by bootstrap checks, noting that they are different in development and production modes. By setting the system property es.enforce.bootstrap.checks to true, you can avoid bootstrap checks altogether.

7. TransportError 

In OpenSearch, the transport module refers to communication between nodes in a cluster and is used for every call that goes from one node to another. Transport errors are generic, and failures can be due to anything ranging from missing shards, conflicting settings, poorly structured content, network failures, and missing headers. 

There are different types of transport errors. One error message—“TransportError(403, u’cluster_block_exception’, u’blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];’)”—can occur when indexes become read only. This can happen when there isn’t enough available disk space for OpenSearch to allocate and relocate shards to and from nodes. To solve this particular issue, you can increase your disk space, delete old data to free up space, or update your index read-only mode.

Another type of transport error can appear when you try to use an index that was just created, before all the shards were allocated. In this case, you will get a TransportError(503, u”). Transport errors can also be linked to problems with mapping. For example, TransportError (400, u’mapper_pasing_exception’) can occur when you attempt to index a field with a data type that is different than its mapping.  

8. Initialization/Startup Failures

Sometimes, seemingly trivial issues can prevent OpenSearch from starting. For instance, when using conflicting versions of OpenSearch, you may get error messages such as “OpenSearch java client initialization fails” or “\Common was unexpected at this time.”

How to Minimize Errors and Exceptions: Dealing with the Deeper Issues at Play

If you look beyond tackling one error message at a time, you’ll begin to notice that many errors and exceptions are linked to one of three deeper causes: issues with setup and configuration, indexing new information, or cluster slowness. Let’s take a look at some basic guidelines for tackling these problems.

  • Setup and configuration: It’s easy to set up OpenSearch quickly, but making sure it’s production grade requires mindfully configuring your settings. This can help avoid a broad range of errors and exceptions, such as bootstrap checks failure.
  • Indexing new information: In OpenSearch, you must use templates properly, know the scheme structure, and carefully name your variables accordingly. Paying careful attention to these parameters can help you avoid issues like mapping exceptions and bulk index errors. 
  • Cluster slowness: As operations begin to scale, OpenSearch can sometimes slow down unexpectedly, with timeout errors popping up left and right. For this reason, it is crucial that you constantly monitor the activity of your cluster—observing error rate, error logs, and rejected metrics to make sure everything is operating as expected.

Conclusion

Errors and exceptions are bound to arise while operating OpenSearch. Although you can’t avoid them completely, there are some best practices you can employ to help reduce them and to solve problems more efficiently when they do arise. These include paying close attention to your initial setup and configuration and being particularly mindful when indexing new information. In addition, you should have strong monitoring and observability in your system, which is the first basic component of quickly and efficiently getting to the root of complex problems like cluster slowness. In short, instead of dreading their appearance, you can treat errors and exceptions as an opportunity to optimize your OpenSearch infrastructure.  

To easily solve OpenSearch errors, we recommend you try AutoOps for OpenSearch. AutoOps diagnoses issues in OpenSearch based on hundreds of metrics pulled by a lightweight agent. Once diagnosed, the system not only provides root cause analysis, but also resolves the issues. Try it for free.

The post How to solve 8 common OpenSearch errors appeared first on Opster.

]]>
https://opster.com/blogs/how-to-solve-8-common-opensearch-errors/feed/ 0
OpenSearch requirements in production https://opster.com/blogs/opensearch-requirements-in-production/ https://opster.com/blogs/opensearch-requirements-in-production/#respond Thu, 17 Nov 2022 12:01:01 +0000 https://opster.com/?p=30626 To ensure that your OpenSearch is fully prepared for production, it’s imperative that you avoid the major pitfalls. Here are the five major concerns that should be addressed before your OpenSearch, whether already in production or not, can be considered truly production-ready.

The post OpenSearch requirements in production appeared first on Opster.

]]>
Last updated on: November 2022

OpenSearch, an open-source, full-text search engine, allows for massive volumes of data to be stored, searched, and analyzed rapidly in near real-time. OpenSearch is employed behind the scenes, integrating with backend infrastructure where it provides the underlying technology that powers applications.

OpenSearch teams have made a tremendous effort in designing OpenSearch so that it can be set up fairly quickly and reliably, without having to invest much thought in its initial configuration. When a new cluster is first created, the scale is usually small, and everything runs smoothly out-of-the-box.

However, unforeseen complications begin to arise once the OpenSearch cluster begins to scale. As the cluster is loaded with more and more data, and indexing and searches are run more frequently, companies begin to experience severe problems such as outages, degraded performance, data loss, and security breaches. Too often, by the time a company realizes that OpenSearch requires additional resources, time, and/or expertise, it has already become a central component of their operations.

At Opster, we’ve seen many potentially disastrous mistakes made when working with OpenSearch. In this blog post, we present five major concerns that should be addressed before your OpenSearch, whether already in production or not, can be considered truly production-ready.   

Neglecting to Look Inside 

It’s enticing to deploy OpenSearch and just forget about its inner workings. But, because OpenSearch can suddenly slow down, nodes can get disconnected, and systems can even crash unexpectedly. Without proper monitoring and observability, you won’t know why this happened, how it can be fixed, or how to avoid the problem in the future.Monitoring and observability are critical, not just for when things break down, but also for the relentless optimization required of enterprises that wish to maintain their competitive edge. While monitoring reveals whether or not a system is operating as expected, it can’t improve current performance, and it doesn’t explain why something isn’t working the way it should. This is where observability comes in.

Observability gives an end-to-end view of processes, detecting undesirable behavior (such as downtime, errors, and slow response time) and identifying the root causes of problems.

Observability is achieved using logs, metrics, and traces—three powerful tools that are often referred to as the three pillars of observability.

When complex distributed systems start to malfunction, good visibility is crucial for pinpointing the root of the problem and significantly reducing time to resolution. The OpenSearch community provides free open-source monitoring tools that can help enhance visibility, such as Cerbro.

Misconfigured Circuit Breakers  

In OpenSearch, circuit breakers are used to limit memory usage so that operations do not cause an OutOfMemoryError. Sometimes, a modest adjustment to your circuit breakers can make the difference between high-performing clusters and detrimental downtime. OpenSearch queries, whether initiated directly by users or by applications, can become extremely resource-intensive. While the default circuit breaker settings may be adequate in some cases, often adjusting breaker limits is absolutely necessary to ensure that queries do not impede performance or cause outages due to running out of memory (OOM).

Poorly Configured Security Settings  

It’s dangerously easy to misconfigure OpenSearch security settings. If you are not proactive about your security settings, your OpenSearch database can be exposed or leaked. Common security oversights include exposing the OpenSearch rest API to the public internet, not changing default passwords, and neglecting to encrypt data in transfer or at rest. These oversights can leave OpenSearch servers vulnerable to malware or ransomware and subject data to theft or corruption.

Even if your OpenSearch is configured properly with optimal security settings, unprotected OpenSearch Dashboards instances can still compromise your data. OpenSearch Dashboards is an open-source project that performs data analytics and visualization of OpenSearch data. The platform performs advanced analytics on data that it pulls from OpenSearch databases, which it presents graphically through charts, tables, and maps. The problem is that OpenSearch Dashboards isn’t equipped with comprehensive built-in security, especially when being used with the free open-source version of OpenSearch.

Disks and Data Loss

Developer forums are filled with confusion about lost data nodes and unassigned shards in OpenSearch. This calls to attention the necessity of handling disks mindfully to avoid losing data. If you’re not careful when selecting disks for your data nodes, you might find that shards are unassigned and that data is lost after restart. Ensure that data and master-eligible nodes are using persistent storage. in the case of ephemeral disks, however, this is not enough. It is common to select ephemeral disks for their high performance and cost-efficiency; but, without taking the proper precautions, this choice can lead to data loss. When using ephemeral disks, you must have more than one copy of each shard and have a reliable procedure in place to restore data in case all copies are gone.

In the case of ephemeral disks, however, this is not enough. It is common to select ephemeral disks for their high performance and cost-efficiency; but, without taking the proper precautions, this choice can lead to data loss. When using ephemeral disks, you must have more than one copy of each shard and have a reliable procedure in place to restore data in case all copies are gone.

Neglecting Backup and Restore

Although everyone agrees that backup and restoration are important, many companies do not have sufficient backup and restore strategies in place for their OpenSearch clusters.

There’s a lot to take into account when protecting data in OpenSearch. For starters, you should make sure that all your important information is backed up. This may seem obvious, but, because indices are added constantly, you may not have snapshots of all your vital indices, backup may not run as often as it should, and backup processes may fail silently—oversights that you may only discover after it’s too late. Keep in mind that running backup procedures is resource-intensive, so it should be done when the cluster is less loaded.

Even if your backup appears to be running perfectly, you should periodically execute restore procedures to make sure that the data is truly restorable. This can be very time-consuming, so it is advisable to predetermine the order of restoration, ensuring that the most vital data is taken care of first.   

Sometimes it’s wiser not to use backup and restore at all. When OpenSearch mirrors another data source, i.e., it is not the single point of truth, it might be advisable to reconstruct the indices from scratch by reindexing data from the other single point of truth.This might take longer, depending on the nature of the data, but it can take the load off your OpenSearch backup processes, mitigating costs and reducing storage space.           

Summary

OpenSearch is a powerful and widely-used search engine that is at the core of many of today’s technological platforms. It may be easy to manage at first, but as your business scales, you will encounter serious problems if you have not taken some necessary precautions. To ensure that your OpenSearch is fully prepared for production, it’s imperative that you avoid the major pitfalls detailed above.

To detect and resolve OpenSearch errors, we recommend you try the AutoOps platform. AutoOps diagnoses issues in OpenSearch based on hundreds of metrics pulled by a lightweight agent. Once diagnosed, the system not only provides root cause analysis, but also resolves the issues. Try it for free.

The post OpenSearch requirements in production appeared first on Opster.

]]>
https://opster.com/blogs/opensearch-requirements-in-production/feed/ 0
How to Improve OpenSearch Search Performance https://opster.com/blogs/improve-opensearch-search-performance/ https://opster.com/blogs/improve-opensearch-search-performance/#respond Tue, 15 Nov 2022 17:15:11 +0000 https://opster.com/?p=30571 Here are 14 important tips on how to optimize and tune query performance in OpenSearch. First, assigning a huge value to size parameter causes OpenSearch to compute vast amounts of hits, which causes severe performance issues. Instead of setting a huge size...

The post How to Improve OpenSearch Search Performance appeared first on Opster.

]]>
Last Updated : November 2022

If you’re suffering from poor search performance, you should run Opster’s Search Log Analyzer. With Opster’s Analyzer, you can easily locate slow searches and understand what led to them adding additional load to your system. You’ll receive customized recommendations for how to improve your search performance. The tool is free and takes just 2 minutes to run.

14 tips on how to reduce OpenSearch search latency and optimize search performance:

  1. Size parameter

    Assigning a huge value to size parameter causes OpenSearch to compute vast amounts of hits, which causes severe performance issues. Instead of setting a huge size, you should batch requests in small sizes.

  2. Shards and replicas

    Optimize necessary index settings that play a crucial role in OpenSearch performance, like the number of shards and replicas. In many cases having more replicas helps improve search performance. Please refer to Opster’s guide on shards and replicas to learn more.

  3. Deleted documents

    Having a large number of deleted documents in the OpenSearch index also causes search performance issues. Force merge API can be used to remove a large number of deleted documents and optimize the shards.

  4. Search filters

    Effective use of filters in OpenSearch queries can improve search performance dramatically as the filter clauses are 1) cached, and 2) able to reduce the target documents to be searched in the query clause.

  5. Wildcard queries

    Avoid wildcard, especially leading wildcard queries, which causes the entire OpenSearch index to be scanned. 

  6. Regex and parent-child

    Note that Regex queries and parent-child can cause search latency.

  7. Implementing features

    There are multiple ways to implement a specific feature in OpenSearch. For example, Autocomplete can be implemented in various styles. This documentation gives a 360-degree view of both functional and non-functional features.

  8. Multitude of small shards

    Having many small shards could cause a lot of network calls and threads, which severely impact search performance.

  9. Heavy aggregations

    Avoid heavy aggregations that involve unique IDs.

  10. Timeout and terminate

    Timeout param and terminate after param can be useful when executing heavy searches, or when result data is vast.

  11. Search templates

    Use search templates to achieve better abstraction, meaning without exposing your query syntax to your users. Search templates also help you transfer less data over the network, which is particularly useful when you have large OpenSearch queries.

  12. Multi search API

    Use msearch whenever possible. In most of the applications it’s required to query multiple OpenSearch indices for a single transaction, and sometimes users do so in a serial order even when it’s not required. In both cases, when you need to query multiple indices for the same transaction and when the result of these queries are independent, you should always use msearch to execute the queries in parallel in OpenSearch.

  13. Term queries

    Use term query when you need an exact match and on keywords fields. By default, OpenSearch generates both text and keyword fields for every field that consists of a string value if explicit mapping is not supplied. Users tend to use the match query even on keyword data types like product-ids, which is costly as match query goes through an analysis operation. Always use term query on keyword data types and wherever you need exact searches for better performance.

  14. Source filtering

    _source filtering is a great way to improve the performance of OpenSearch queries when retrieving a large number of documents or documents of large sizes. By default, OpenSearch returns the complete source of matching documents. If you don’t need _source at all or need only values of specific fields, you can achieve this with _source filtering.

Say goodbye to search latency and related downtime – Opster’s Search Gateway transforms the way searches are handled in OpenSearch.

Aside from gaining deep visibility of searches and the option to group data by users and application, the Gateway provides users with the unique ability to block heavy searches and prevent them from degrading performance and breaking clusters. Learn more about the Search Gateway and book a demo to get started.

The post How to Improve OpenSearch Search Performance appeared first on Opster.

]]>
https://opster.com/blogs/improve-opensearch-search-performance/feed/ 0