Elasticsearch monitoring tool - A chrome extension

Announcements Community Ecosystem
1

Hey guys,

I've been debugging Elasticsearch clusters for years, and I got tired of jumping between _cat APIs, and terminal tabs just to check cluster health. So I built a lightweight Chrome extension that surfaces the metrics I actually care about right from the browser toolbar. No agents, no setup overhead.

I'm sharing some of the metrics and insights below.

  • indexing rate/latency & search rate/latency
  • cluster status
  • node stats
  • JVM heap
  • Active HTTP traffic
  • long running tasks (reindex, update by query, etc)
  • Slow search detection (with auto collect and profile aka. diagnose)

It's called Searchali Monitoring (Elasticsearch Performance Monitoring) and I'd genuinely love feedback from people who live in ES clusters daily. Happy to answer questions or take feature requests here.

:link: https://www.searchali.com/monitoring

image
image1280×800 159 KB

2

Ive installed it and the first thing which I note is that for every indicie it gives you an index rate and search rate per second so you can immediately see where data is going etc very quickly. I haven't found this in elasticsearch/kibana GUI anywhere but I'm a beginner in this space so may be somewhere. Anyway this is good.

3

Thank you so much for your feedback @geoffrey. I'm glad to hear you like the product.

indexing rate/latency and search rate/latency metrics also available in stack monitoring and AutoOps, but you should install an agent. Also in stack monitoring you should keep the data on your own cluster.

4

I notice in the screen for SHARD information that it is trying to display a fixed number of indicies irrespective of screen width. This means you can end up doing a lot of scrolling left and right on each page of indicie information. If it was able to dynamically determine how many indicies it can display (with no left-right scroll bar needed) I reckon this would be better as you now only have to only move pages forward and back.

image
image3678×1787 304 KB

5

Hi @Musab_Dogan

I see in the p0 and r0 boxes you colour the background based on activity on the indicie in question. I would say that it is quite hard to pick this background colour up. If you used a bit different colour for the background it would probably be more noticeable. When in dark mode the colour is very similar to the background anyway.

This may be because I have too little index activity to show your colour intentions well.

image
image1094×897 47.8 KB

6

Were you going to do this monitoring tool for edge browser ?

7

hmm, good idea to make the colour more appeared. I'll check that. Thanks for your feedback.

Regarding to adding the extension to edge browser, it's on the roadmap. Whenever I saw a real potential in edge browser I'll add it. Just fyi, the number of users is less than %10 when you compare the chrome users :slight_smile:

If you like the product, I'd love to get your feedback chrome webstore too: https://chromewebstore.google.com/detail/elasticsearch-performance/eoigdegnoepbfnlijibjhdhmepednmdi/reviews

Thanks in advance.

8

Agreed. I fixed it at 7 indices per page. thanks for detailed feedback. It'll be available in the next version. which is 2.2.0

image
image1920×1058 205 KB

9

Hi @Musab_Dogan,

In regards to the CLUSTER stats it does a nice little summary of the transforms but in the description field it adds "data_frame_" to the beginning of the names of the transforms. This means that the identification of which transform is being referenced is not immediately obvious - you need to hover over the description to get the full name:

image
image3674×441 67.4 KB

10

I used to be a chrome user for quite some time but 2 years ago changed to edge. This was in part because of the RAM consumption of chrome. I reckon the edge of today uses less RAM than chrome and i dont have issues with any websites with edge.

11

When I go into the TRAFFIC tab it initially appears to display network communications along the lines I would have expected:

Screenshot 2026-08-16 115523
Screenshot 2026-08-16 1155231920×621 106 KB

Once it has displayed this for more than 30 seconds all the communicating nodes on the right appear to disappear into the heading QUIET IPS. Typically it drops down to just one device showing as communicating:

Screenshot 2026-08-16 115534
Screenshot 2026-08-16 1155341920×612 76.7 KB

The IPs that I know are communicating with the elastic servers never reappear. It is only when you go to another tab and then return to the traffic tab that you get another 30s of useful information. As a result of this behaviour it is not particularly useful.

12

In your NODES tab the networking section can just say Incoming and Outgoing. The current wording of "Transport RX/s" seems unnecessary:

image
image1653×313 18.3 KB

I would just call it transmitted (or TX/s) and received (RX/s).

13

Thanks a lot for great feedbacks @geoffrey. Let me answer it one by one.

  1. long running tasks - the tool show the long running tasks include internal default transform tasks. the explanation, "data_frame_...." is coming from the _tasks api call results. I'm planning to drop all internal tasks from long running tasks screen.

  2. browser extension - Thanks a lot for your feedback about edge vs chrome. We will see the results :slight_smile: Whenever I reach 1k users in chrome I'll plan to implement edge/firefox extension, app, web, docker image.

  3. TRAFFIC tab - (only works with Elasticsearch because OS doesn't have that information). For the initial request, the API call collect all endpoints and draw the picture. 30 seconds later, the tool send another API call and compare the metrics espcially the `request_count`. If the request_count not changed the IP will be marked as passive that you can see at the bottom of the list. With the following message Quiet · 49 IPs No requests in the last 60s. Hidden from the map to reduce noise.

    1. The IPs that I know are communicating with the elastic servers never reappear - I check like 100 times and I can see the correct index/search/update requests with correct IP addresses. Can you make a test for me? For example, run a script to send 10 search requests per second and check the screen again.
      image
      image1920×1056 249 KB

  4. Nodes => Transport RX/s - You're right. The names updated to Incoming (RX) | Outgoing (TX) . It'll be available in the next version.

@geoffrey this is for your great feedbacks :bouquet: Thanks.

14

OK thanks for that. I guess in light of this I wonder if it perhaps would be worthwhile having a dropdown where you can specify how long a connection needs to be quiet before being dropped. As it currently stands, the 30 seconds you get, is sufficiently small that you are looking at what is happening and then it all disappears. The dropdown will allow some level of control around how long you get to observe things before they clear.

Also, with these discussions, if I send I think it is 3 replies and get nothing back it prevents me from doing any other replies until someone else says something. I was not aware of this limitation but I have to say its another "rule" that is annoying.

Anyway, thanks for the changes done so far. I using it daily more for my understanding of elasticsearch & kibana which is great.

15

The main idea for this extension is "real time monitoring and trouble shooting". But we can see the history from first click to extension to current view. I'll think about a dropdown for some control.

I was not aware of 3 replies rule :slight_smile: sorry for that, I missed your message. I didn't receive any update.

Happy to hear you are using daily. Let me know if you have any more quesitons.