【Prometheus】弱点を克服。Prometheusのデータを長期保管出来るようにする方法

Prometheusは、ローカルの時系列データベースに加えて、監視データの長期保存をサポートするために、リモートストレージの読み取りと書き込みを行うように構成できます。 

#リモート読み取り
構成すると、Prometheusストレージクエリ（HTTP APIなどを介して）がローカルストレージとリモートストレージの両方に送信され、結果がマージされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/614998/806dcfaa-6035-513e-fd64-2761ba41e565.png)

リモートストレージの際にも信頼性を維持するために、アラートと記録のルール評価ではローカルTSDBのみを使用することを忘れないようにしてください。

#リモート読み取りの構成
リモートストレージの読み取りパスは、Prometheus構成ファイルの```remote_read```セクションで構成します。

最も簡単なのは、リモートストレージの読み取りエンドポイントURLと認証方法を指定する方法です。 HTTP基本認証またはベアラートークン認証を使用できます。

```read_recent```フラグを使用することもできます。trueに設定すると、すべてのクエリがローカルストレージだけでなくリモートからも応答されます。 false（デフォルト）の場合、ローカルストレージから完全に応答できるクエリは、リモートエンドポイントに送信されません。

一連の```required_matchers```（ラベル、値のペア）を指定して、リモート読み取りをクエリの一部のサブセットに制限でき、たとえば以下のようなケースで メトリックのサブセットのみをリモートストレージに書き込めます。

より複雑な構成の場合、要求のタイムアウト、TLS構成、およびプロキシ設定のオプションもあり、それぞれに1つの```remote_read```セクションを持つことで、複数のリモートエンドポイントから読み取ることができます。

#リモート書き込み
構成すると、Prometheusはそのスクレイピングされたサンプルを1つ以上のリモートストアに転送できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/614998/76e75e56-6476-7c62-5759-9e5efd2880bb.png)

リモート書き込みは、ローカルストレージに書き込まれた時系列サンプルを「テーリング」し、リモートストレージへの書き込みのためにそれらをキューに入れることによって機能します。

キューは、実際には動的に管理される「シャード」のセットです。特定の時系列のすべてのサンプル（つまり、一意のメトリック）は、同じシャードに配置されます。

キューは、リモートストレージに書き込むシャードの数を自動的にスケールアップまたはスケールダウンして、着信データのレートに対応します。

これにより、Prometheusは、必要なリソースのみを使用して、最小限の構成でリモートストレージを管理できます。

#リモート書き込みの構成
リモートストレージの書き込みパスは、Prometheus構成ファイルの```remote_write```セクションで構成します。

```remote_read```の場合と同様に、最も単純な構成は、リモートストレージの書き込みURLと認証方法で、 HTTP基本認証またはベアラートークン認証を使用できます。

write_relabel_configsを使用して、リモートストレージに書き込むメトリックのラベルを変更したり制限したりでき、一般的な使用法は、メトリックの一部を削除することです。

queue_configセクションでは、上記の動的キューをある程度制御できます。通常、ここで変更を加える必要はなく、Prometheusのデフォルトを使用できます。

- ```capacity```：各シャードはそれ自体がキューであり、これはシャードがさらに追加を「ブロック」する前にキューに入れられたサンプルの数です。
- ```min_shards、max_shards```：動的キューが使用する最小および最大のシャード。
- ```max_samples_per_send```、```batch_send_deadline```：各シャードは、サンプルを```max_samples_per_send```のブロックにバッチ処理します。または、```batch_send_deadline```の前にそのサイズのバッチを作成できない場合は、とにかく送信します。この後者は、ビジー状態のPrometheusインスタンスではめったに発生しません。
- ```min_backoff```、```max_backoff、max_retries```：管理を再試行します。現在の実装では```max_retries```は使用されていないことに注意してください。各シャードはブロックし、送信を「永久に」再試行します。

remote_readと同様に、リクエストのタイムアウト、TLS構成、プロキシ設定のオプションも構成できます。

それぞれに1つの```remote_write```セクションを持つことで、複数のリモートエンドポイントに書き込むことができます。

#ログメッセージ
ログにリモートストレージサブシステムからのメッセージが表示される場合があります。

- ```dropped sample for series that was not explicitly dropped via relabelling```

ラベルの付け直しやその他の理由により、リモート書き込みパスにラベルのないシリーズになりました。 私たちはそれを落とします。

- ```Remote storage resharding from N to M```

動的キューのサイズにより、シャードの数が変化しています。受信サンプル数と送信リモートストレージの書き込み速度の数に対応するために増加するか、必要以上のシャードがあるために縮小しています。

- ```Currently resharding, skipping```

動的キューは新しい数のシャードに変更しようとしていますが、リシャードはすでに進行中です。

- ```Failed to flush all samples on shutdown```

動的キューをシャットダウンしているときに、Prometheusはすべてのサンプルをリモートストレージにフラッシュできませんでした。リモートストレージエンドポイントに問題があった可能性があります。

#メトリック
リモートストレージサブシステムは、```prometheus_remote_storage_```または```prometheus_wal_watcher_```というプレフィックスが付いた多数のメトリックをエクスポートします。以下に、興味深いと思われる選択肢を示します。

- ```prometheus_remote_storage_samples_in_total```：

リモートストレージへのサンプル入力。キューマネージャー（カウンター）のサンプル出力と比較します。

- ```prometheus_remote_storage_succeeded_samples_total```：

リモートストレージ（カウンター）に正常に送信されたサンプルの総数。

- ```prometheus_remote_storage_pending_samples```：

リモートストレージ（ゲージ）に送信される、キューのシャードで保留中のサンプルの数。

- ```prometheus_remote_storage_shards```：

リモートストレージ（ゲージ）への並列送信に使用されるシャードの数。

- ```prometheus_remote_storage_sent_batch_duration_seconds```：

リモートストレージへのサンプルバッチ送信呼び出しの期間（ヒストグラム）。