REST API 変更ログ

最終更新日: 07 年 2024 月 XNUMX 日

この記事では、各バージョンでの LogicMonitor REST API の変更点を取り上げます。これは、API がどのように進化し、改善されてきたかを明確に把握できるようにすることを目的としています。

v201 プラットフォーム リリースの更新

プラットフォーム リリース v201 以降、既存のフィルターに加えて _all~ 新しいフィルターを使用することもできます description~ 特定のデータを検索します。

  • _all – フィルタは全文検索、つまり以下に基づいたキーワード検索を実行します。 usernameipdescriptionsessionid 田畑。応答は、前述のフィールド全体でフィルターに指定された値と一致する結果をフェッチします。一般的な結果が得られることに注意してください。
    例– {{url}}/setting/accesslogs?filter=_all~"update value=false, old value=true"
    ここで、応答は次のようになります。
    • "update value=false, old value=true"
    • "update value=true, old value=false"
    • ある応答はすべて、 updatevaluefalseoldvaluetrue その中に(任意の順序で)。例えば、 "update value of field is changed to true, field old value was false"
  • description – フィルターは完全なテキスト検索、つまり完全な部分文字列一致を実行します。検索は、 description 分野。応答は、パラメータで指定された値と完全に一致する結果を取得します。 description 分野。限定的ではあるが具体的な結果が得られます。
    例– {{url}}/setting/accesslogs?filter=description~"update value=false, old value=true"
    ここで、応答は次のようになります。
    • "update value=false, old value=true"

v200 プラットフォーム リリースの更新

v200 プラットフォーム リリースでは、次のフィールドを使用して LogicMonitor REST API v3 Swagger を更新しました。

  • インスタンスレベルのしきい値設定 – alertTransitionInterval, alertClearInterval, alertForNoData
  • インスタンスグループレベルのしきい値設定 – alertTransitionInterval, alertClearTransitionInterval, alertForNoData
  • リソースグループレベルのしきい値の設定  alertTransitionInterval, alertClearTransitionInterval, alertForNoData

影響を受ける API エンドポイントは次のとおりです。

  • GET /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings
  • PUT /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings/{id}
  • PATCH /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId}/alertsettings/{id}
  • GET /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PUT /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PATCH /device/groups/{deviceGroupId}/datasources/{dsId}/alertsettings
  • PUT /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{dsigId}/datapoints/{dpId}/alertconfig
  • PATCH /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{dsigId}/datapoints/{dpId}/alertconfig

v198 プラットフォーム リリースの更新

Swagger および SDK ファイルの更新

v198 プラットフォーム リリースでは、LogicMonitor REST API v3 Swagger、v3 Python、GO SDK ファイルを更新しました。 Swagger および SDK ファイルは、v198 の実稼働環境へのデプロイが完了した後に使用できるようになります。ご質問がある場合は、LogicMonitor カスタマー サクセス マネージャーにお問い合わせください。詳細については、を参照してください。 REST API v3 Swagger ドキュメント.

LogicMonitor REST API v3 に追加された新しい API エンドポイントについては、次の表を参照してください。

カテゴリーエンドポイント目的
デバイスグループPOST /azure/functions/discoverSubscriptions
POST /azure/functions/testAccount
GET /aws/accountId
POST /aws/functions/testAccount
POST /saas/functions/testAccount
POST /gcp/functions/testAccount
サブスクリプション ID を表示する
Azure アカウントのテスト
AWS アカウント ID を取得する
AWS アカウントをテストする
SaaS アカウントのテスト
GCP アカウントをテストする
レポートGET /report/reports/{id}/tasks/{taskId}レポートを実行する
ユーザデータPATCH /setting/userdata/{id}
PUT /setting/userdata/{id}
デフォルトのダッシュボードを更新する
構成ソースGET /setting/configsources/{id}/updatereasonsconfigSource の更新履歴を取得する
データソースPOST /setting/datasources
PUT /setting/datasources/{id}
PATCH /setting/datasources/{id}
データソースの追加
データソースの更新
ダッシュボードグループPOST /dashboard/groups/{id}/asynccloneダッシュボードグループを非同期的に追加する
データソースインスタンスPOST /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups
PUT /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{id}
PATCH /device/devices/{deviceId}/devicedatasources/{deviceDsId}/groups/{id}
デバイス データソース インスタンス グループの追加 
デバイス データソース インスタンス グループを更新する 
且つPOST /device/instances/datafetchデバイス インスタンス データを取得する
デルタGET /device/devices/delta
GET /device/devices/delta/{deltaId}
新しいデルタ ID を持つフィルターに一致するデバイスを取得します
デルタ ID を使用してデルタ デバイスを取得する

LogicMonitor REST API v3 から削除された API エンドポイントについては、次の表を参照してください。

カテゴリーエンドポイント
データソースPOST /setting/datasources/{id}/audit
構成ソースPOST /setting/configsources/{id}/audit
プロパティソースPOST /setting/propertyrules/{id}/audit 
イベントソースPOST /setting/eventsources/{id}/audit

Bearer Token を使用した LM REST API v4 へのアクセスのブロック

v198 リリース以降、LogicMonitor REST API v4 外部エンドポイントを使用するための認証にベアラー トークンを使用できなくなります。 API v1 を使用するために、Basic 認証と LMv4 認証はすでに無効になっています。 API v4 は正式にサポートされていないことに注意してください。 LogicMonitor REST API v3 の使用をお勧めします。

Python および GO SDK のベアラー トークンのサポート

Bearer トークンを使用して、GO および Python v3 SDK を使用するための自分自身を認証できるようになりました。 SDK ファイルは、v198 の実稼働環境へのデプロイが完了した後に利用できるようになります。ご質問がある場合は、LogicMonitor カスタマー サクセス マネージャーにお問い合わせください。詳細については、を参照してください。 LogicMonitor v3 SDK.

追加の更新

  • パフォーマンスの問題のため、削除されました customColumn から  /alert/alerts & /alert/alerts/id 応答。同様に、こちらも削除しました detailMessage から  /alert/alerts 応答。ただし、ユーザーは引き続き見ることができます detailMessage in /alert/alerts/id 応答。
  • 更新中 deviceType デバイスモデルの説明。 deviceType フィールドの値は「0」に設定されます。
  • パフォーマンスの問題のため、削除されました customColumn からのリクエストパラメータ GET /alert/alerts/{id} & GET /alert/alerts

一般的な変更

REST API v1 および v2 のサポート終了のお知らせ

LogicMonitor REST API v1 および v2 を廃止することを決定しました。 3 年 2023 月から API v1 に移行することをお勧めします。API v2 と v2024 は 3 年 XNUMX 月まで引き続きサポートされ、その後はサポートが停止されます。 API vXNUMX への移行を支援するために、サポート終了日を事前にお知らせします。 詳細については、を参照してください。 LogicMonitor REST API v1 および v2 の廃止.

REST API フィルター

エンドポイントGETを呼び出すと /alert/alerts フィルターを使用すると、以前は、新しいアラートがなくても、結果が一貫せず、シャッフルされていました。 この問題は修正されました。 新しいアラートが生成されたり、既存のアラートがクリアされたりしない限り、結果はシャッフルされず、アラート リストの順序は一貫したままです。 詳細については、を参照してください。 REST API 基本フィルター & REST API 高度なフィルター.

LMv1 トークン

アプリケーションは、API と SDK を使用して複数のバックエンド プラットフォームに接続し、バックエンド プラットフォームで API と SDK を認証するためのトークン/シークレットを提供します。 認証するために、ユーザーは多くの場合、セキュリティ上の重大な問題につながるソース コードと一緒にシークレット/トークンを入力します。 セキュリティ対策として、トークンのフォーマットを改訂しました。 

LMv1 トークンは、access_id+access_key+payload+time+http_method を使用して動的に構築されます。 10 分間しか有効ではないため、リポジトリに保存したりコミットしたりしても意味がありません。

  • access_id – サイズ 20 の英数字で構成されます。たとえば、 32WDPj2KIdZikg7g98SR
  • access_key – サイズ 120 の英数字で構成されます。たとえば、 lma_A4S8)Ps9^jT9[4YFN4S36yG~+uF[h4tG){]]827McL=E3RtaqED%+{(n2p%+LOTRhYjc3ZmQtNmI2MC00M2EzLWJlZjYtMGQ3MmVhOTEwYzA3L0BeLhN  

REST APIv3での変更

numOfKuberntesDevices フィールドの追加

追加しました Kuberntes デバイスの数 フィールドを DeviceGroup API モデル。 を参照するすべてのエンドポイントの応答本文に存在します。 DeviceGroup API モデル。 ターゲット グループ内の Kubernetes リソースの数を示します。 また、ターゲット グループのサブ グループ内の Kubernetes リソースの数も含まれます。

例: 

HTTPメソッドAPIレスポンス
GET
PUT
PATCH
サンタバ/休息/デバイス/グループ/{id}
POST
GET
サンタバ/休息/デバイス/グループ

選択した場合:

  • ルート グループ (id = 1) – 応答本文には、ポータルに存在するすべての Kubernetes デバイスの数が含まれます。
  • 特定のデバイス グループ – 応答本文には、そのデバイス グループに存在する Kubernetes デバイスの数が含まれます。

新しいエンドポイント

REST API v3 の主なハイライトは、XNUMX つの新しいエンドポイントの追加です。 彼らです:

  • POST – /setting/datasources/{id}/audit
  • POST – /setting/evensources/{id}/audit
  • POST – /setting/configsources/{id}/audit
  • POST – /setting/propertyrules/{id}/audit
  • GET – /setting/integrations/auditlogs

詳細については、を参照してください。 REST API v3 Swagger ドキュメント.

REST APIv2での変更

LogicMonitor REST API v2 には、非下位互換性などの新機能が含まれています。

ステータスコード

REST API v1 では、応答に 200 つの状態コードがありました。HTTP 状態コード (ほとんど常に 2) と、応答本文の別の LogicMonitor 状態コードです。 REST API vXNUMX では、HTTP ステータス コードを XNUMX つ返すようになり、返される可能性のあるステータス コードのリストを大幅に絞り込みました。 

基本認証のサポートなし

REST API v2 での基本認証のサポートを削除しました。 多くの追加の利点 (UI/API アクセスの分離、監査ログ エントリ、およびより安全) があるため、認証のための API トークンのより多くの使用を促進するためにこれを行いました。

PATCH メソッドのサポート

REST API v2 には、ほとんどのリソースに対する HTTP PATCH のサポートが含まれています。 これは、PUT を使用してリソース全体 (すべてのフィールド) を更新するのではなく、リソースの XNUMX つのフィールドのみを更新する場合に便利です。 

レスポンスボディ構造

REST API v1 では、成功した応答が含まれていました status, エラーメッセージ, データ 応答のトップ レベルのオブジェクト。 REST API v2 では、HTTP ステータスが LM ステータスと一致するようになったため、成功応答の最上位で「data」の内容が返されます。 失敗した応答には、エラー メッセージ フィールドが含まれます。 これは、REST API v1 用に作成され、API 応答を解析するように構成されたスクリプトを、これを反映するように調整する必要があることを意味することに注意してください。

記事上で