Những gì bạn cần biết về monitoring elasticsearch
Elasticsearch
5
monitoring
3
White

huydx viết ngày 03/08/2017

Elasticsearch là gì

alt text

Elasticsearch chắc hẳn là nhiều người đã biết, nhưng để bài viết trơn tru, cứ phải có cái introduction cho nó dài. Elasticsearch là cơ sở dữ liệu (database) (từng) dành để lưu trữ text (document) là chính, dựa trên một engine nổi tiếng là lucene. Nói là "từng" vì hiện tại elasticsearch được dùng cho cả những ứng dụng thời thượng như là time series data (lưu dữ liệu là các "point" thay vì document) chứ không chỉ dừng lại cho text nữa.

Trong Elasticsearch thì dữ liệu được biểu diễn dưới dạng JSON và có thể dễ dàng truy vấn thông qua REST API cũng như native API (thông qua thư viện). Điểm thú vị của elasticsearch nằm ở chỗ Distributed: Dữ liệu của elasticsearch được phân tán đều trên các node (primary shard / replica shard) và được tự động phân chia lại khi thêm/xoá node đã có. Việc này khiến cho Elasticsearch rất dễ dàng để scale up/down.

Mô hình dữ liệu của ES:

alt text

Về cơ bản thì sẽ có 2 loại node chính trong ES:

  • Master node: Node này có nhiệm vụ đứng mũi chịu sào, chịu trách nhiệm điều hành anh em làm việc (coordinate), cũng như nhận một số trọng trách quan trọng như thêm, xoá index... Khi master node chết thì anh em còn lại sẽ họp lại và tìm ra thằng mới dựa trên một thuật toán gọi là Paxos.
  • Data node: Thằng này là culi, chuyên bốc vác dữ liệu, ai bảo gì làm nấy, có trách nhiệm lưu trữ là chính.

Tuy nhiên distributed cũng khiến cho việc vận hành trở nên painful hơn, nhiều khi do bug của việc cooperate giữa các node, hay là do các hoàn cảnh không dự đoán trước được như server gặp mưa, server gặp bão, cá mập cắn cáp... Ngoài ra một số design của elasticsearch (hay cũng như nhiều database khác) khiến cho nó có thể chết không dự đoán trước được do hết memory hay gặp phải query nặng hơn nó có thể chịu được.

Để vận hành đỡ painful thì việc quan trọng nhất chính là monitoring, tức là nắm được elasticsearch cluster của bạn đang hoạt động thế nào mà không cần phải nhìn log hay là các kiến thức cao siêu mà không phải ai cũng biết. Và cuối cùng chúng ta cũng đén được phần chính của bài viết: chúng ta cần monitoring "cái gì" để biết về sức khoẻ của elasticsearch cluster?

Những metrics cần xem khi monitoring ES

Search performance

Đây là một trong những chỉ số quan trọng nhất khi mà chức năng chính của ES là .. tìm kiếm. Những chỉ số có thể lấy được từ ES liên quan đến search performance gồm có

Total number of queries indices.search.query_total Throughput
Total time spent on queries indices.search.query_time_in_millis Performance
Number of queries currently in progress indices.search.query_current Throughput
Total number of fetches indices.search.fetch_total Throughput
Total time spent on fetches indices.search.fetch_time_in_millis Performance
Number of fetches currently in progress indices.search.fetch_current Throughput

Để hiểu hơn những chỉ số trên thì chúng ta cần hiểu trước về việc: Elasticsearch thực hiện việc "tìm kiếm" thế nào? Khi có một request về tìm kiếm thì đầu tiên request sẽ được gửi đến một data node bất kì chữa data của một index nào đó. Sau đó thì node này sẽ gửi request đến tất cả các node xung quanh mà chứa shard của index đang tìm, và nhận kết quả từ các node xung quanh, việc này được gọi là Fetching.
Theo như bảng ở trên thì chúng ta sẽ cần theo dõi các yếu tố chính dưới đây:

  • Query Load : dựa vào "số lượng" query hiện tại đang được thực hiện, qua đó xem cluster có bị quá tải không
  • Query Latency : dựa vào query time, chúng ta có thể biết cluster mất bao nhiều lâu để trả về một request
  • Fetch Latency : nếu fetch tốn quá lâu, thì khả năng cao sẽ là do disk hay network có vấn đề

Index performance

Nếu coi tìm kiếm là thao tác "read" thì index chính là thao tác "write". Để có performance tốt nhất thì các database thường tiết kiệm việc phải ghi dữ liệu vào disk (fsync) thông qua buffer, tức là lưu tạm ở memory trước, đợi nhiều nhiều rồi ghi vào disk cả thể. Elasticsearch cũng vậy, việc này thể hiện ở diagram dưới đây:

alt text

alt text

Nhìn vào 2 diagram ở trên chúng ta cần chú ý đến 2 thao tác là RefreshFlush. 2 thao tác này dựa trên một đơn vị gọi là "Segment". Bạn nào từng làm việc với các hệ thống database (Postgres, cassandra, influxdb) thì sẽ hiểu rằng có các đơn vị dữ liệu không thay đổi được (immutable) là rất quan trọng trong việc tạo ra một database với high write throughput. Việc này dựa trên idea chính là, cứ write đã, đúng sai tính sau (việc đúng sai tính sau thể hiện bằng thao tác "merge" được thực hiện ở background). Ở đây thì "Segment" chính là đơn vị dữ liệu không thay đổi (immutable data) của elastic search.
Một segment được tạo mới thông qua Refresh và được ghi vào đĩa + merge thông qua Flush. Flush sẽ được trigger khi memory đến giới hạn, hoặc sau một khoảng cách thời gian nào đó (khoảng sau mỗi 30 phút).

Để theo dõi các thông số liên quan đến index thì có các chỉ số dưới đây

Total number of documents indexed indices.indexing.index_total Throughput
Total time spent indexing documents indices.indexing.index_time_in_millis Performance
Number of documents currently being indexed indices.indexing.index_current Throughput
Total number of index refreshes indices.refresh.total Throughput
Total time spent refreshing indices indices.refresh.total_time_in_millis Performance
Total number of index flushes to disk indices.flush.total Throughput
Total time spent on flushing indices to disk indices.flush.total_time_in_millis Performance

Từ những con số trên các bạn có thể hiểu ra được

  • Index latency: thông qua index_total và index_time_in_millis thì bạn có thể thấy ES tốn bao nhiêu thời gian cho việc indexing , và đang phải chịu tải là bao nhiêu request.
  • Flush latency : thông qua flush.total_time_in_millis thì bạn có thể thấy được latency của thao tác Flush. Nếu latency quá cao, thì có khả năng bạn đang gặp phải vấn đề về disk, hoặc là flush size quá lớn.

JVM metrics

Elasticsearch được build trên java. Vận hành một hệ thống java mà không hiểu về JVM thì coi như bạn toi chắc rồi. Để monitoring JVM system thì việc kiểm soát Memory và GC là 2 cái quan trọng nhất. Đặc biệt memory là cái tối quan trọng khi mà một query nặng có thể dẫn đến memory vượt quá kiểm soát và JVM sẽ lăn ra chết, hay là trở nên unresponsive. Khi nhìn vào heap thì quan trọng nhất là xem heap percent, tức là trong XXGB memory đã được cấp phát cho JVM, thì bao nhiêu % đã và đang được sử dụng.

Bên cạnh đó thì việc nhìn vào GC (mặc dù có nhìn thì cũng không làm được gì vì GC nằm ngoài tầm kiểm soát của bạn) cũng khá có ích để phán đoán việc khi ES cluster của bạn trở nên chậm chạp thì liệu có phải do ES bug không :v. ES team cũng khuyến cáo người dùng đừng có cố thay đổi GC option default: https://www.elastic.co/guide/en/elasticsearch/guide/current/_don_8217_t_touch_these_settings.html

Host metrics

Host metrics là những metrics thể hiện sự khoẻ mạnh của machine nói chung. Nó bao gồm những thông số như diskSpace, CPU usage , IO utilization. Như đã nói ở trên thì việc disk chậm, CPU bị starve cũng đều ảnh hưởng đến chức năng tìm kiếm rất lớn (tất nhiên rồi :v), vậy nên việc theo dõi những thông số này một cách chặt chẽ cũng giúp ích rất nhiều trong việc trouble shooting cũng như dự đoán trước về performance downgrade của ES.

Cluster health

Những thông số tôi đã nói ở trên hầu hết thể hiện sự khoẻ mạnh của một node trong toàn thể cluster. Vậy làm thế nào để biết được sự khoẻ mạnh "tổng thể" của toàn bộ cluster?

Cluster status (green, yellow, red) cluster.health.status Other
Number of nodes cluster.health.number_of_nodes Availability
Number of initializing shards cluster.health.initializing_shards Availability
Number of unassigned shards cluster.health.unassigned_shards Availability

Quan trọng nhất, và cũng dễ hiểu nhất chính là "Cluster status".

  • Green: khoẻ mạnh, không vấn đề gì
  • Yellow: Một hoặc một vài replica shard đột nhiên biến mất, và nếu nó tiếp tục biến mất nữa, bạn sẽ mất dữ liệu khi tìm kiếm (có thể hiểu yellow là threshold trước khi dữ liệu tìm kiếm không còn toàn vẹn nữa )
  • Red: Một hoặc một vài primary shard biến mất, điều này có nghĩa là chắc chắn kết quả search của bạn sẽ không toàn vẹn, sẽ thiếu data.

Bên cạnh cluster status thì Initializing and unassigned shards cũng khá quan trọng, nó thể hiện các shard mà đang được khởi động , hoặc chưa được assigned cho master, nếu con số này không về 0 không một nhanh chóng, chứng tỏ rằng cluster của bạn đang ở trạng thái rất thiếu ổn định.

Làm thế nào để monitoring?

Như vậy là chúng ta đã nắm được là : cần phải xem gì, nhưng chúng ta vẫn chưa đề cập đến việc: làm thế nào để xem các thông số đó. Elasticsearch cung cấp cho chúng ta tất cả các thông số ở trên thông qua HTTP GET một cách rất dễ dàng, dựa vào endpoint /_nodes/_local/stats

Đây là ví dụ khi tôi vào một node bất kì với url : node-name/_nodes/_local/stats

alt text

Để lưu dữ liệu lại và xem dưới dạng graph, bạn có thể sử dụng những service hiện có như datadog, hay là sử dụng solution có sẵn như prometheus + elasticsearch_exporter

Kết luận

Việc tìm hiểu xem một hệ thống middleware xem cần monitoring những gì và hiểu rõ về từng metrics phải monitoring sẽ giúp chúng ta có thêm nhiều kiến thức rât bổ ích về internal của middleware đó. Trong bài tiếp theo tôi sẽ nói về monitoring metrics của mysql, đợi năm sau nhé :P.

Reference

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

huydx

116 bài viết.
960 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
153 14
Introduction (Link) là một cuộc thi ở Nhật, và cũng chỉ có riêng ở Nhật. Đây là một cuộc thi khá đặc trưng bởi sự thú vị của cách thi của nó, những...
huydx viết gần 2 năm trước
153 14
White
126 15
Happy programmer là gì nhỉ, chắc ai đọc xong title của bài post này cũng không hiểu ý mình định nói đến là gì :D. Đầu tiên với cá nhân mình thì hap...
huydx viết hơn 3 năm trước
126 15
White
98 10
(Ảnh) Mở đầu Chắc nhiều bạn đã nghe đến khái niệm oauth. Về cơ bản thì oauth là một phương thức chứng thực, mà nhờ đó một web service hay một ap...
huydx viết 3 năm trước
98 10
Bài viết liên quan
White
5 0
About elasticsearch memory control Elasticsearch rất dễ bị die bởi OOM(OutOfMemory) bởi memory trên ES được dùng intensive trong rất nhiều logic k...
huydx viết hơn 1 năm trước
5 0
White
10 0
Có cái note từ xưa hồi mới học ES nhét ở evernote, để lên đây cho khỏi mất Elasticsearch Document == row, grouped by types, multiple types == i...
huydx viết gần 2 năm trước
10 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
116 bài viết.
960 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!