Monitor TFS Search Data Usage
Monitor TFS Search Data Usage
Learn how do monitoring of the instance of a searches component that is in a different machine on a TFS installation.
Join the DZone community and get the full member experience.Join For Free
In a previous post, I explained how to move a searches component in a different machine on a TFS 2018 installation. Now, it is time to understand how to monitor that instance.
First of all, you should monitor the folder that physically contains data. In my installation, it is C:\tfs\ESDATA. This is a parameter that you choose when you configure the Search Server with the
Configure-TFSSearch.ps1 -Operation install PowerShell script. The data folder should be placed on a fast disk; usually, SSD is the best choice. If the SSD ever fails, you can always restart ES with an empty data folder and use scripts to force TFS to reindex everything.
Data in ElasticSearch can be wiped away without a problem; like a database warehouse, its content can always be restored.
If you want to have a better idea of what is happening to your search instance, you can install plugins to ease management. The first step is to connect to the machine where the Search Service is running and locate the folder where ElasticSearch was installed. A simple trick is checking the corresponding Windows Service.
Figure 1: Locate ElasticSearch binaries from Windows Service
Now, simply open a command prompt and change the directory to the
bin installation directory of ElasticSearch. From here, you can install various plugins to simplify ES management. I usually start with the HQ plugin; you can install it with the simple instruction:
plugin install royrusso/elasticsearch-HQ/v2.0.3
You should check the correct version on the HQ home site — currently, version 2.0.3 is the latest version that works with ES 2.4.1, the version used by TFS Search Service. For this command to be able to run, the machine should have an internet connection and the GitHub site should not be blocked.
Figure 2: HQ was correctly installed
Now, you can just browse to http://localhost:9200/_plugin/HQ to open the web interface of the HQ plugin and connect to the actual instance.
Figure 3: HQ plugin up-and-running and ready to be connected to a local instance of ES
Figure 4: The homepage of HQ, where you can find the total size used by the server (1) as well as some node diagnostics (2)
From the Node Diagnostics tool, you can find if some statistics are not good. In my example, I have Search Server on a server with slow disk, and query time is sub-optimal. Usually, ES is supposed to answer in less than 50 milliseconds; in my installation, I have an average time of 660 ms.
Figure 5: Statistics on search.
If you move the mouse over the number, it can give you some hints on the reason why the specific number is calculated and why it is not considered to be good.
Figure 6: Help on the various number gives you an idea of what is wrong and how you could solve this.
I suggest that you navigate in the HQ interface to familiarize yourself with the various information it can give to you, especially clicking on the name of a single node (there is only one node in my installation). You can get some interesting data on that single node, especially on RAM usage.
Figure 7: Ram usage of a single node.
There are lots of other plugins that can show lots of useful information about your ElasticSearch instance. The installation is similar to HQ and you can install and use them with very few clicks.
Published at DZone with permission of Ricci Gian Maria , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.