このトピックでは、Data Service のシステム設定を構成する方法について説明します。
権限
スーパー管理者とシステム管理者のみがシステム構成を変更できます。
システム構成ページへのアクセス
Dataphin のホームページで、上部のメニューバーから [サービス] > [サービス管理] を選択します。
左側のナビゲーションウィンドウで、[システム構成] をクリックして [システム構成] ページを開きます。
API 呼び出し認証の構成
前提条件
API 呼び出し認証は、ゲートウェイの構成が完了した後にのみ構成できます。ゲートウェイの構成方法の詳細については、「Data Service の設定」をご参照ください。
制限事項
Alibaba Cloud API Gateway (専用または共有インスタンス) または Apsara Stack API Gateway を使用する場合、呼び出しに対してトークンベースの認証を有効にできます。
Dataphin の自己開発ゲートウェイを使用する場合、アプリケーションの IP ホワイトリストを有効にできます。
Alibaba Cloud API Gateway-専用インスタンスまたは Alibaba Cloud API Gateway-共有インスタンスを使用する場合、API 呼び出し認証を有効にすると、API 呼び出し認証セクションは非表示になります。既存の API を再公開して、トークンベースの認証を有効にする必要があります。
Apsara Stack API Gateway を使用する場合、API 呼び出し認証の構成を変更できます。
呼び出しに対するトークンベース認証の有効化
[API 呼び出し認証の構成] セクションで、[変更] をクリックし、呼び出しに対するトークンベース認証を有効にするかどうかを選択します。
有効化: アプリケーションの AppKey と AppSecret を取得し、SDK コードを使用してトークンを生成する必要があります。トークンは、API を呼び出す際の認証に使用されます。このメソッドはデータセキュリティを強化します。
無効化: 認証トークンは不要です。API 呼び出しはトークンを使用して認証されません。API の基本情報を提供するだけで API を呼び出すことができます。このオプションはデータセキュリティが低いため、注意して使用する必要があります。
[保存] をクリックして、API 呼び出し認証の構成を完了します。
アプリケーション IP ホワイトリストを有効にする
[API 呼び出し認証の構成] セクションで、[変更] をクリックし、アプリケーション IP ホワイトリストを有効にするかどうかを選択します。
この機能を有効にすると、[呼び出し-アプリケーション管理] ページでアプリケーションの IP アドレスホワイトリストを構成できます。アプリケーションが API を呼び出すときに、その IP アドレスがホワイトリストにある場合、呼び出しは認証なしで続行されます。
[保存] をクリックして、API 呼び出し認証の構成を完了します。
API キャッシュデータの保存場所
アクティブリンクとスタンバイリンクのデータキャッシュを有効にするには、次の条件を満たす必要があります:
Dataphin の自己開発ゲートウェイを使用する必要があります。他のゲートウェイタイプはサポートされていません。詳細については、「API ゲートウェイの構成」をご参照ください。
DataService Studio またはオンラインタギングサービスの高可用性 (HA) 機能を有効にする必要があります。
[API キャッシュデータストレージ場所] セクションで、[変更] をクリックして API キャッシュデータのストレージ場所を指定します。アクティブリンクとスタンバイリンクの構成は同じです。
システム Redis + アプリケーションメモリ: キャッシュデータをシステムパブリック Redis インスタンスに保存します。ストレージスペースは他のモジュールと共有されます。このオプションは、キャッシュデータ量が少ないシナリオに適しています。
説明スタンバイリンクは、Dataphin スタンバイシステムのパブリック Redis インスタンスにキャッシュデータを保存します。このオプションは、キャッシュデータ量が少ないシナリオに適しています。
アプリケーションメモリのみ: メモリ使用量がシステムの応答時間に影響するため、キャッシュデータ量が多い場合はこのオプションは推奨されません。このオプションは、少数の API のみがキャッシュを必要とし、データ量が非常に少ないシナリオに適しています。
説明キャッシュ期間は、Dataphin アプリケーションのデプロイメント中に設定されるメモリデータキャッシュ時間によって決まります。API の作成時に定義したキャッシュ期間は有効になりません。
指定された Redis インスタンス: 最適な安定性とパフォーマンスを得るために、専用の Redis インスタンスを使用できます。このオプションは、指定された Redis インスタンスにキャッシュデータを保存し、多くの API でキャッシュが有効になっている場合や、キャッシュデータ量が多いシナリオに適しています。Redis インスタンスを追加するには、「Redis データソースの作成」をご参照ください。
重要API キャッシュデータに使用される Redis インスタンスを削除しないでください。削除すると、キャッシュデータのストレージが失敗し、API で有効になっているキャッシュが無効になります。
[保存] をクリックして、API キャッシュデータストレージ場所の構成を完了します。
SQL インジェクションチェック
DataService Studio またはオンラインタギングサービス機能を有効にする必要があります。
登録済み API は SQL インジェクションチェックをサポートしていません。
[SQL インジェクションチェック] セクションで、[変更] をクリックして SQL インジェクションチェックを有効または無効にします。
有効化: 有効にすると、API 呼び出し中に入力 SQL がチェックされます。チェックが失敗した場合、API 呼び出しはブロックされます。ページで返されるエラーコードを確認することで、失敗の理由を表示できます。
無効化: 無効にすると、API 呼び出し中に入力 SQL はチェックされません。
[保存] をクリックして、SQL インジェクションチェックの構成を完了します。
ログと O&M 統計設定
前提条件
ログと O&M 統計は、ゲートウェイが構成された後にのみ構成できます。ゲートウェイのログ収集が構成されていないか、構成後に無効になっている場合、失敗したゲートウェイログは収集できません。ゲートウェイの構成方法の詳細については、「Data Service の設定」をご参照ください。
制限事項
現在のログ収集フレームワークは、完全な高可用性を保証しません。そのため、アプリケーションの再起動時や API 呼び出しの失敗時に、一部のログ情報が失われたり重複したりする可能性があります。
DataService Studio HA が有効になっている場合、アクティブリンクに対してのみ外部ログストレージデータソースの接続性をテストできます。アクティブリンクとスタンバイリンクの両方がログストレージデータベースに接続できる場合にのみ、両方のリンクのログ収集が成功します。
Alibaba Cloud API Gateway (専用または共有インスタンス) を使用する場合、以前に公開された API の呼び出しログには
requestid情報が含まれません。この情報をログに含めるには、API を再公開する必要があります。Alibaba Cloud API Gateway-共有インスタンスを使用する場合、ゲートウェイは
requestQueryString,requestHeaders,requestBody,responseHeaders, or responseBodyなどの情報の収集をサポートしていません。ゲートウェイで認証、スロットリング、またはその他の障害が発生した場合、呼び出しログにはリクエストパラメーター、リクエスト SQL、またはその他の情報は含まれません。API ゲートウェイでログ収集が有効になっていない場合、ゲートウェイからの失敗した呼び出しの数は呼び出し統計に含まれず、失敗した呼び出しのログは収集できません。完全なログ情報を収集するために、ゲートウェイのログ収集を構成することを強くお勧めします。
呼び出し詳細ログのストレージテーブルが変更されると、呼び出し詳細ログは新しいストレージテーブルからクエリされます。以前のストレージテーブルのデータは検索できなくなります。同様に、統計ログテーブルが変更されると、以前の統計ログテーブルのデータは検索できなくなります。履歴ログへのアクセスが失われないように、テーブルの変更を適切に計画してください。
手順
構成の変更は同日に有効になります。指定された保存期間を超えた呼び出し詳細ログと呼び出し統計は自動的に消去されます。保持期間が長いと大量のストレージを消費する可能性があるため、この設定は注意して構成してください。
[ログと O&M 統計の設定] セクションで、下部にある [変更] をクリックして、API 呼び出し詳細ログと呼び出し統計のストレージ場所と期間を構成します。
呼び出し詳細ログ: この機能はデフォルトで無効になっています。この機能を有効にすると、成功した API 呼び出し詳細ログと失敗した API 呼び出し詳細ログのストレージ場所と期間を構成できます。
[ストレージデータベース]：呼び出し詳細ログの保存場所を選択します。 オプションには、[組み込みストレージ] と [外部データソース] があります。
組み込みストレージ: 最大 500,000 件の成功した呼び出し詳細ログと 500,000 件の失敗した呼び出し詳細ログを保存します。利用可能な保存期間は [3 日]、[7 日]、[14 日]、[カスタム] (1〜9,999 日)、[保存しない]、および [無制限] です。
外部データソース: 最大 1 億件の成功した呼び出し詳細ログと 1 億件の失敗した呼び出し詳細ログを保存します。ログストレージのデータソースタイプ、データソース、およびログテーブル名を選択する必要があります。利用可能な保存期間は [7 日]、[14 日]、[30 日]、[カスタム] (1〜9,999 日)、[保存しない]、および [無制限] です。
[データソースタイプ]：PostgreSQL データソースのみがサポートされています。
データソース: 指定されたタイプのデータソースインスタンスを選択します。[接続性のテスト] をクリックして、トランザクション処理 (TP) アプリケーションのデータソース接続をテストします。データソースを作成するには、[作成] をクリックして [データソースの作成] ダイアログボックスを開きます。このダイアログボックスは [管理センター] > [データソース管理] にあります。
ログテーブル名 - プライマリテーブル: API 呼び出しログ情報を保存するテーブルを選択します。[ワンクリックでテーブルを作成] をクリックすることもできます。[ログテーブルの作成] ダイアログボックスで、[テーブル名の存在を確認] をクリックします。すると、システムはログテーブルとその関連インデックステーブルを作成します。
ログテーブルには次のフィールドが含まれます。各フィールドの長さは 10,240 文字を超えることはできません。
フィールド名
データ型
フィールドの説明
biz_code_describe
VARCHAR(1024)
ビジネスコードの説明。
tenant_id
INT4
テナント ID。
status_code
VARCHAR(16)
HTTP ステータスコード。
biz_code
VARCHAR(64)
ビジネスコード。
create_time
TIMESTAMP(3)
ログが作成された時刻。
api_no
INT4
API 番号。
ip
VARCHAR(32)
クライアント IP アドレス。
end_time
TIMESTAMP(3)
クエリの終了時刻。
response_size
INT4
応答サイズ (バイト単位)。
sql
TEXT
クエリの SQL 文。
start_time
TIMESTAMP(3)
クエリの開始時刻。
app_key
INT4
アプリケーションキー。
response_parameter
TEXT
応答パラメーター。
status_describe
VARCHAR(1024)
HTTP ステータスコードの説明。
cost_time
INT4
クエリ期間 (ミリ秒単位)。
id
INT8
自動インクリメントの序数。
request_size
INT4
リクエストサイズ (バイト単位)。
result_count
INT4
API クエリ結果の数
request_id
VARCHAR(64)
クエリの一意の ID。
request_parameter
TEXT
リクエストパラメーター。
successful
ブール値
クエリが成功したかどうかを示します。
job_id
VARCHAR(64)
非同期呼び出しのタスク ID。
execute_mode
INT2
呼び出しの実行モード。
execute_cost_time
INT4
非同期呼び出しの SQL 実行期間 (ミリ秒単位)。
補足情報テーブル: 非同期呼び出しモードでのパブリック API への呼び出しのログ情報を保存します。[ワンクリックでテーブルを作成] をクリックすることもできます。[ログテーブルの作成] ダイアログボックスで、[テーブル名の存在を確認] をクリックします。すると、システムは補足情報テーブル (パブリック API 呼び出し詳細ログテーブル) を作成します。
補足情報テーブルには次のフィールドが含まれます。
フィールド名
データ型
フィールドの説明
id
INT8
自動インクリメントの序数。
api_no
INT4
API 番号。
job_id
VARCHAR(64)
非同期呼び出しのタスク ID。
ext_content
TEXT
パブリック API 呼び出しの結果。
create_time
TIMESTAMP(3)
ログレコードが作成された時刻。
update_time
TIMESTAMP(3)
ログレコードが更新された時刻。
tenant_id
INT4
テナント ID。
説明成功したログと失敗したログは同じテーブルに保存されます。テーブル名はテナントごとに一意です。`successful` フィールドを使用してそれらを区別できます。
期限切れのログは、毎日 02:00 からシステムによって削除されます。有効期限は次のように計算されます:
現在の日付 - 保存期間より古いログ - 1 < 作成時刻。組み込みストレージは、応答時間が長い API 呼び出しのトラブルシューティングに使用できる成功ログの保存など、短期的なストレージシナリオに適しています。外部データソースは、API 呼び出しエラーのトラブルシューティングに使用できる失敗ログの保存など、長期的なストレージシナリオに適しています。
オンプレミス環境 (パブリッククラウドおよびプライベートクラウドのオンプレミスデプロイメントを含む) でのアップグレード後、構成ファイル内の呼び出し詳細ログのテーブル名が
dataservice_api_logからdataservice_api_log_${tenantid}に変更されます。このテーブルにログ収集タスクを構成している場合は、[DataService Studio] > [管理] > [システム構成] > [呼び出し詳細ログ] > [ログテーブル名] に移動してログテーブル名を更新する必要があります。
[呼び出し統計]：1 分ごとおよび 5 分ごとの API 呼び出し統計ログの保存場所と期間を構成します。
[ストレージデータベース]：呼び出し統計ログの保存場所を選択します。 オプションには、[組み込みストレージ] と [外部データソース] があります。
組み込みストレージ: 最大 500,000 件の 1 分の呼び出し統計ログと 500,000 件の 5 分の呼び出し統計ログを保存します。利用可能な保存期間は [7 日]、[14 日]、[30 日]、および [カスタム] (1〜9,999 日) です。
外部データソース: 最大 1 億件の 1 分の呼び出し統計ログと 1 億件の 5 分の呼び出し統計ログを保存します。呼び出し統計ログストレージのデータソースタイプ、データソース、およびテーブル名を選択する必要があります。1 分の呼び出し統計ログの利用可能な保存期間は [7 日]、[14 日]、[30 日]、および [カスタム] (1〜9,999 日) です。5 分の呼び出し統計ログの利用可能な保存期間は [183 日]、[366 日]、[2 年]、[3 年]、および [カスタム] (1〜9,999 日) です。
[データソースタイプ]：PostgreSQL データソースのみがサポートされています。
データソース: 指定されたタイプのデータソースインスタンスを選択します。[接続性のテスト] をクリックして、TP アプリケーションのデータソース接続をテストします。データソースを作成するには、[作成] をクリックします。これにより、[管理センター] > [データソース管理] > [データソースの作成] ダイアログボックスに移動します。
テーブル名: 呼び出し統計ログを保存するテーブルを選択します。[ワンクリックでテーブルを作成] をクリックすることもできます。[ログテーブルの作成] ダイアログボックスで、[テーブル名の存在を確認] をクリックします。すると、システムはログテーブルとその関連インデックステーブルを作成します。
ログテーブルには次のフィールドが含まれます。
フィールド名
データ型
フィールドの説明
tenant_id
INT4
テナント ID。
client_ips
VARCHAR(256)
クライアント IP アドレスの概要 (最大 10 件)。
biz_error_count
INT8
API クエリにおけるビジネスエラーの数。
create_time
TIMESTAMP(3)
ログレコードが作成された時刻。
total_count
INT8
API クエリの総数。
api_no
INT4
API 番号。
total_time_cost
INT8
API クエリで消費された合計時間 (ミリ秒単位)。
offline_count
INT8
API クエリにおけるサーバー側の障害数。
total_succ_time_cost
INT8
成功した API クエリで消費された合計時間 (ミリ秒単位)。
minute
VARCHAR(16)
統計の時間枠。
update_time
TIMESTAMP(3)
ログレコードが更新された時刻。
app_key
INT4
アプリケーションキー。
client_fail_count
INT8
API クエリにおけるクライアント側の障害数。
execute_mode
INT2
API 呼び出しの実行モード。
説明1 分ごとおよび 5 分ごとの呼び出し統計ログは異なるテーブルに保存されます。 テーブル名はテナントごとに一意です。
期限切れのログは、毎日 02:00 からシステムによって削除されます。有効期限は次のように計算されます:
現在の日付 - 保存期間より古いログ - 1 < 作成時刻。組み込みストレージは、応答時間が長い API 呼び出しのトラブルシューティングに使用できる 1 分の呼び出し統計ログの保存など、短期的なストレージシナリオに適しています。外部データソースは、API 呼び出しエラーのトラブルシューティングに使用できる 5 分の呼び出し統計ログの保存など、長期的なストレージシナリオに適しています。
dws_dataphin_service_api_miテーブルは、Dataphin メタデータウェアハウス共有モデルの Data Service 呼び出し回数統計テーブルであり、組み込みストレージからの API 呼び出し統計ログのみを記録します。ログストレージに外部データソースを使用する場合、このテーブルはそのデータソースからデータを収集しません。外部データソースからログデータを取得するには、統合タスクを使用する必要があります。
[保存] をクリックして、ログと O&M 統計の構成を完了します。