翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon MSK プロビジョニング済みクラスターに推奨される CloudWatch アラーム
Amazon MSK プロビジョンドクラスターをモニタリングして、アプリケーションに影響を与える前に問題を検出します。CloudWatch アラームは、CloudWatch メトリクスがある程度の時間にわたって指定された値を超えたときにアクションを実行します。たとえば、パーティション数がブローカーインスタンスサイズの推奨値を 15 分以上超えた場合に、E メール通知を受け取ることができます。次の表に示す重要なアラームは推奨されますが、クラスターをモニタリングするために作成できるアラームの完全なリストではありません。
アラームの設定の詳細については、[Amazon CloudWatch ユーザーガイド」の「Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)」を参照してください。 *Amazon CloudWatch *
次の表に、Standard ブローカーと Express ブローカーの両方に適用されるアラームを示します。
| アラーム | 問題 |
| --- | --- |
| `CPUUser` \+ `CPUSystem` 平均 >= 5 分間 60、連続 3 回
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーの平均 CPUUser\+CPUSystem が推奨 60% を超えています。詳細については[CPU 使用率をモニタリングする](bestpractices.md#bestpractices-monitor-cpu)を参照してください。 |
| `PartitionCount` 平均 >= **5 分間 X、3 回連続 (*X* = ブローカーインスタンスサイズの推奨パーティション数)
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーのパーティション数が推奨パーティション数制限を超えています。詳細については、「[クラスターの適切なサイズ設定: 標準ブローカーあたりのパーティション数](bestpractices.md#partitions-per-broker)」および「[Express ブローカーパーティションクォータ](limits.md#msk-express-broker-partition-quota)」を参照してください。 |
| `SumOffsetLag` 平均 >= *X* 5 分間、3 回連続 (*X* はユースケースに基づいてコンシューマーグループとトピックの組み合わせに設定されます)
ディメンション: `Cluster Name`、`Consumer Group`、`Topic` | トピック内のすべてのパーティションの集計オフセット遅延は *X* を超えています。 遅延の詳細については、各パーティションの遅延を表すパーティションレベルの`Offset`メトリクスを使用するか、Kafka コマンドラインツールを使用してコンシューマーグループを記述できます。プロデューサーに対するコンシューマーアプリケーションの処理速度を確認して、コンシューマーが追いつくことができないかどうかを確認し、コンシューマーの再調整によってコンシューマーが遅くなっているかどうかを確認します。 |
次の表に、標準ブローカーのみに適用されるアラームを示します。
| アラーム | 問題 |
| --- | --- |
| `OfflinePartitionsCount` 平均 >= 1 を 1 分間、連続 3 回
ディメンション: `Cluster Name` | 1 つ以上のトピックパーティションが使用できません。パーティションが使用できない場合、それらのパーティションに対する生成および消費オペレーションは失敗します。オフラインパーティションは、バランスが取れ、サイズが正しく、正しく設定されたクラスターでは発生しません。詳細については[高可用性クラスターの構築](bestpractices.md#ensure-high-availability)を参照してください。 |
| `UnderMinIsrPartitionCount` 平均 >= 1 を 1 分間、連続 3 回
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のトピックに、最小設定の同期内レプリカセット (ISR) 未満のパーティションがあります。パーティションが最小 ISR を下回ると、プロデューサーオペレーションは失敗します (プロデューサー を使用`acks=all`)。詳細については[高可用性クラスターの構築](bestpractices.md#ensure-high-availability)を参照してください。 |
| `KafkaDataLogsDiskUsed` 平均 >= 5 分間 80、連続 3 回
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーのデータディスク使用量が 80% 以上である。詳細については[ディスク容量のモニタリング](bestpractices.md#bestpractices-monitor-disk-space)を参照してください。 |
| `HeapMemoryAfterGC` 平均 >= 5 分間 60、連続 3 回
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーで、ガベージコレクション後に使用中の合計ヒープメモリの 60% 以上が使用されています。詳細については[Apache Kafka メモリのモニタリング](bestpractices.md#bestpractices-monitor-memory)を参照してください。 |
| (Sum(`VolumeReadBytes`) \+ Sum(`VolumeWriteBytes`)) / (5 \* 60 \* 1024 \* 1024) >= *X* MiB を 5 分間、3 回連続 (*X* = 使用可能なボリュームスループットの 80%)
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーには、使用可能なボリュームスループットの最大 80% を使用する基盤となるボリュームの読み取りおよび書き込みアクティビティがあります。詳細については、[「プロビジョンドストレージスループット](https://docs.aws.amazon.com/msk/latest/developerguide/msk-provision-throughput-management.html)」を参照してください。 |
| `CPUCreditBalance` 平均 <= 100 を 5 分間、連続 3 回
ディメンション: `Cluster Name`、`Broker ID` | これは t3.small ブローカータイプにのみ関連します。1 つ以上のブローカーが CPU クレジット残高を最大 576 から 100 未満まで枯渇させました。残高が 0 に達すると、ブローカーは 20% の CPU ベースラインを超えることはできません。CPU クレジットの枯渇を回避するには、t3 ブローカーインスタンスタイプから CPU クレジットを使用しない m7g インスタンスタイプにアップグレードします。 |
| `RequestHandlerAvgIdlePercent` 平均 <= 0.3 5 分間、3 回連続
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーで、リクエストを処理するスレッドプールでアクティビティの輻輳が発生しています (スレッドプールのアイドル状態が 30% 未満）。ここで飽和状態はリクエストが遅いことを示し、クライアント側のタイムアウトが発生する可能性があります。また、クライアントが過剰なリクエストを生成しているかどうかを確認します。たとえば、不正なクライアントは、ブローカーが拒否するリクエストを積極的に再試行している可能性があります。クラスタースループットの最適化の詳細については、「」を参照してください[m5.4xl、m7g.4xl、またはそれ以上のインスタンスでクラスタースループットを最適化する](bestpractices.md#optimize-broker-threads)。 |
| `NetworkProcessorAvgIdlePercent` 平均 <= 0.3 5 分間、3 回連続
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーで、ネットワーク接続スレッドプールでアクティビティの輻輳が発生しています (スレッドプールのアイドル状態が 30% 未満）。ここで飽和すると、タイムアウトが発生する可能性があります。また、クライアントが過剰なリクエストを生成しているかどうかを確認します。たとえば、不正なクライアントは、ブローカーが拒否するリクエストを積極的に再試行している可能性があります。クラスタースループットの最適化の詳細については、「」を参照してください[m5.4xl、m7g.4xl、またはそれ以上のインスタンスでクラスタースループットを最適化する](bestpractices.md#optimize-broker-threads)。 |
| `KafkaFileDescriptorsUsagePercent` > 80%、5 分間、3 回連続
ディメンション: `Cluster Name`、`Broker ID` | ブローカーで使用されているファイル記述子の割合。100% 枯渇すると、Kafka ブローカーは起動できない可能性があります。ファイル記述子の数は、パーティションの数、各パーティションのログセグメントの数、クライアント接続の数に応じて増加します。低`segment.ms`値で頻繁にログロールが発生するトピックがあるかどうかを確認し、クライアント接続の数を減らすことを検討してください。 |
| `KafkaMemoryMappedFilesUsagePercent` > 80%、5 分間、3 回連続
ディメンション: `Cluster Name`、`Broker ID` | ブローカーで使用されているメモリマップファイルの割合。100% 枯渇すると、Kafka ブローカーは起動できない可能性があります。メモリマップファイルの使用数は、パーティションの数と各パーティションのログセグメントの数に応じて増加します。`segment.ms` 値が小さいトピックがあり、頻繁にログがロールされるかどうかを確認します。 |
## IAM アクセスコントロールアラーム
上記のアラームに加えて、IAM アクセスコントロールに固有の以下のメトリクスのアラームを作成することをお勧めします。これらのアラームは、IAM 認証が有効になっている Standard ブローカーと Express ブローカーの両方に適用されます。Amazon MSK は、IAM 接続リクエストの過負荷からブローカーを保護するために、IAM 接続に論理的な制限を設けます。これらの制限のいずれかに違反すると、クライアント接続のタイムアウトが発生し、ワークロードに影響します。
| アラーム | 問題 |
| --- | --- |
| `ClientConnectionCount` 合計 >= *X* を 1 分間、3 回連続 (*X* = ブローカーあたりの最大 TCP 接続数の 80%)
ディメンション: `Cluster Name`、`Broker ID`、`Client Authentication` | 1 つ以上のブローカーの接続数が接続制限の 80% に等しい。IAM アクセスコントロールのブローカーあたりのデフォルトの最大 TCP 接続数は 3000 です。この値は変更できます。詳細については、Express ブローカー[Amazon MSK Express ブローカークォータ](limits.md#msk-express-quota)の場合は「」、Standard ブローカー[Amazon MSK 標準 ブローカークォータ](limits.md#msk-provisioned-quota)の場合は「」を参照してください。 |
| `ConnectionCreationRate` 合計 >= *X* を 1 分間、3 回連続 (*X* = インスタンスサイズの接続作成レート制限の 80%)
ディメンション: `Cluster Name`、`Broker ID` | 1 つ以上のブローカーには、接続作成レート制限の 80% に相当するレートで IAM 接続を作成するクライアントがあります。IAM アクセスコントロールのブローカーあたりの最大 TCP 接続レートは、インスタンスサイズによって異なります。詳細については、Express ブローカー[Amazon MSK Express ブローカークォータ](limits.md#msk-express-quota)の場合は「」、Standard ブローカー[Amazon MSK 標準 ブローカークォータ](limits.md#msk-provisioned-quota)の場合は「」を参照してください。 |