Elasticsearch:Yüksek disk kullanımı ve salt okunur dizinler

Belirtiler

• Yazma istekleri şu hata ile başarısız olur: FORBIDDEN/12/index read-only / allow delete (api)

• Küme sağlık durumu kırmızı renktedir. Düğümlerin kümeye yeniden katılıp katılmadığını kontrol etmek için GET /_cat/nodes?v komutunu çalıştırın. Parça atamasını kontrol etmek için GET /_cat/allocation?v komutunu çalıştırın.

  Not

  Kırmızı küme sağlık durumu, birincil parçaların kullanılamadığı anlamına gelir. Verileriniz risk altında olabilir.

• Ingest işlem hatları oluştururken veya Beats kaydı yaparken Kibana internal server error hatası döndürür

• Küme veya Kibana izleme verileri, disk kullanımının %100'e yaklaştığını gösterir

Temel neden

Disk kullanımı eşikleri

Elasticsearch disk kullanımını sürekli olarak izler ve üç su seviyesi eşiğini uygular:

• %85 — düşük su seviyesi: Elasticsearch bu düğüme yeni parça atamayı durdurur.

• %90 — yüksek su seviyesi: Elasticsearch mevcut parçaları daha fazla boş disk alanına sahip düğümlere taşır.

• %95 — sel aşaması: Elasticsearch tüm dizinlerde read_only_allow_delete niteliğini ayarlar ve tüm yazma işlemlerini engeller.

Disk su seviyesi eşiklerine ek olarak aşağıdaki koşullar da yazma hatalarına veya uyarılara neden olabilir. Bu nedenleri birlikte inceleyin:

Parça sayısı sınırına ulaşıldı

Varsayılan olarak, bir Elasticsearch kümesindeki her veri düğümü en fazla 1.000 parçayı destekler. Mevcut sınırı doğrulamak için GET /_cluster/settings?include_defaults=true&flat_settings=true komutunu çalıştırın ve cluster.max_shards_per_node parametresini kontrol edin. Parça sayısı sınırı aştığında Logstash günlükleri yazamaz ve yeni dizinler oluşturulamaz.

Geçici bir çözüm olarak parça sınırını artırmak için aşağıdaki komutu çalıştırın:

PUT /_cluster/settings
{
  "transient": {
    "cluster": {
      "max_shards_per_node": 2000
    }
  }
}

Uzun vadeli bir çözüm için süresi dolmuş veya kullanılmayan dizinleri temizleyin ya da kümeye daha fazla veri düğümü ekleyin.

Sistem dizini yaşam döngüsü ilkeleri

Disk kullanımı sık sık dalgalanıyorsa ancak özel Index Lifecycle Management (ILM) ilkeleri yapılandırılmamışsa bu dalgalanma, .monitoring-es-* ve .monitoring-kibana-* gibi sistem dizinlerinin varsayılan yaşam döngüsü ilkelerinden kaynaklanıyor olabilir. Bu dizinler günlük olarak otomatik olarak oluşturulur ve eski dizinler otomatik olarak silinir. Bu normal bir davranıştır.

Kaynak ilişkili etki

Yüksek disk kullanımına yüksek JVM bellek kullanımı (örneğin %90'a ulaşması) ve düğüm anormallikleri eşlik edebilir; bu durum Kibana'nın bağlanmasını engelleyebilir. Bu durumda hem disk kapasitesini hem de bellek kaynaklarını ölçeklendirin. Küme sağlıksız durumdaysa yapılandırma yükseltmesi sırasında zorunlu değişiklikleri etkinleştirin. Düğüm yeniden başlatmalarından kaynaklanan hizmet kesintilerini önlemek için işlemi iş saatleri dışında gerçekleştirin.

Hızlı çözüm (10–15 dakika)

1. Disk alanını boşaltmak için eski veya kullanılmayan dizinleri silin.

   Uyarı

   Silinen veriler geri yüklenemez. Verileri korumak için bunun yerine depolarma kapasitesini artırma seçeneğini değerlendirin.

   curl -u <username>:<password> -XDELETE http://<host>:<port>/<index-name>

   • <host>, kümenizin dahili veya genel uç noktasıdır. Bu komutu çalıştırmadan önce erişim izin listesini yapılandırın.

   • Küme yanıt vermiyorsa zorunlu bir yeniden başlatma tetikleyin ve bu komutu yeniden başlatma sırasında çalıştırın.

2. Salt okunur kilidini kaldırın. Disk alanını boşaltmak yazma engelini otomatik olarak kaldırmaz. Engeli kaldırmak için index.blocks.read_only_allow_delete değerini null olarak ayarlayın:

   PUT /_all/_settings
   {
      "index.blocks.read_only_allow_delete": null
   }

3. Küme sağlığını doğrulayın. Durum hala kırmızıysa atanmamış parçaları kontrol etmek için GET /_cat/allocation?v komutunu çalıştırın.

4. Atanmamış parçalar kalıyorsa nedeni belirlemek için GET /_cluster/allocation/explain komutunu çalıştırın. Çıktı tükenmiş atama yeniden denemelerini gösteriyorsa (aşağıda gösterildiği gibi) POST /_cluster/reroute?retry_failed=true komutunu çalıştırın.

   "deciders": [
     {
       "decider": "max_retry",
       "decision": "NO",
       "explanation": "shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2020-02-14T00:22:25.939Z], failed_attempts[5], delayed=false, details[failed shard on node [xxx]: shard failure, reason [lucene commit failed], failure IOException[No space left on device], allocation_status[deciders_no]]]]"
     }
   ]

   Diski ölçeklendirdikten veya verileri temizledikten sonra hatalar devam edebilir. Disk kullanımı %100'e ulaştığında parça ataması başarısız olur ve başarısız yeniden deneme sayacı tükenir. Diski genişlettikten veya verileri sildikten sonra bile bazı parçalar atanmamış kalabilir ve sorgular 503 search_phase_execution_exception gibi hatalarla başarısız olmaya devam eder.

   Bu durumda başarısız olan parça atamalarını yeniden denemek için manuel olarak POST /_cluster/reroute?retry_failed=true komutunu çalıştırın. Komut döndükten sonra parça kurtarma işleminin tamamlanmasını bekleyin. Küme kurtarma tamamlandıktan sonra normal hizmete döner.

5. Tüm kurtarma adımlarından sonra küme sağlık durumu kırmızı olarak kalıyorsa Alibaba Cloud teknik desteğiyle iletişime geçin.

SSS

Neden Elasticsearch konsolu normal küme durumu göstermesine rağmen hala disk kullanımı uyarıları alıyorum?

Konsoldaki normal küme durumu kümenin şu anda kullanılabilir olduğunu yalnızca gösterir. Ancak disk kullanımı zaten uyarı eşiğine (örneğin %91) ulaşmış olabilir. Yüksek disk kullanımı henüz hemen read_only modunu tetiklememiş olsa da kritik su seviyesine yaklaşmaktadır; %95'te zorunlu salt okunur modu tetiklenir ve yazma işlemleri herhangi bir anda engellenebilir.

Riski ortadan kaldırmak için Cluster Monitoring sayfasındaki gerçek disk kullanımını hemen kontrol etmenizi ve aşağıdaki eylemlerden birini uygulamanızı öneririz:

• Disk kapasitesini ölçeklendirin.

• Kullanılmayan veya süresi dolmuş dizinleri temizleyin.

Küme sağlığını geri yüklemek için disk su seviyesini geçici olarak nasıl ayarlarım?

Düşük su seviyesini yalnızca acil durum önlemi olarak geçici şekilde yükseltin. Küme durumu disk su seviyesi sınırları nedeniyle sağlıksızsa, parçalar atanmamışsa ve hemen ölçeklendirme yapamıyorsanız bu yöntemi uygulayın. Kibana Dev Tools içinde küme ayarları API'sini çağırarak düşük su seviyesini örneğin %88'e yükseltin; böylece su seviyesi tarafından engellenen parçalar yeniden atanabilir.

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  },
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  }
}

%88 değeri mevcut küme için düşük su seviyesini yalnızca geçici olarak gevşetir. Temel neden bölümünde açıklanan %85, %90 ve %95 varsayılan su seviyelerini değiştirmez.

Bu geçici bir çözümdür. Küme durumu yeşile döndükten sonra konsol üzerinden yerinde ardışık değişiklik yoluyla yapılandırmayı yükseltin veya verileri mümkün olan en kısa sürede temizleyin. Yükseltilmiş su seviyesine uzun vadede güvenmeyin.

Bir dizini sildikten sonra disk alanının boşalması ne kadar sürer?

Hızlı çözüm (10–15 dakika) bölümünün ilk adımında açıklandığı şekilde bir dizini sildikten sonra disk alanı genellikle birkaç dakika ile yarım saat içinde boşalmaya başlar ve değişiklik kısa süre sonra izleme ölçümlerinde yansıtılır.

Disk alanı uzun süre boyunca hala boşalmadıysa kalan dizinler, anlık görüntüler veya günlükler gibi diğer verilerin diski tüketip tüketmediğini veya izleme ölçümlerinin yenilenmesinde gecikme olup olmadığını kontrol edin.

Önleme

Disk kullanımı izlemeyi etkinleştirin ve kullanım %80'i aştığında uyarıların tetiklenmesini sağlayacak şekilde yapılandırın. Uyarıları operasyon ekibinize yönlendirerek sel aşamasına ulaşmadan önce harekete geçmelerini sağlayın. Kurulum talimatları için bkz. İzleme ve uyarıyı yapılandırma.