有効にしなければログは永遠に残る

一言でいうと

Lokiは保持をオフにしたまま出発します。オンにしなければ、入れたログは永遠に残り、オンにしても、削除はコンパクターが自分の周期で行う非同期の作業なので、「消した」と「見えない」の間に時間差があります。

なぜ必要なのか

ストレージの請求書が3か月で4倍になったチームがありました。ダッシュボードで古い区間を開くと、1年前のログまで出てきました。誰も保持を設定しておらず、誰もその事実を知りませんでした。デフォルトが「削除しない」だからです。

逆方向の事故もあります。個人情報が混ざっているのを発見して削除リクエストを出したチームが、リクエストの直後にその行が参照から消えるのを見て、「消した」と報告しました。1か月後、ストレージ容量はそのままでした。デフォルトの削除方式(filter-and-delete)は、リクエストが受理されるとすぐにクエリ時点でふるい落としてくれますが、オブジェクトから実際に消す作業は、キャンセル猶予期間(デフォルト24時間)が過ぎたあと、コンパクターが行います。見えないことと、消えたことは違います。

どう動くのか

保持はコンパクターが行います。3つを一緒に見る必要があります。

設定	デフォルト値	意味
compactor.retention_enabled	false	オフなら何も削除しません
compactor.compaction_interval	10m	圧縮と保持を回す周期
compactor.retention_delete_delay	2h	削除対象としてマークしてから、実際に削除するまで待つ時間

保持期間そのものはlimits_config.retention_periodで決め、ストリームごとに別の値をかけたければ、retention_streamのリストにセレクター・優先度・期間を書きます。複数のルールが重なったときは、優先度が高いものが勝ちます。監査ログは1年、デバッグログは1日。同じクラスターでこのように分けておくことが、コストを減らす最大のつまみです。

特定の行を消す作業は、保持とは別の道です。POST /loki/api/v1/deleteにセレクターと区間を渡すと、削除リクエストが受理され、状態がreceivedになります。デフォルトのdeletion_modeであるfilter-and-deleteでは、その瞬間からクエリが該当する行をふるい落とすので、参照はすぐに空に見えます。しかし、リクエストはdelete_request_cancel_period(デフォルト24時間)の間はキャンセルでき、保存されたオブジェクトから実際に消えるのは、その時間が過ぎたあとの、コンパクターの仕事です。

ここでよくずれるのが、期待と保証です。「参照から消えた」は表示であって、「消えた」という証拠ではありません。規制対応で期限があるなら、その期限とキャンセル猶予期間・コンパクターの周期を一緒に計算する必要があり、容量が減るのを待っているなら、なおさらです。

容量計画は、むしろ単純です。クエリのレスポンスに載ってくるtotalBytesProcessedで、1時間分の実際のバイト数を測り、1日・1か月に掛け、ストリームごとの保持期間を掛けて足します。圧縮率は、実際に保存されたチャンクファイルのサイズと比べて補正します。推定ではなく実測から出発すれば、保持期間を減らそうという議論が、数字で進みます。

現場での姿

最もよく見る失敗は、保持をオンにしてコンパクターを起動しないことです。マイクロサービス構成では、コンパクターは別の構成要素で、クラスターにちょうど1つだけ起動している必要があります。設定にretention_enabled: trueと書いておいて、コンパクターがなければ何も起きませんが、設定ファイルだけを見ると、オンになっているように見えます。

2つ目は、ストリームルールの優先度を書き忘れることです。優先度が同じ2つのルールが同じストリームにかかると、どちらが勝つか予測しにくくなります。ルールを入れるたびに、優先度を明示する習慣が安全です。

3つ目は、「消したのに容量が減らない」です。削除マークと実際のオブジェクト削除の間には待ち時間があり、オブジェクトストレージ側のライフサイクルポリシーが、さらに1層ある場合もあります。

次のラボですること

保持をオンにして、ストリームごとに異なる期間をかける設定ファイルを自分で書き、loki -verify-configで、文法ではなく設定自体が有効かを確認します。その設定で2つ目のLokiを別のポートで起動し(gRPCポートまで変える必要があります)、サーバーが実際にその値を持って起動したかを/configで確認したあと、削除リクエストを出して、受理されることと、すぐには消えないことを一緒に記録します。最後に、実測のバイト数から保持の予算を計算して、ポリシー文書を作ります。