Исправляем статус одиночного сервера ElasticSearch

Thank you for reading this post, don't forget to subscribe!

Оди­ноч­ный сер­вер будет жёл­то­го цвета.

Цвет означает состояние сервера:

  • Зелё­ный — всё хорошо.
  • Жёл­тый — сер­вер пра­виль­но обра­ба­ты­ва­ет все запро­сы на чтение/запись, но есть внут­рен­ние про­бле­мы, кото­рые необ­хо­ди­мо исправить.
  • Крас­ный — всё плохо.

Как увидеть цвет сервера?

    • Запрос:

    • При­мер ответа:


Почему отдельный сервер будет по умолчанию жёлтым?

  • Пото­му что ElasticSearch явля­ет­ся отка­зо­устой­чи­вой систе­мой хра­не­ния дан­ных, кото­рая рас­счи­та­на для запус­ка не на одном сер­ве­ре, а на груп­пе (кла­сте­ре) из несколь­ких свя­зан­ных сер­ве­ров (узлов, “nodes”).
  • В част­но­сти, ElasticSearch под­ра­зу­ме­ва­ет, что при отка­зе одно­го узла систе­ма долж­на сохра­нять пол­ную работоспособность.
  • Для это­го систе­ма долж­на состо­ять из несколь­ких сер­ве­ров (мини­мум — двух, жела­тель­но — трёх для предот­вра­ще­ния split brain), и каж­дая пор­ция дан­ных (т.н. “shard” в тер­ми­но­ло­гии ES) долж­на хра­нить­ся в несколь­ких экзем­пля­рах на раз­ных серверах.
  • Один из этих экзем­пля­ров ES будет счи­тать пер­вич­ным (“master shard”), осталь­ные копи­я­ми пер­вич­но­го (“replica shards”).
  • В систе­ме из одно­го сер­ве­ра ES хра­нит на нём все “primary shards”, но созда­вать “replica shards” такой систе­ме будет негде.
  • Поэто­му ста­тус в при­ве­дён­ном при­ме­ре явля­ет­ся жёл­тым из-за нену­ле­во­го зна­че­ния “unassigned_shards”, кото­рое при­мер­но рав­но “active_shards”.
  • Неболь­шая раз­ни­ца меж­ду коли­че­ством актив­ных и нераз­ме­щён­ных шар­дов обу­слов­ле­на тем, что часть слу­жеб­ных индек­сов явля­ет­ся локаль­ной для каж­до­го узла, то есть не долж­на иметь реплик и не при­во­дит к появ­ле­нию unassigned shards.
  • Подроб­нее о том, что такое шар­ды, зачем они нуж­ны, и какое место зани­ма­ют меж­ду доку­мен­та­ми и индек­са­ми: https://stackoverflow.com/a/49892584/2743554.

Как сделать одиночный сервер зелёным?

    • Сна­ча­ла узна­ем, какие шар­ды систе­ма не суме­ла разместить:
      curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED
    • Теперь посмот­рим, к каким индек­сам они относятся:
      curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }'
    • После это­го поме­ня­ем настрой­ки индек­сов — умень­шим коли­че­ство реплик (так назы­ва­е­мый Replication Factor) до нуля:
    • curl -sS -XGET '127.0.0.1:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | awk '/UNASSIGNED/ { print $1 }' |while read idx; do curl -XPUT "localhost:9200/$idx/_settings" -H 'Content-Type: application/json' -d '{ "index": { "number_of_replicas": 0 } }'done
    • И про­ве­рим результат:


Почему в полночь сервер снова станет жёлтым?

    • Пото­му что в ES при­ня­то каж­дые сут­ки авто­ма­ти­че­ски созда­вать новый индекс с име­нем вида “basename-yyyy.mm.dd” из шаблона.
    • Поэто­му Replication Factor необ­хо­ди­мо умень­шить до нуля не толь­ко в суще­ству­ю­щих индек­сах, но и в шаб­ло­нах, из кото­рых будут созда­вать­ся новые индексы.
    • Это дела­ет­ся так:
    • curl -XPUT "127.0.0.1:9200/_template/all?pretty=true" -H 'Content-Type: application/json' -d \'{ "template" : "*" , "settings": { "number_of_replicas": 0 } }'
  • После это­го посто­ян­ный ста­тус оди­ноч­но­го сер­ве­ра ста­нет зелё­ным, а жёл­тый пре­вра­тит­ся из «фоно­во­го шума» в надёж­ный пока­за­тель про­блем, дей­стви­тель­но тре­бу­ю­щих исправления.