AliyunAMQPReadOnlyAccess によるクエリ
AliyunAMQPReadOnlyAccess ポリシーは、amqp:Get* および amqp:List* の権限のみを付与します。キュー内のメッセージにアクセスするには、amqp:BasicGet カスタム権限を追加する必要があります。詳細については、「ApsaraMQ for RabbitMQ カスタムポリシーリファレンス」をご参照ください。
{
"Version": "1",
"Statement": [
{
"Action": [
"amqp:BasicGet"
],
"Resource": [
"acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
],
"Effect": "Allow"
}
]
}キューのパージ後のメッセージの蓄積
パージ操作は、キュー内の準備完了メッセージをクリアしますが、デフォルトでは遅延メッセージは対象外です。
QoS メカニズム
タイムアウトやブロッキングが発生した場合は、QoS またはプリフェッチカウントを 1 に設定してください。これにより、クライアントが同時に期限切れになる可能性のあるメッセージをキャッシュしすぎるのを防ぎます。
デッドレターキューのメッセージ配信
TTL 値のないメッセージは、否定応答 (NACK) された場合、またはリトライ回数が上限に達した場合にのみ、デッドレターキューに送信されます。
メッセージ ID の設定
詳細については、「メッセージ ID の設定方法」をご参照ください。
デッドレターキュー内のメッセージ数の減少
ApsaraMQ for RabbitMQ はメッセージを最大 3 日間保持します。メッセージが 3 日以内に消費されない場合、デッドレターキューから自動的に削除され、メッセージ数が減少します。詳細については、「制限事項」をご参照ください。
メッセージ保持期間
ApsaraMQ for RabbitMQ は、消費されたかどうかに関わらず、すべてのメッセージを最大 3 日間保持します。詳細については、「制限事項」をご参照ください。
RabbitMQ のネットワークセグメント
ApsaraMQ for RabbitMQ インスタンスのネットワークセグメントは固定されていないため、この情報を事前に取得することはできません。
キューの自動削除に関する問題
コンシューマーがキューに正常にサブスクライブしていない場合、channel.close を呼び出してもキューの自動削除はトリガーされません。自動削除ロジックは、コンシューマーが channel.basicConsume を使用して正常にサブスクライブした後にのみ有効になります。
ストレージ料金
ApsaraMQ for RabbitMQ はメッセージを 3 日間保持します。ストレージ料金はメッセージ本文のストレージ量に基づいて計算されます。このストレージ領域は手動でクリアすることはできず、メッセージの有効期限が切れたときにのみ解放されます。
パージ操作はメッセージをコンシューマーから受信できなくしますが、物理的に即時削除するわけではないため、ストレージ使用量はすぐには減少しません。
キューのパージ
キューをパージすると、キュー内のすべての準備完了メッセージがクリアされ、コンシューマーはそれらのメッセージを受信できなくなります。この操作は、コンシューマーがメッセージをスキップするように動作しますが、メッセージデータ自体を即時に削除するものではありません。
キューの下りレートを決定する要因
キューのメッセージ配信レートは、メッセージ量、コンシューマーの数、およびそれらの QoS 設定によって決まります。
排他キューの考慮事項
Spring フレームワークを CONNECTION モードで使用する場合、事前にコンソールでエクスチェンジ、キュー、バインディングを作成する必要があります。CONNECTION モードでは、これらのリソースは自動的に宣言または作成されません。
メッセージリトライの課金
課金は初回配信に対して一度だけ行われます。その後の再キューイングや消費の試行では追加料金は発生しません。
再キューイングは、コンシューマーがメッセージの処理に失敗し、メッセージがサーバーキューに返されたときに発生します。サーバーは専用のリトライキューを使用して、特定の時間間隔でメッセージをコンシューマーに再配信します。
TPS 制限のメトリック
TPS 制限は、Cloud Monitor の「インスタンスあたりのピーク API リクエストレート」メトリックに対応します。
接続制限の超過
接続制限はインスタンスレベルの制限として文書化されていますが、バックエンドノードレベルで適用されます。その結果、インスタンスの総接続数は、記載されている制限をわずかに超えることがあります。
サブスクリプションインスタンスの設定は動的に調整できません。リソース制限を超えてビジネスの中断を引き起こすのを避けるために、インスタンスを作成する際にはリソースを慎重に計画することを推奨します。
生成レートと消費レートが均衡している場合のメッセージの蓄積
生成レートと消費レートが均衡していても、一部のメッセージの確認応答 (ACK) が遅れると、モニタリングツールは特定のサンプリング時点で一時的なメッセージの蓄積を報告することがあります。蓄積レベルは通常、次のサンプリングサイクルで通常の状態に戻ります。
Pod の消費レートの急激な低下
Pod のパフォーマンスを確認することを推奨します。CPU 使用率が高いと、クライアントが ACK を迅速に送信できなくなる可能性があります。サーバーが ACK を受信しない場合、新しいメッセージをプッシュできず、タイムアウトを待ってからリトライします。これにより、消費レートが低下します。
たとえば、QoS が 1 に設定されている場合、コンシューマーは一度に 1 つの未確認メッセージしか持てません。サーバーは、コンシューマーがメッセージを処理して ACK を送信するのを待ってから、次のメッセージをプッシュする必要があります。ACK が受信されない場合、サーバーはタイムアウトを待ってからリトライします。
デフォルトのマスターキーの使用
はい。
エラー：The channelMax limit is reached
サーバーは、すべての接続にまたがるチャネルの総数ではなく、接続ごとのチャネル数を制限します。
このエラーは、createChannel メソッドが null を返すたびに SDK によってログに記録されます。
インスタンスをアップグレードした後は、クライアントを再起動する必要があります。そうしないと、既存の接続はアップグレード前のチャネル制限を引き続き使用するため、エラーが発生し続けます。
たとえば、チャネルの最大値が 100 のインスタンスを購入した場合、接続が確立されると、クライアントとサーバーはこの制限をネゴシエートします。後でインスタンスをアップグレードして 2,000 または 2,500 チャネルをサポートするようにしても、アップグレード前に確立された接続は、元の 100 チャネルの制限に依然として制約され、エラーを発生させ続けます。
チャネルパラメーターのネゴシエーションプロセス
TPS のアップグレードによる影響
いいえ。コンソールで TPS 制限をアップグレードしても、既存の接続が中断されたり切断されたりすることはありません。
新しい接続によるチャネルのシャットダウン
いいえ、通常は発生しません。ただし、ネットワーク帯域幅、メモリ、JVM 容量などのクライアントリソースが不十分な場合、他の接続やチャネルが中断される可能性があります。クライアントのリソース使用状況を調査し、中断の原因となりうるリソースの競合や不足がないか確認することを推奨します。
キューコンシューマーの消失
まず、インシデント発生時のクライアントのアプリケーションロジックとリソースの状態を確認することを推奨します。アプリケーションを中断させた可能性のある、中断されたプロセスやリソース不足などの問題を探してください。クライアントが正常に機能している場合は、サーバーが期待どおりにメッセージを配信しているかどうかを確認してください。
キューのパージが機能しない
パージ操作では、未確認 (unacked) のメッセージはクリアされません。unacked メッセージとは、クライアントに配信されたものの、まだ確認応答がされていないメッセージのことです。これらのメッセージ数は、メッセージの有効期限が切れると自動的に更新されます。
クライアントログからの TPS の計算
次の SQL クエリを使用してください。
* and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000結果のサンプル：
Logstore の変更後にログが空になる
新しい Logstore で、[インデックス作成を有効にする] をクリックしてください。約 1 分待ってからページを更新すると、ログが表示されます。
手順：
1) [インデックス作成を有効にする] をクリックしてください。
2) [OK] をクリックしてください。
RabbitMQ の切断の原因
クライアントが送信する有効な ACK の数が少ない場合、サーバーは確認応答を受信しないため、メッセージを繰り返し再配信します。これにより、継続的なメッセージの蓄積が発生する可能性があります。
クライアント側のこのメッセージの蓄積は、接続がハートビートパケットを送信するのを妨げる可能性があります。これにより、最終的に Connection ALL_IDLE エラーと切断が引き起こされます。まず、クライアントが有効な ACK の送信に失敗する理由を調査する必要があります。
TTL の設定
TTL の最大値は 3 日です。3 日を超える設定は無効です。TTL が無効な場合、期限切れのメッセージはデッドレターキューに移動されず、他の予期しない動作を引き起こす可能性があります。
1) TTL が設定されていない場合、キュー内のすべてのメッセージは通常メッセージです。モニタリングの readyMessage メトリックは、蓄積されたメッセージの実際の数を反映します。
2) TTL が設定されている場合、readyMessage メトリックは有効なメッセージの数を表します。
a) TTL が正しく機能している場合、有効なメッセージの数は TTL に基づいて動的に計算されます。readyMessage メトリックはこの数を正確に反映します。
b) TTL が設定されているが有効でない場合、有効なメッセージの数は常に 0 になります。readyMessage メトリックも 0 を示し、実際のメッセージの蓄積を反映しません。
エラー：java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768
このエラーは、メッセージヘッダーがフレームサイズの制限を超えたことを示します。メッセージヘッダーのデフォルトの制限は 32 KB であり、サーバー上で変更することはできません。
このエラーを防ぐには、大きなデータをメッセージヘッダーからメッセージ本文に移動してください。
キューのパージ後のメッセージ検索
メッセージ検索機能は、ライブキューではなくログデータをクエリします。ログはキュー内のメッセージよりも長く保持されるため、キューからメッセージがパージされた後でも、そのレコードをログ内で見つけることができます。
サブスクリプションのバインド解除エラー
原因：
排他キューは、最初にそれを宣言した接続にのみ表示されます。したがって、その特定の接続によってのみ削除でき、コンソールからは削除できません。
詳細については、「排他キュー」をご参照ください。
解決策：
1) 排他キューが不要になった場合は、対応する接続を切断してください。キューとそのバインディングは自動的に削除されます。
2) キューを作成した接続の ID が見つからない場合は、クライアントを再起動して排他キューを削除してください。
エラー：VPC flow is not allowed to login in
原因：
サーバーは、使用された認証情報がコンソールから生成された静的認証情報ではないと判断し、リクエストをオープンソースの認証トラフィックと誤って解釈して接続を拒否します。
解決策：
VPC からの接続を確認した上で、コンソールで生成された静的認証情報を使用していることを確認してください。不明な場合は、認証情報を再生成することを推奨します。
インスタンス作成が 30 分以上かかる問題
トラブルシューティング手順：
インスタンス作成時に指定した VPC が存在し、アカウント (UID) に属し、「利用可能」状態であることを確認してください。
インスタンス作成時に指定した vSwitch が要件を満たしていることを確認してください。詳細については、CreateInstance API の
VswitchIdsパラメーターをご参照ください。
原因：
この問題は通常、インスタンス作成プロセス中に VPC または vSwitch の設定が変更された場合に発生します。たとえば、最初のリクエスト検証が成功した後に VPC が削除されると、非同期のインスタンス作成は失敗します。
解決策：
プロセス中に作成パラメーターが変更された場合 (たとえば、VPC または vSwitch が削除された場合)、ApsaraMQ for RabbitMQ インスタンスを解放し、新しいインスタンスを作成してください。
リージョン間のプライベートネットワークアクセス
リージョン間のプライベートネットワークアクセスの標準的な解決策は、PrivateLink と Cloud Enterprise Network (CEN) の組み合わせを使用することです。
この解決策では PrivateLink の料金が発生することにご注意ください。詳細については、「PrivateLink エンドポイント」をご参照ください。
PrivateLink エンドポイント作成エラー：VPC パラメーター
原因：
VPC ID が存在しないか、VPC が利用可能状態ではありません。
解決策：
選択した Virtual Private Cloud (VPC) が存在し、「利用可能」状態であることを確認してください。VPC コンソールで VPC のステータスを確認できます。
PrivateLink エンドポイント作成エラー：VSwitch パラメーター
原因：
選択した vSwitch が、次の条件の 1 つ以上を満たしていません。
少なくとも 2 つの異なるゾーンから vSwitch を選択する必要があります (一部の単一ゾーンリージョンには適用されません)。
vSwitch は選択した VPC に属している必要があります。
vSwitch は利用可能状態である必要があります。
vSwitch には少なくとも 20 個の利用可能な IP アドレスが必要です。
vSwitch が存在するゾーンは NLB の作成をサポートしている必要があります。
解決策：
vSwitch の数を確認してください：単一ゾーンリージョン (南京、福州、武漢-ローカル、東南アジア 6、東南アジア 7、北東 2、中東 1 など) の場合は、少なくとも 1 つの vSwitch を選択してください。その他のリージョンの場合は、少なくとも 2 つの異なるゾーンから vSwitch を選択してください。
vSwitch が選択した VPC に属し、利用可能状態であることを確認してください。
vSwitch に少なくとも 20 個の利用可能な IP アドレスがあることを確認してください。
vSwitch が存在するゾーンが NLB の作成をサポートしていることを確認してください。
PrivateLink エンドポイント作成エラー：セキュリティグループパラメーター
原因：
選択したセキュリティグループが、次の条件の 1 つ以上を満たしていません。
セキュリティグループには、宛先ポート 5672 および 5671 での TCP トラフィックを許可するインバウンドルールが必要です。
マネージドセキュリティグループはサポートされていません。
セキュリティグループは選択した VPC に属している必要があります。
セキュリティグループの数は、アカウントのクォータを超えてはなりません。
解決策：
セキュリティグループに、宛先ポート 5672 および 5671 での TCP トラフィックを許可するインバウンドルールがあることを確認してください。
マネージドセキュリティグループを選択していないことを確認してください。
セキュリティグループが選択した VPC に属していることを確認してください。
エラー：PrivateLink サービスが有効化されていません
原因：
アカウントで PrivateLink サービスが有効化されていません。
解決策：
PrivateLink サービスを有効化してから、再度 PrivateLink エンドポイントの作成を試みてください。詳細については、「PrivateLink とは」をご参照ください。
クライアントで IOException または接続エラーが発生する原因は何ですか？
以下は、IOException または 接続エラー の原因となる可能性があります:
ネットワークの問題
クライアントとサーバー間のネットワークの不安定性や中断により、接続が切断されることがあります。
ALL_IDLE の問題
ALL_IDLE はさまざまな理由で発生する可能性があります。
SDK の中断：クライアントが使用する SDK がサーバーへのハートビートパケットの送信を停止すること。
ブロックされたコンシューマースレッド：コンシューマースレッドがブロックされると、TCP バッファがサーバーメッセージで満たされます。クライアントはハートビートパケットを送信できません。
単一接続上の複数チャネルでのトラフィック急増：単一接続上の複数のチャネルが同時にメッセージを送信し、TCP トラフィックの急増を引き起こします。サーバーからのパケットと組み合わせると、Linux Netfilter Conntrack が INVALID になる可能性があります。これにより、クライアントは接続をリセットします。
確認事項：
クライアントのハートビートメカニズムがオンになっていること。
コンシューマースレッドがブロックされていないこと (例：消費ロジックが多すぎる、または同期操作による
BasicAckのブロッキング)。クライアントがハートビートまたは RST 接続を送信していること。tcpdump を使用してローカルパケットを取得し、クライアントとサーバーの接続を確認してください。