ClickHouse OpenAPI を使用すると、
ClickHouse サービスと同様に Managed Postgres サービスをプログラムから
操作できます。同じ API では、サービスのメトリクスをスクレイピングするための
[Prometheus エンドポイント] も公開されています。
すでに OpenAPI に慣れている場合は、[API キー] を取得して
Managed Postgres API リファレンス に直接進んでください。
そうでない場合は、このまま簡単な概要をご確認ください。
ClickHouse OpenAPI を使用するには認証が必要です。作成方法については
API keys を参照してください。次に、以下のように Basic 認証の認証情報として使用します。
次に、Organization ID が必要になります。
- コンソールの左下で組織名を選択します。
- Organization details を選択します。
- Organization ID の右側にあるコピーアイコンをクリックして、
直接クリップボードにコピーします。
これで、次のようにリクエストで使用できます。
これで最初の Postgres API リクエストを実行できました。上記の list API では、
組織内のすべての Postgres サーバーが一覧表示されます。出力は次のようになります。
Postgres サービス のライフサイクルを見ていきましょう。
まず、create API を使って新しく作成します。このリクエストでは、JSONボディに次のプロパティを含める必要があります。
name: 新しいPostgres サービスの名前
provider: クラウドプロバイダーの名前
region: serviceをデプロイするproviderのネットワーク内のRegion
size: VMのサイズ
これらのプロパティの設定可能な値については、create API のドキュメントを参照してください。さらに、デフォルトの17ではなく、Postgres 18を指定します。
次に、このデータを使用して新しいインスタンスを作成します。なお、そのためにはContent-Typeヘッダーの内容が必要です:
成功すると、新しいインスタンスが作成され、その情報
(接続情報を含む) が返されます:
レスポンスのidを使って、サービスを再度取得します:
出力は作成時に返されるJSONと似ていますが、state を確認して
ください。これが running に変わったら、サーバーの準備完了です。
これで、connectionString プロパティを使って、たとえば
psql 経由で接続できます:
psql を終了するには、\q と入力します。
patch API は、RFC 7396 の JSON Merge Patch を使用して、Managed
Postgres サービスのプロパティの一部を更新できます。複雑なデプロイメントでは、タグが特に重要になることがあります。その場合は、リクエストでタグだけを送信してください:
返却されるデータには、新しいタグが含まれているはずです:
OpenAPI では、patch API でサポートされていないプロパティを更新するための追加のエンドポイントが提供されています。たとえば、Postgres configuration を更新するには、
config API を使用します。
出力には、更新後の設定に加えて、変更による影響を説明するメッセージも表示されます:
Postgres サービスを削除するには、delete API を使用します。
Postgres サービスを削除すると、サービス自体とその中のすべての
データが完全に削除されます。サービスを削除する前に、必ずバックアップを
取得するか、レプリカをプライマリに昇格させてください。
成功した場合、レスポンスではステータスコード 200 が返されます。例:
Prometheus 互換のエンドポイントが 2 つあり、Managed Postgres サービスの CPU、メモリ、I/O、接続、
およびトランザクションのメトリクスを公開しています。1 つは組織内のすべてのサービスの
メトリクスを返し、もう 1 つは単一のサービスのメトリクスを返します。設定については
[Prometheus エンドポイント] ページを、メトリクスの一覧については
[メトリクス リファレンス] を参照してください。
Cloud
Console の [クエリインサイト] タブの各ステートメントのテレメトリーは、プログラムからも利用できます。2 つのエンドポイントにより、サービス上の最も遅い
クエリパターンを取得できます。1 つは影響度順にすべてのパターンを一覧表示し、もう 1 つは単一のパターンとその最近の実行結果を返します。
[スローパターン API] は、一定の時間範囲内で観測された最も遅いクエリ
パターンの集約メトリクスを返します。時間範囲の指定は必須です。
RFC 3339 形式のタイムスタンプとして from_date と to_date を渡してください:
結果はデフォルトで、total_duration の
降順で、最もコストの高いパターンから返されます。sort_by を使うと別の指標 (たとえば
p99_duration、call_count、または total_wal_bytes) でソートでき、sort_order
で並び順を反転できます。db_name、db_user、
db_operation、および app フィルターで対象を絞り込み、limit と
offset でページ送りできます。
各結果は 1 つの正規化されたパターンで、リテラルは取り除かれ、
実行時間はマイクロ秒単位で示されます:
queryId は正規化されたステートメントの符号付き 64 ビットハッシュなので、しばしば
負の値になります。単一のパターンを取得するには、先頭の - も含めて
その値をそのまま渡してください。
リストレスポンスの queryId を [低速クエリパターン API] に渡すと、その
パターンの集計メトリクスと、直近の個別実行結果を取得できます。
パターンの識別に必要な db_name、db_user、db_operation は
必須です。
レスポンスには、aggregate の下にあるリストエンドポイントと同じ集計に加えて、
recentExecutions 配列が含まれます。各実行には、実行ごとの
完全なカウンター — shared および temp block の I/O、CPU の user および system
time、並列 worker 数、JIT、WAL — が含まれます。これらは、
コンソールの
detail flyout で内訳が表示されるものと同じカウンターです。
この例では簡潔にするため、両方のオブジェクトを一部省略しています。API は
per-execution counters で説明している完全なカウンター セットを返します。