REST API レート制限
最終更新日: 06 年 2024 月 XNUMX 日LogicMonitorのRESTAPIへのリクエストにはレート制限が課せられます。 制限は、エンドポイントとメソッドの組み合わせごとに割り当てられます。 たとえば、GET / device / devicesへのリクエストには、POST / device / devicesへのリクエストやGET / device / devices / ID / devicedatasourcesへのリクエストとは異なる制限がある場合があります。 レート制限を超えて行われたリクエストは、HTTP 429 Too ManyRequestsとエラーを含むレスポンスを受け取ります。 制限はユーザーごとではなく、アカウントに対して行われたすべてのリクエストに適用されます。
重要: デフォルトの制限は、時折のピーク使用量についてテストされており、これらの制限でAPIを継続的に使用することはありません。 定格制限でAPIを継続して使用すると、ポータルの全体的なパフォーマンスに影響を与える可能性があります。 LogicMonitorは、ポータルの可用性とパフォーマンスを最優先するため、ポータルのパフォーマンス、アラート、およびデータ収集に悪影響が及ぶ場合は、APIの制限をデフォルトから減らす権利を留保します。 ニーズがこれらの設計制限を超える場合は、カスタマーサクセスマネージャーと積極的に協力して、考えられるオプションについて話し合ってください。
応答ヘッダーのレート制限情報
制限および制限への近さに関する情報は、以下の応答ヘッダーで返されます。 これにより、課されるレート制限を表示し、必要に応じてスクリプトを調整してそれらを回避できます。
ヘッダ | 説明 |
X-レート-制限-制限 | X-Rate-Limit-Windowごとのリクエスト制限 |
Xレート制限-残り | 時間枠に残っているリクエストの数 |
X-Rate-Limit-ウィンドウ | 秒単位のローリング時間ウィンドウの長さ |
レート制限ロジック
制限は変更される可能性があるため、上記のヘッダーとその値に基づいてレート制限を回避することを目的としたロジックを使用することをお勧めします。 たとえば、レート制限に達したときに60秒待機してから別の要求を行うロジックをスクリプトに導入できます。 以下は、さまざまな言語にわたるそのようなロジックの例です。
Python
次のロジックは、requestsモジュールを使用してループで利用でき、「X-Rate-Limit-Remaining」ヘッダー値がゼロになった場合に単純なタイムアウトを実装します。
if (response.headers['X-Rate-Limit-Remaining'] == 0):
window = response.headers['X-Rate-Limit-Window']
time.sleep(float(window))
ルビー
次のロジックは、ネットhttpライブラリを使用してループで利用でき、「X-Rate-Limit-Remaining」ヘッダー値がゼロになった場合に単純なタイムアウトを実装します。
if resp['X-Rate-Limit-Remaining'].to_i == 0
sleep resp['X-Rate-Limit-Window'].to_i
end
Groovy
次のロジックは、Apache httpライブラリを使用してループで利用でき、「X-Rate-Limit-Remaining」ヘッダー値がゼロになった場合に単純なタイムアウトを実装します。
remainingRequestsHeader = response.getHeaders('X-Rate-Limit-Remaining');
windowHeader = response.getHeaders('X-Rate-Limit-Window');
remainingRequests = remainingRequestsHeader[0].getValue();
window = windowHeader[0].getValue();
if (remainingRequests.toInteger() == 0){
Thread.sleep(window.toInteger() * 1000);
}
PowerShellの
PowerShellでレート制限を回避する方法は、リクエストを行う方法によって異なります。 Invoke-RestMethodコマンドレットは、例外が発生しない限り応答ヘッダーをスローします。そのため、Invoke-RestMethodを使用している場合は、HTTP429が返されたときに再試行を試みることをお勧めします。 たとえば、次のコード例に示すように、try catchループでAPIリクエストを作成し、結果のステータスが429の場合に再試行できます。
(または、Invoke-WebRequestコマンドレットを使用して、律速応答ヘッダーに基づいてロジックを追加することもできます。)
<# Make request & retry if failed due to rate limiting #>
$Stoploop = $false
do {
try {
<# Make Request #>
$response = Invoke-RestMethod -Uri $url -Method $httpVerb -Headers $headers
<# Print status and body of response #>
$status = $response.status
$body = $response.data| ConvertTo-Json -Depth 5
Write-Host "Status:$status"
Write-Host "Response:$body"
$Stoploop = $true
}
catch {
if ($response.status -eq 429){
Write-Host "Request exceeded rate limit, retrying in 60 seconds..."
Start-Sleep -Seconds 60
}
else {
Write-Host "Request failed, not as a result of rate limiting"
$Stoploop = $true
}
}
}
While ($Stoploop -eq $false)
デフォルトのレート制限
次の表に、リクエスト タイプごとのデフォルトのレート制限を示します。
HTTPメソッド | レート制限 |
DELETE | 300 / M |
GET | 500 / M |
PATCH | 250 / M |
POST | 200 / M |
PUT | 200 / M |
レート制限の例外
次の表に、エンドポイント/メソッド リクエストの組み合わせごとのレート制限を示します。
HTTPメソッド | APIリクエスト | レート制限 | 説明 |
GET | /santaba/rest/alert/alerts | 400 / min | アラートリストを取得 |
GET | /santaba/rest/device/devices/{id}/alerts | 600 / min | アラートを受け取る |
GET | /santaba/rest/device/groups | 400 / min | デバイス グループ リストの取得 |
GET | /santaba/rest/device/groups/{id} | 1000 / min | ID でデバイス グループを取得する |
GET | /santaba/rest/device/devices/{deviceId}/properties | 700 / min | デバイスのプロパティを取得する |
GET | /santaba/rest/device/devices | 700 / min | デバイス リストを取得する |
GET | /santaba/rest/device/devices/{deviceId}/devicedatasources/{hdsId}/instances | 500 / min | デバイス インスタンス リストの取得 |
POST | /santaba/rest/setting/opsnotes | 100 / min | opsnote を追加 |
GET | santaba/rest/swagger.json | 10 / min | Swaggerドキュメント |
POST | santaba/rest/device/instances/datafetch | 5 / min | インスタンスデータの取得 |
ご注意: 上の表に記載されていないエンドポイントは、デフォルトのレート制限に従います。