InfluxDB 2 の Timestream のモニタリングと設定の最適化

圧縮オペレーション (IOPS を大幅にスパイクできる)

スムーズに実行するためのデータベースの再起動

ピーク時のクエリバースト

バッチ取り込みからの書き込みスパイク

インデックスメンテナンスオペレーション

プロビジョンド IOPS: 12,000

ターゲット最大持続 IOPS (TotalIOpsPerSec): 8,400 (使用率 70%)

リザーブドヘッドルーム: 3,600 IOPS (30%)

ターゲット: IOPS 使用率 < 70% を維持する

警告: IOPS 使用率 > 70%

重大: IOPS 使用率 > 90%

InfluxDB 2.x アーキテクチャがインメモリインデックス作成を使用する

10Mシリーズを超えると、インデックス操作は過度に高価になります

メモリ要件が非線形に増加

クエリ計画のオーバーヘッドが大幅に増加

InfluxDB 3.0 は、高基数用に設計された列指向ストレージエンジンを使用します。

CPUUtilization > 70% 持続

QueryRequestsTotal (大量のクエリまたはスロークエリ)

ActiveTaskWorkers (タスク負荷が高い)

query-concurrency: vCPU 数の 50～75% に設定する

例: 8 vCPU インスタンス → query-concurrency = 4-6

influxql-max-select-series: 10000 (無制限クエリの防止)

influxql-max-select-point: 100000000

query-queue-size: 2048 (キューの蓄積を防止)

flux-log-enabled: TRUE (一時的にデバッグ用)

ログレベル: info (または詳細分析用のデバッグ)

より多くの vCPUs

最適化の機会のクエリパターンを確認する

MemoryUtilization > 70% 持続

HeapMemoryUsage が上昇傾向

スパイクを示す ActiveMemoryAllocation

SeriesCardinality (カーディナリティが高いとメモリ使用量が増加する)

storage-cache-max-memory-size: 合計 RAM の 10～15% に設定

例: 32GB RAM → 3,355,443,200～5,033,164,800 バイト

storage-cache-snapshot-memory-size: 26,214,400 (25 MB)

query-memory-bytes: 合計 RAM の 60～70% に設定

query-max-memory-bytes: query-memory-bytes と同じ

query-initial-memory-bytes: query-memory-bytes の 10%

storage-series-id-set-cache-size: カーディナリティが高い場合は減らす

ハイメモリ: 100～200

正常: 500-1000

QueryResponseVolume を確認して、過剰なデータを返すクエリを特定する

QueryRequestsTotal を使用して、最適化の恩恵を受ける可能性のある頻繁に実行されるクエリを検索する

時間範囲フィルターを追加して、ワークロードに必要なデータスキャンを減らす

アプリケーションレベルでクエリ結果キャッシュを実装する

ダウンサンプリングタスクを使用してデータを事前集約することを検討する

SeriesCardinality を確認し、データモデルを最適化して不要なタグを減らす

インスタンスサイズを増やして RAM を増やす

DiskUtilization > 70%

WriteThroughput パターン

TotalBuckets (多くのバケットでオーバーヘッドが増加する)

ログレベル: 「情報」 (「デバッグ」ではない) に設定されていることを確認します。

flux-log-enabled: アクティブにデバッグしない限り FALSE に設定します

storage-retention-check-interval: 15m0s (クリーンアップの頻度が高い)

storage-compact-full-write-cold-duration: 2h0m0s (より頻繁)

storage-cache-snapshot-write-cold-duration: 5m0s

storage-max-index-log-file-size: 524,288 (高速圧縮用に 512 KB)

log-level: debug は、1 時間あたり数百 MB の可能性のある非常に詳細なログを生成します。

flux-log-enabled: TRUE は、すべての Flux クエリ実行を完全な詳細でログに記録し、大量のログファイルを作成します。

これらのログは急速に蓄積され、キャパシティプランニング中に見落とされることがよくあります。

ログファイルは、特に小さなインスタンスでは、データインジェストよりも速くディスク容量を埋めることができます。

時系列データとは異なり、ログは削除前に 24 時間ローカルストレージに保持されます。

圧縮オペレーションが CPU サイクルを消費すると、CPUUtilization は増加します

MemoryUtilization は、データのロードと処理に伴って圧縮中に増加します

WriteOpsPerSec と WriteThroughput は圧縮ウィンドウ中に急増し、30% IOPS ヘッドルームを超える可能性があります

圧縮 I/O がアプリケーションの書き込みと競合すると、WriteTimeouts が増加する可能性があります

ストレージ容量を増やす (多くの場合、シンプルでコスト効率が高い)

データダウンサンプリングまたは集約戦略を実装する

バケットの統合 (TotalBuckets の削減) によるオーバーヘッドの削減

保持ポリシーをより厳密に確認して適用する

ストレージ容量を増やす

ReadOpsPerSec + WriteOpsPerSec = TotalIOpsPerSec

ReadThroughput と WriteThroughput

プロビジョニングされた IOPS (3K、12K、または 16K) と比較する

storage-max-concurrent-compactions: 2～3 (同時圧縮の制限)

storage-compact-throughput-burst: ディスク機能に基づいて調整する

3K IOPS: 25,165,824 (24 MB/秒)

12K IOPS: 50,331,648 (48 MB/秒)

storage-wal-max-concurrent-writes: 8～12

storage-wal-max-write-delay: 5m0s

storage-cache-snapshot-write-cold-duration: 15m0s (低頻度)

storage-compact-full-write-cold-duration: 6h0m0s (低頻度)

減らすと圧縮操作storage-max-concurrent-compactionsが遅くなり、TSM ファイルが蓄積され、DiskUtilization がより迅速に増加します。

を小さくすると圧縮時間がstorage-compact-throughput-burst長くなり、コンパクタのアクティブ時間が長くなり、他のオペレーションがブロックされる可能性があります。

圧縮が遅いということは、ストレージエンジンが統合された TSM ファイルではなく、より小さい TSM ファイルから読み取る必要があるため、クエリのパフォーマンスが時間の経過とともに低下することを意味します。

I/O の待機中にクエリがタイムアウトすると、QueryRequestsTotal runtime_error レートが増加することがあります。

storage-cache-snapshot-write-cold-duration と を増やすstorage-compact-full-write-cold-durationと、データは先行書き込みログ (WAL) に長く保持されます。

これにより、ディスクにフラッシュされる前にキャッシュに保持されるデータが増えるため、MemoryUtilization が向上します。

キャッシュされたデータが保持される前にインスタンスがクラッシュすると、データ損失のリスクがわずかに増加します。

より多くの WAL データを再生する必要があるため、再起動後の復旧時間が長くなる

削減storage-wal-max-concurrent-writesすると書き込みオペレーションがシリアル化され、高スループット期間中に WriteTimeoutsが増加する可能性があります。

増加storage-wal-max-write-delayは、書き込みが拒否されるまでに時間がかかることを意味します。これにより、容量の問題はマスクされますが、応答が遅いユーザーを苛立たせる可能性があります。

より高い IOPS ストレージ階層へのアップグレード (3K → 12K)

30% IOPS ヘッドルームが維持されていることを確認する

バケットあたりの SeriesCardinality と合計

MemoryUtilization (基数の増加)

CPUUtilization (クエリ計画オーバーヘッド)

QueryRequestsTotal (runtime_error レートが増加する可能性があります)

storage-series-id-set-cache-size: 1000-2000 (キャッシュを増やす)

storage-series-file-max-concurrent-snapshot-compactions: 4～8

influxql-max-select-series: 10000 (ランナウェイクエリの防止)

influxql-max-select-buckets: 1000

storage-max-index-log-file-size: 2,097,152 (2MB)

多くのホスト/サービスに集約されるダッシュボードのモニタリング

複数のエンティティを比較する必要がある分析クエリ

フリート全体の条件を評価するアラートクエリ

クエリ計画が過度に高価になる (CPUUtilization が高い)

メモリ要件が非線形に増加する (MemoryUtilization が高い)

インデックスオペレーションが I/O を支配する (ReadOpsPerSec、WriteOpsPerSec)

QueryRequestsTotal runtime_error レートが増加する

タグ設計を確認して不要な基数を減らす

類似シリーズの統合を検討する

> 10M シリーズの場合: InfluxDB 3.0 への移行を計画する

QueryRequestsTotal 結果タイプ別 (成功、runtime_error、 compile_error、queue_error)

Status=500 または Status=499 の APIRequestRate

QueryResponseVolume (大きなレスポンスは高価なクエリを示す)

クエリ同時実行数: vCPUs の 75% に増加

query-memory-bytes: 合計 RAM の 70% を割り当てる

query-queue-size: 4096

storage-series-id-set-cache-size: 1000 (キャッシュを改善するために増加)

http-read-timeout: 60 秒 (早期タイムアウトの防止)

influxql-max-select-point: 100000000

influxql-max-select-series: 10000

influxql-max-select-buckets: 1000

CPUUtilization が増加し、ピーククエリ期間中に飽和に達する可能性があります

MemoryUtilization は、より多くのクエリがメモリを同時に割り当てると増加します

適切なリソースなしで同時実行数を増やすと、キューイングではなくすべてのクエリが遅くなります。

同時クエリで使用可能なリソースが枯渇した場合のカスケード失敗のリスク

HeapMemoryUsage が増加

storage-cache-max-memory-size 補償のために減らす必要がある場合があります

キャッシュヒットが少ないほど、ReadOpsPerSec が高くなり、クエリのパフォーマンスが遅くなります。

クエリが全割り当てを使用する場合、システムはメモリ枯渇に対してより脆弱になる

クエリがキューで待機時間が長くなり、end-to-endレイテンシーが増加する

スループットが変わらない場合でも、ユーザーはシステムを遅く認識する

キューが大きいと、基盤となる容量の問題をマスクできる

QueryRequestsTotal queue_error レートは低下しますが、ユーザーエクスペリエンスは向上しない可能性があります

長時間実行されるクエリはリソースをより長く消費し、他のクエリの容量を削減します。

ユーザーがタイムアウトエラーを受信するまで待機時間が長くなる

最適化する必要がある非効率的なクエリを非表示にできる

多くのスロークエリが蓄積されると、リソースが枯渇する可能性があります

コンピューティング容量をスケールし、クエリは追加の処理能力 (vCPUsの恩恵を受ける

正確なタグ値のフィルタリング - のような RegEx パターンの代わりに等価演算子 (==) または contains()関数を使用します。 /^exact_value$/

複数の特定の値の一致 - のような変更パターンではなく、値の配列で in演算子を使用します。 /(value1|value2|value3)/

単純なプレフィックスまたはサフィックスマッチング - RegEx アンカーよりも効率的な strings.hasPrefix()関数または strings.hasSuffix()関数の使用を検討してください。

WriteTimeouts (カウントの増加)

WriteOpsPerSec と WriteThroughput

書き込みエンドポイントのステータスが 500 の APIRequestRate

書き込み中の result=runtime_error を含む QueryRequestsTotal

storage-wal-max-concurrent-writes: 12-16

storage-wal-max-write-delay: 10m0s

http-write-timeout: 60 秒

storage-cache-snapshot-memory-size: 52,428,800 (50 MB)

storage-cache-snapshot-write-cold-duration: 10m0s

storage-no-validate-field-size: TRUE (データソースが信頼されている場合)

CPUUtilizationは、より多くの書き込みスレッドが CPU と競合するにつれて増加します。

MemoryUtilization は、WAL フラッシュの前にメモリにバッファされるデータが増えるにつれて増加します

WriteOpsPerSec が急増し、30% IOPS ヘッドルームを超える可能性があります

ディスク I/O の競合が増加すると、実際には個々の書き込みが遅くなる可能性があります

ディスク I/O 容量を超えると、WriteTimeouts が減少するのではなく増加する可能性があります。

書き込みをすぐに失敗させるのではなく待機させることで、容量の問題をマスクします

書き込みが最終的に成功しても、ユーザーの書き込み応答時間が遅くなる

書き込みキューの蓄積とメモリ負荷につながる可能性がある

実際に容量を増やさない - タイムアウトを遅らせるだけ

より大きなバッチ書き込みの完了を許可する

ただし、書き込みが遅いとリソースをより長く消費できます。

基盤となるパフォーマンス問題を非表示にできる

多くのスロー書き込みが蓄積されると、リソースが枯渇する可能性があります

MemoryUtilization が大幅に増加

スナップショットの前にインスタンスがクラッシュすると、データ損失のリスクが増加する

スナップショットが大きいほど書き込みに時間がかかり、WriteOpsPerSec のスパイクが大きくなります

より多くのデータをバッチ処理することで書き込みスループットを向上させることができますが、メモリと信頼性のコストがかかります

データがキャッシュに保持される時間が長くなると、MemoryUtilization がさらに増加します

データ損失リスクウィンドウを増やす

WriteOpsPerSec の頻度を減らしますが、スナップショットが発生するとスパイクが大きくなります

より多くの WAL を再生する必要があるため、再起動後の復旧時間が長くなる

検証チェックをスキップして書き込みスループットを改善

重大なリスク: 不正な形式または悪意のあるデータの書き込みを許可する

書き込みに無効なフィールドサイズが含まれていると、データの破損につながる可能性があります

データ問題のデバッグをはるかに困難にする

データソースを完全に制御し、信頼している場合にのみ使用します。

より高い IOPS ストレージへのアップグレード (3K → 12K → 16K)

I/O ヘッドルームが適切であることを確認する

CPU またはメモリに制約がある場合は、より大きなインスタンスクラスにスケールする

しきい値: > 90%、5 分間

アクション: トラフィック修復対策またはコンピューティングスケーリングを実装する

しきい値: > 90%、5 分間

アクション: トラフィック修復対策またはコンピューティングスケーリングを実装する

しきい値: > 85%

アクション: 古いバケットの削除、保持設定の更新、または Storage Scaling によるスペースの解放を試みる

しきい値: 10 分間にプロビジョニングされた の > 90%

アクション: トラフィック修復対策を実装する、または IOPS を増やす

しきい値: > 10,000,000

アクション: データモデルを確認し、変更できない場合は、InfluxDB 3 への移行またはデータのシャードを検討してください。

しきい値: 予期しないリセット (< 300 秒)

アクション: Timestream サポートへのチケットを作成しない場合は、メンテナンスウィンドウと一致するかどうかを確認します。

しきい値: > 70%、15 分間

アクション: ワークロードまたはトラフィックの変更を確認する

しきい値: > 70%、15 分間

アクション: ワークロードまたはトラフィックの変更を確認する

しきい値: > 70%

アクション: 保持ポリシーを確認する

しきい値: 15 分間にプロビジョニングされた の > 70%

アクション: ワークロードまたはトラフィックの変更を確認する

しきい値: 合計クエリの > 1%

アクション: ワークロードまたはトラフィックの変更を確認する

しきい値: 書き込みオペレーションの > 1%

アクション: ワークロードまたはトラフィックの変更を確認する

しきい値: > 5,000,000

アクション: データモデルの最適化を確認する

APIRequestRate でエラースパイク (400、404、499、500) を確認する

runtime_error および queue_error レートの QueryRequestsTotal を確認する

WriteTimeouts カウントが最小限であることを確認する

重要なアラームがないか確認する

EngineUptime を検証する (予期しない再起動なし)

CPUUtilization、MemoryUtilization、および DiskUtilization の傾向を確認する

QueryRequestsTotal パターンを結果タイプ別に分析する

バケットあたりの SeriesCardinality 増加率を確認する

TotalIOpsPerSec 使用率の傾向を確認する

設定パラメータが最適であることを確認する

TaskExecutionFailures パターンを確認する

キャパシティプランニングレビュー (3～6 か月前にプロジェクト)

現在のメトリクスをサイジングテーブルと比較する

保持ポリシーの確認と最適化

APIRequestRate と QueryResponseVolume からクエリパターンを分析する

SeriesCardinality とデータモデルの効率を確認する

インスタンスのスケーリングまたは設定変更の必要性を評価する

TotalBuckets と統合の機会を確認する

AWS マネジメントコンソールの設定パラメータの変更

アプリケーションのデプロイの変更

クエリパターンの変更

データモデルの変更

インフラストラクチャの変更 (インスタンスタイプ、ストレージ)

CPU スパイク? → CPUUtilization、QueryRequestsTotal を確認する

メモリプレッシャー? → MemoryUtilization、HeapMemoryUsage、ActiveMemoryAllocation を確認する

IOPS 飽和度 → TotalIOpsPerSec、ReadOpsPerSec、WriteOpsPerSec を確認する

シリーズ基数ジャンプ? → SeriesCardinality の増加を確認する

エラー率の増加 → QueryRequestsTotal (runtime_error)、APIRequestRate (Status=500) を確認する

予期しない再起動ですか? → EngineUptime を確認する

ログレベル: デバッグ

flux-log-enabled: TRUE

検出結果に基づいて適切な設定変更を適用する

制限に達した場合のリソースのスケーリング

必要に応じてクエリまたはデータモデルを最適化する

突然負荷が増加する場合はレート制限を実装する

MemoryUtilization > 90%

HeapMemoryUsage が最大値に近づいています

runtime_error (メモリ不足) を示す QueryRequestsTotal

Status=500 を示す APIRequestRate

storage-cache-max-memory-size: RAM を 10% に減らす

例: 32GB → 3,355,443,200 バイト

storage-cache-snapshot-memory-size: 26,214,400 (25 MB)

query-memory-bytes: 合計 RAM の 60% に設定

query-max-memory-bytes: query-memory-bytes の一致

query-initial-memory-bytes: query-memory-bytes の 10%

influxql-max-select-series: 10000

influxql-max-select-point: 100000000

クエリ同時実行数: vCPUs

データモデルを最適化して SeriesCardinality を減らす

アプリケーションレベルでクエリ結果のサイズ制限を実装する

クエリタイムアウトの適用を追加する

最も一般的なクエリを確認して、 セクションで説明されているベストプラクティスに従っていることを確認します。 クエリパフォーマンスの問題

SeriesCardinality > 5M

MemoryUtilization 高

runtime_error の増加を示す QueryRequestsTotal

クエリ計画のオーバーヘッドによる CPUUtilizationの向上

SeriesCardinality 成長率 (毎日/毎週)

10Mのしきい値への射影

高基数の原因を特定する

タグの設計と使用を確認する

QueryRequestsTotal成功率

MemoryUtilization の相関を確認する

CPUUtilization パターンを確認する

QueryResponseVolume の傾向を分析する

SeriesCardinality が最も高いバケットはどれですか?

一意の値数が多いタグはどれですか?

不要なタグはありますか?

タグ値は無制限ですか (UUIDs、タイムスタンプなど)?

storage-series-id-set-cache-size: 現在の値?

influxql-max-select-series: ランナウェイクエリを制限していますか?

storage-max-index-log-file-size: 基数に適していますか?

storage-series-id-set-cache-size: 1500-2000

storage-series-file-max-concurrent-snapshot-compactions: 6～8

storage-max-index-log-file-size: 2,097,152 (2MB)

influxql-max-select-series: 10000

influxql-max-select-buckets: 1000

query-concurrency: メモリが制約されている場合は減らす

次のインスタンス階層にスケールする

メモリ割り当てを増やす

12K IOPS ストレージ層を検討する

InfluxDB 3.0 は優れた高カーディナリティパフォーマンスを提供します

移行タイムラインを計画する (2～3 か月)

最初にデータのサブセットを使用してテストする

移行用のアプリケーションを準備する

InfluxDB 3.0 は、数十億のシリーズに最適化された列指向ストレージを使用します。

result=queue_error の増加を伴う QueryRequestsTotal (クエリは拒否されます)

Status=429 または Status=503 の APIRequestRate (サービスが利用できない/リクエストが多すぎる)

CPUUtilization が上昇する (> 70%) 可能性があり、リソースの飽和を示す

MemoryUtilization が高い (> 70%) クエリ容量を制限する可能性があります

大きなレスポンスサイズを示す QueryResponseVolume (クエリに過剰なリソースがかかる)

QueryRequestsTotal内訳を確認します。

APIRequestRate パターンをモニタリングします。

高キュー期間中の CPUUtilization:

MemoryUtilization の相関関係:

TotalIOpsPerSec パターン:

QueryResponseVolume を確認します。

QueryRequestsTotal レートを分析する:

エンドポイント別に APIRequestRate を確認します。

現在のメトリクスをサイジングテーブルのレコメンデーションと比較します。

IOPS 容量を確認します。

query-queue-size: 4096 (デフォルト 1024 から)

クエリ同時実行数: vCPUs の 75% に増加

例: 16 vCPU → query-concurrency = 12

CPUUtilization が変更後も < 80% のままであることを確認する

MemoryUtilization が変更後も < 80% のままであることを確認する

query-memory-bytes: 適切な割り当てを確保する

storage-series-id-set-cache-size: 1000-1500

http-read-timeout: 120s (早期タイムアウトの防止)

influxql-max-select-series: 10000

influxql-max-select-point: 100000000

クエリ結果キャッシュを実装する (Redis、Memcached)

連続クエリを使用して一般的なパターンを事前集計する

大きな結果セットのページ分割を追加する

ユーザー/ダッシュボードごとにクエリレート制限を実装する

履歴クエリにダウンサンプリングされたデータを使用する

CPUUtilization > 70% が持続する場合: より大きなインスタンスにスケールする

MemoryUtilization > 70% が持続している場合: メモリ最適化インスタンスにスケールする

クエリレートがインスタンス容量を超える場合: サイジングテーブルごとに次の階層にスケールする