ClickHouse OpenAPI を使用すると、
ClickHouse サービスと同様に ClickHouse Managed Postgres サービスをプログラムから
操作できます。同じ API では、サービスのメトリクスをスクレイピングするための
Prometheus エンドポイント も公開されています。
すでに OpenAPI に慣れている場合は、API キー を取得して
ClickHouse 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ヘッダーの内容が必要です。レスポンスを保存してください。serviceの
認証情報が含まれるのはこのレスポンスだけです (リクエストでpasswordを指定しない場合、password reset のレスポンスでも返されます) :
成功すると、新しいインスタンスが作成され、その情報
(接続情報を含む) が返されます:
レスポンスの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 つあり、ClickHouse 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 に記載されている完全なカウンター セットを返します。
Cloud Console のログビューアで表示される PostgreSQL サーバーログは、
プログラムからも利用できます。logs API は、指定した期間内のサービスの個々のログエントリを
返します。クエリインサイトと同様に、この期間の指定は必須のため、
from_date と to_date を RFC 3339 形式のタイムスタンプとして渡します。期間は
30 日を超えることはできず、to_date は from_date より後でなければなりません。
エントリは新しい順に返されます。sort_order (asc または
desc) で順序を反転できます。severity (例: ERROR、
WARNING、LOG) で単一の重大度に絞り込み、body_contains で
ログボディ内の大文字・小文字を区別する部分文字列を検索し、limit と offset で
結果をページングできます。
各エントリには timestamp、severity、生データの body が含まれます。ボディは
常に文字列です。構造化ログ行は JSON エンコードされて返され、プレーンな行は
そのまま返されます。
エンドポイントでは合計件数を返すのではなく、limit と offset を使用してページ分割します。
ページが limit 未満のエントリを返すまで、offset を増やしてください。