【解決】 Elasticsearch: flood stage disk watermarked の解決方法と原因 | Elasticsearch トラブルシューティング

Elasticsearchをお使いの皆さん、システム運用中に「flood stage disk watermarked」というエラーメッセージに遭遇し、不安を感じているかもしれませんね。ご安心ください。このエラーは、ディスク容量の問題が原因で発生しますが、落ち着いて対処すれば必ず解決できます。このガイドでは、エラーの概要から、Windowsユーザーが今すぐ試せる最も速い解決策、そして将来的な再発防止策まで、具体的に解説します。

1. Elasticsearch: flood stage disk watermarked とは？（概要と緊急度）

「flood stage disk watermarked」は、Elasticsearchクラスターが稼働しているサーバーのディスク使用率が非常に高くなり、これ以上書き込みを受け付けられない状態になったことを示す緊急度の高いエラーです。Elasticsearchは、データ損失を防ぐためにディスクの空き容量を監視しており、特定のしきい値（ウォーターマーク）を超えると、新しいインデックスへの書き込みや、既存のインデックスへの新規データ追加をブロックします。

このエラーが発生すると、新たなデータがElasticsearchに取り込まれなくなるため、ログ収集システムや監視システムが機能しなくなる可能性があります。しかし、ディスク容量を解放すれば、この書き込みブロックは自動的に解除され、システムは正常な状態に戻ります。データの喪失ではないため、落ち着いて対処しましょう。

2. 【最速】今すぐ試すべき解決策

このエラーを最も速く解決する方法は、Elasticsearchが利用しているディスクの容量を即座に解放することです。特に、不要な古いインデックスを削除するのが最も効果的かつ安全な手段となります。

解決策1：不要な古いインデックスの削除

Elasticsearchでは、ログや時系列データを扱うことが多いため、過去の不要なデータがインデックスとして蓄積され、ディスク容量を圧迫しているケースがほとんどです。以下の手順で、Windows環境からPowerShellを使って不要なインデックスを削除し、ディスク容量を解放します。

手順1: 現在のインデックス一覧を確認する

まず、現在Elasticsearchに存在するインデックスの一覧とそのディスク使用量を確認しましょう。これにより、どのインデックスが容量を圧迫しているか、そしてどのインデックスが不要かを特定できます。

Invoke-RestMethod -Uri "http://localhost:9200/_cat/indices?v&s=store.size:desc" -Method Get | Format-Table

コマンドの説明:

  • http://localhost:9200: ElasticsearchのAPIエンドポイントです。必要に応じてIPアドレスやポート番号を調整してください。
  • _cat/indices?v&s=store.size:desc: インデックスの一覧を詳細表示（v）し、ディスク使用量（store.size）で降順ソート（desc）します。
  • Format-Table: 結果を見やすい表形式で表示します。

このコマンドを実行すると、インデックス名、シャード数、レプリカ数、ドキュメント数、そして最も重要なディスク使用量（store.size）などが表示されます。特に「store.size」列に注目し、容量の大きい古いインデックスを見つけましょう。例えば、日付付きのログインデックス（例: logstash-2023.01.01）などが対象となることが多いです。

手順2: 不要なインデックスを削除する

削除するインデックスを特定したら、以下のコマンドで削除を実行します。この操作は元に戻せませんので、削除するインデックス名が正しいことを十分に確認してください。

例えば、your_old_index_nameというインデックスを削除する場合：

Invoke-RestMethod -Uri "http://localhost:9200/your_old_index_name" -Method Delete

複数の古いインデックスをまとめて削除したい場合（例: 2023年のログインデックスを全て削除）:

PowerShellのループ機能を使って、特定のパターンに一致するインデックスを削除することも可能です。以下の例では、logstash-2023で始まる全てのインデックスを削除します。実行前に削除対象を確認するステップを含めています。

# 削除対象となるインデックスを事前に確認する
Write-Host "以下のインデックスが削除対象となります。よく確認してください。"
$indicesToDelete = (Invoke-RestMethod -Uri "http://localhost:9200/_cat/indices?h=index" -Method Get) | Where-Object { $_ -like "logstash-2023*" }
$indicesToDelete

# 削除を実行する前に確認を求める
Read-Host "上記のインデックスを削除しますか？ (y/n)" | ForEach-Object {
    if ($_ -eq 'y') {
        foreach ($index in $indicesToDelete) {
            Write-Host "Deleting index: $index"
            Invoke-RestMethod -Uri "http://localhost:9200/$index" -Method Delete
        }
        Write-Host "指定されたインデックスの削除が完了しました。"
    } else {
        Write-Host "削除はキャンセルされました。"
    }
}

インデックスを削除すると、Elasticsearchは自動的にディスク容量を再評価し、ディスク使用率がウォーターマーク以下になれば、書き込みブロックが解除され、正常にデータが書き込めるようになります。削除後、数分待ってからシステムの動作を確認してください。

3. Elasticsearch: flood stage disk watermarked が発生する主要な原因（複数）

このエラーが発生する主な原因は、以下の通りです。

  • ディスク容量の不足: Elasticsearchが稼働するサーバーのディスク容量が物理的に不足している、またはElasticsearchが利用可能な空き容量が少ない。
  • データ蓄積の増加: ログデータや時系列データなどが予想以上に速いペースで蓄積され、ディスク容量を急速に消費している。特にインデックスライフサイクル管理（ILM）が設定されていない場合に顕著です。
  • Elasticsearchのウォーターマーク設定: Elasticsearchには、ディスク使用率に応じて動作を制限する「ウォーターマーク」設定があります。
    • cluster.routing.allocation.disk.watermark.low: デフォルト75%。このしきい値を超えると、ノードへの新しいシャード割り当てが制限されます。
    • cluster.routing.allocation.disk.watermark.high: デフォルト85%。このしきい値を超えると、Elasticsearchはディスク使用率の高いノードからシャードを他のノードに移動させようとします。
    • cluster.routing.allocation.disk.watermark.flood_stage: デフォルト95%。このしきい値を超えると、ディスク使用率の高いインデックスへのすべての書き込みがブロックされます。今回発生したエラーはこのしきい値に関連しています。

    これらの設定値がデフォルトのままで、かつシステムに適切な容量がない場合にエラーが発生しやすくなります。

  • シャード数の増加とレプリカ設定: インデックスのシャード数やレプリカの数が多いと、同じデータが複数コピーされるため、ディスク使用量が増加します。

4. Elasticsearchで恒久的に再発を防ぐには

一時的な解決策だけでなく、長期的にこの問題の再発を防ぐための対策も重要です。

  1. ディスク容量の拡張

    最も根本的な解決策は、Elasticsearchが稼働するサーバーのディスク容量を増やすことです。物理ディスクの追加、クラウド環境であればインスタンスのストレージ容量アップグレードを検討しましょう。

  2. インデックスライフサイクル管理 (ILM) の導入

    Elasticsearch 6.8以降で利用可能なILMは、インデックスのライフサイクル（作成、ウォーム、コールド、削除）を自動的に管理する機能です。古いインデックスを自動的に削除するように設定することで、ディスク容量の過剰な消費を防ぐことができます。

    • 設定例: 「30日以上経過したインデックスは自動的に削除する」といったポリシーを設定します。

  3. シャードの最適化とレプリカ数の見直し

    インデックスのシャード数やレプリカ数は、ディスク使用量に直結します。

    • シャードサイズの見直し: シャードの適切なサイズは通常20GB～50GBとされています。大きすぎるシャードは管理が難しく、小さすぎるシャードはオーバーヘッドが増えます。
    • レプリカ数の見直し: 高可用性のためにレプリカは必要ですが、ディスク容量に余裕がない場合は、レプリカ数を減らすことも検討できます。ただし、可用性とのトレードオフになります。

  4. スナップショットとアーカイブ

    非常に古いデータや参照頻度の低いデータは、Elasticsearchクラスターから削除し、スナップショットとして別のストレージ（S3などのオブジェクトストレージやNAS）にアーカイブすることを検討しましょう。これにより、Elasticsearchクラスターのディスク容量を節約しつつ、必要に応じてデータを復元できるようになります。

  5. ディスクウォーターマーク設定の調整（慎重に）

    システムの特性やディスクの状況に合わせて、cluster.routing.allocation.disk.watermark.* の設定値を調整することも可能です。ただし、これは一時的な対処や特殊な環境向けであり、安易な変更はデータ損失のリスクを高める可能性があるため、非常に慎重に行う必要があります。基本的には、物理的なディスク容量を確保し、ILMでデータを適切に管理する方が推奨されます。

    例えば、flood_stage のしきい値を一時的に98%に引き上げる場合：

    Invoke-RestMethod -Uri "http://localhost:9200/_cluster/settings" -Method Put -ContentType "application/json" -Body '{ "persistent": { "cluster.routing.allocation.disk.watermark.flood_stage": "98%" } }'

    注意: この設定変更は、問題の根本解決にはならず、ディスクが満杯になるまでの時間を稼ぐだけです。設定変更後は、速やかに根本原因の解決（容量追加やILM設定など）を進めてください。

これらの対策を講じることで、「flood stage disk watermarked」エラーの発生を未然に防ぎ、安定したElasticsearch運用を実現できるでしょう。

Related Posts