Welcome!

Apache Authors: Liz McMillan, Carmen Gonzalez, Elizabeth White, Pat Romanski, Christopher Harrold

Related Topics: Java IoT, Industrial IoT, Microservices Expo, Open Source Cloud, @CloudExpo, Apache

Java IoT: Article

Tracing Black Boxes II: Monitoring Solr

Providing insight into Apache Solr instances by correlating individual traces with JMX metrics

Your site is indexed on Google, but that doesn't mean you're done with search. Content-rich websites provide native search functionality to keep users engaged, maintain visual consistency, and provide content-aware filtering. But it's very hard to implement an effective, scalable search system, which is why Apache Solr is just about the most popular ‘black box' in web application infrastructure. This Lucene-backed search appliance has seen wide adoption due to its performance, reliability, and ease of deployment. In fact, it's become so widely used that many Solr deployments are managed by people who have no other exposure to running Java applications. Documents go in, indexed RESTful search comes out - that is, until something breaks.

TraceView can provide insight into Apache Solr instances by correlating individual traces with JMX metrics, such as the rate of requests over the past 5 minutes. Even at a very low overall volume, an increased traffic rate is already increasing request latency.

TraceView can provide insight into Apache Solr instances by correlating individual traces with JMX metrics, such as the rate of requests over the past 5 minutes. Even at a very low overall volume, an increased traffic rate is already increasing request latency.

Unlike most web application front-ends, Solr is a complex, stateful application that contains persistent objects, runs background indexing processes, and maintains multiple tiers of caches. There are a lot of ways to deploy and configure Solr, and that means there are a lot of ways to make mistakes. But even when you have everything up and running, there's always the lingering question of whether you could be getting more out of your Solr instances (or reducing the number of them!).

One of the best ways to get insight into Solr's internal abstractions - such as cores, handlers, and components - is to monitor them directly via JMX. I've previously written about using JMX metrics to keep tabs on JVM memory internals, but JMX is a common API for collecting data from your Java applications and any application can make use of it. Because of this it's been widely adopted in the Java ecosystem to centralize the provision of application-specific performance data.

Solr provides JMX metrics on a variety of internals, such as queryResultCache.

 

Solr provides JMX metrics on a variety of internals, such as queryResultCache.

 

Solr exposes hundreds of JMX metrics across dozens of categories, and efficient use of them can help you delve into Solr performance in a variety of ways. Some metrics are better for providing a high-level view of Solr's overall workflow. The queryResultCachecategory, pictured above, provides a snapshot of how often your data was successfully cached, as well as how often cache entries had to be evicted due to insufficient space. Other metric categories are more granular and provide detail at the level of classes, or even objects. An update request will be routed to a different handler depending on whether the data was provided in XML, CSV, or JSON; each of these update handlers exposes metrics independently, like how long it has been running and the number of errors.

JMX metrics can even provide insight into advanced Solr use cases, like modifying result scoring to permit n-dimensional spatial searches or customizing results based on user data stored in Redis. Even without adding custom JMX metrics, Solr will report enough data to allow you to separately track the effectiveness of these custom searches relative to more traditional queries.

Let's look at a practical example. You just got paged because half of your distributed Solr cluster lost connectivity in a widespread EC2 outage. It looks like it might last a while, so you decide to add additional capacity in one of the functioning availability zones. Rather than spending time re-indexing your content, you decide to replicate your existing Solr data to the new servers. Using the high-level metrics provided byReplicationHandler, you determine that replication is proceeding smoothly. Halfway through your second replication, though, you realize that the first replicated server is taking five times as long as your original servers to respond to the same user queries, even though it's running on the same hardware. Checking out the cache metrics for a specific search handler, it looks like the hit ratios on its caches are abysmal - but wait, what's actually in those caches? After checking the metrics for that node's active Searcher instance, you realize you didn't set up Solr to warm the cache - it was starting off empty! Now you know to make a quick configuration change next time you spin up an instance so that the first users routed to it will have acceptable performance.

So, that sounds awesome - but how do you do it? The easiest approach is to view Solr's JMX statistics through its web interface (in Solr 3.x,
it's at /solr/admin/stats.jsp, while in Solr 4.x it's available at a collection-based URL like /solr/#/collection1/plugins/). However, web access won't be an option for most deployments. Alternately, you could use remote jconsole, but that requires either a complex remote configuration that's a tremendous hassle to set up or the glacially slow option of SSH X11 forwarding (e.g., ssh -X solr jconsole).

In practice, those approaches all suck. Solr is stunningly verbose: it exposes hundreds of JMX metrics out of the box, and that number expands quickly as you add additional handlers and components. Purpose-built JMX monitoring tools like jconsole are great for browsing the available metrics to see what's available, but they're horrible for pulling out the ones you want in a hurry. They also allow ‘write' operations like initiating garbage collection or clearing caches - definitely not something you want to give out to every developer!

TraceView automatically monitors the JMX metrics of every node involved in this distributed Solr Cloud trace.

 

TraceView automatically monitors the JMX metrics of every node involved in this distributed Solr Cloud trace.

On a day to day basis, it's more common to read JMX metrics via automated, ‘read-only' monitoring tools like NagiosGanglia, or AppNeta TraceView. These tools not only present a number of metrics at once, but they also generally let you filter down to a meaningful subset of the hundreds of lines exposed by Solr. On the other hand, "health check"-style metrics aren't necessarily the only way to look the problem. Each request has a number of metrics it can generate, and bringing together these data sources in one application has some real advantages. Looking at an individual request can tell you exactly what went wrong, it's often the context of JMX data that says why. Examining the concurrent host activity can disambiguate between whether a pause was due to a garbage collection event in the JVM or an overloaded document cache in Solr forcing additional disk access.

Next time, we'll talk about how TraceView captures these request-based metrics directly from the Solr internals. In the meantime, if you've got a Solr installation, sign up for your free account, put in on that server, and take a look inside that black box!

More Stories By James Meickle

James started as a hobbyist web developer, even though his academic background is in social psychology and political science. Lately his interests as a professional Drupal developer have migrated towards performance, security, and automation. His favorite languages is Python, his favorite editor is Sublime, and his favorite game is Dwarf Fortress.

IoT & Smart Cities Stories
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
In an age of borderless networks, security for the cloud and security for the corporate network can no longer be separated. Security teams are now presented with the challenge of monitoring and controlling access to these cloud environments, at the same time that developers quickly spin up new cloud instances and executives push forwards new initiatives. The vulnerabilities created by migration to the cloud, such as misconfigurations and compromised credentials, require that security teams t...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
After years of investments and acquisitions, CloudBlue was created with the goal of building the world's only hyperscale digital platform with an increasingly infinite ecosystem and proven go-to-market services. The result? An unmatched platform that helps customers streamline cloud operations, save time and money, and revolutionize their businesses overnight. Today, the platform operates in more than 45 countries and powers more than 200 of the world's largest cloud marketplaces, managing mo...
When Enterprises started adopting Hadoop-based Big Data environments over the last ten years, they were mainly on-premise deployments. Organizations would spin up and manage large Hadoop clusters, where they would funnel exabytes or petabytes of unstructured data.However, over the last few years the economics of maintaining this enormous infrastructure compared with the elastic scalability of viable cloud options has changed this equation. The growth of cloud storage, cloud-managed big data e...
Your applications have evolved, your computing needs are changing, and your servers have become more and more dense. But your data center hasn't changed so you can't get the benefits of cheaper, better, smaller, faster... until now. Colovore is Silicon Valley's premier provider of high-density colocation solutions that are a perfect fit for companies operating modern, high-performance hardware. No other Bay Area colo provider can match our density, operating efficiency, and ease of scalability.