第2章 GraphQL API

GraphQL API エンドポイントである /api/v2.2/graphql は、ターゲット JVM に対してより短くて単純なクエリーを自動的に実行します。これらのクエリーは、ターゲット JVM のアクティブおよびアーカイブされたレコーディングに対して実行することができます。さらに、API は一般的な Cryostat アーカイブに対してクエリーを実行できます。クエリーをカスタマイズして、アクティブまたはアーカイブされたレコーディングの以下のタスクを自動化できます。

クエリーをカスタマイズして、アクティブまたはアーカイブされたレコーディングの以下のタスクを自動化できます。

カスタムクエリーを作成する場合、クエリーに GraphQL API エンドポイントの具体的な情報を指定する必要があります。続いて、POST リクエストで情報を処理し、その情報を Cryostat に送信することができます。次の例では、Graph QL API の情報を指定します。

POST /api/beta/graphql HTTP/1.1
Accept: application/json, /;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 171
Content-Type: application/json
Host: localhost:8181
User-Agent: HTTPie/3.1.0

GraphQL API は、ワークロード機能が制限されている HTTP REST API よりも強力です。たとえば、HTTP REST API では、OpenShift 上のコンテナー内にあるスケーリングされた各レプリカで開始するレコーディングのコピーごとに、API リクエストを作成する必要があります。GraphQL API は、1 つの API 要求でこのタスクを実現できます。これにより、API のパフォーマンスが向上し、Cryostat インスタンスのネットワークトラフィックを削減できます。

HTTP REST API のもうひとつの制限されたワークロード機能として、この API は、応答データに対して反復的なアクションを実行する際に API JSON 応答を解析するカスタムクライアントを書く必要があるなど、ユーザーの介入をより必要とすることが挙げられます。GraphQL API では、この操作を完了する必要はありません。

$ https :8181/api/v1/targets
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 223
content-type: application/json

 {
	targetNodes {
    		name
    		nodeType
    		labels
    		target {
        		alias
        		serviceUri
    		}
	}
}

$ https -v :8181/api/v2.2/graphql query=@graphql/target-nodes-query.graphql
POST /api/v2.2/graphql HTTP/1.1
Accept: application/json, /;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 171
Content-Type: application/json
Host: localhost:8181
User-Agent: HTTPie/2.6.0

 {
environmentNodes(filter: { name: "<application_pod_name>" }) {
    		descendantTargets {
        		doStartRecording(recording: {
            		name: "myrecording",
            	template: "Profiling",
            	templateType: "TARGET",
     		       	duration: 30
          	 	}) {
          			name
          			state
        		}
    		}
	}
}