MicroProfile メトリックを使用したモニタリング

mpMetrics-1.0 フィーチャーまたは mpMetrics-1.1 フィーチャーを使用して、MicroProfile Metrics API で計測されるアプリケーションをモニターできます。 mpMetrics-1.0 フィーチャーおよび mpMetrics-1.1 フィーチャーは、 MicroProfile Metrics 1.0 仕様または MicroProfile metrics 1.1 仕様に準拠する /metrics REST インターフェースを提供します。アプリケーション開発者は、Liberty で提供されるメトリックと共に、独自のカスタム・メトリックを MicroProfile Metrics API を使用して追加できます。

MicroProfile Metrics フィーチャー・バージョン 2.0 以降の資料は、 Open Liberty Web サイトで入手できます。

始めに

MicroProfile メトリック 1.0 仕様を参照するには、 Metrics for Eclipse MicroProfile 1.0 仕様を参照してください。

MicroProfile メトリック 1.1 仕様を参照するには、 Metrics for Eclipse MicroProfile 1.1 仕様を参照してください。

手順

MicroProfile メトリックを使用したモニタリングをセットアップします。
1. フィーチャーを構成します。 server.xml ファイル内のフィーチャー・マネージャーに mpMetrics-1.0 または mpMetrics-1.1 フィーチャーを追加します。
  mpMetrics-1.0 フィーチャーまたは mpMetrics-1.1 フィーチャーを使用すると、オプションで、認証を使用して REST API を保護できます。デフォルトの構成では、認証を使用して REST API をセキュアにします。セキュア認証が無効になっている場合、メトリック REST エンドポイントは HTTP のみに制限されず、まだ HTTPS プロトコルを介してアクセスできます。次の例は、基本的なセキュリティーのセットアップを示しています。 MicroProfile メトリックは、デフォルトの鍵ストアを使用してエンドポイントを保護します。
```
<featureManager>
  <feature>mpMetrics-1.0</feature>                  
</featureManager>

<quickStartSecurity userName="theUser" userPassword="thePassword"/>
<keyStore id="defaultKeyStore" password="Liberty"/>
```
  次の例は、セキュリティーなしの構成を示しています。
```
<featureManager>
  <feature>mpMetrics-1.1</feature>                  
</featureManager>

<mpMetrics authentication="false"/>
```
2. /metricsからのデータをモニターするためのモニター・ツールをセットアップします。
  
  /metrics への要求に対する応答のデフォルト・フォーマットは、Prometheus と互換のテキスト・フォーマットです。 /metrics への要求で accept ヘッダーが application/json の場合、応答は JSON 出力フォーマットで提供されます。 MicroProfile Metrics REST APIを参照してください。
3. オプション: mpMetrics-1.1 フィーチャーと mpFaultTolerance-1.1 フィーチャーを一緒に使用します。
  
  フォールト・トレランス・アノテーションを使用してアノテーションを付けた各メソッドに対して、メトリックが自動的に提供されます。提供されるメトリックは、使用するフォールト・トレランス・アノテーションによって異なります。詳しくは、 Fault Tolerance 1.1 仕様を参照してください。
メトリック API へのアクセスを許可します。
1. ユーザーまたはユーザー・グループにメトリック API へのアクセスを許可するには、構成済みのユーザー・レジストリーからユーザーまたはグループに administrator 役割をマップします。
  
  メトリック API は、 Liberty administrator ロールによって保護されます。
  以下の例では、構成済みのユーザー・レジストリー内のユーザー Bob と、構成済みのユーザー・レジストリー内のグループ AuthorizedGroup が API にアクセスできるようにするためのサンプル構成を示します。
```
<basicRegistry id="basic" realm="WebRealm">
    <user name="bob" password="bobpwd" />
    <user name="alice" password="alicepwd" />
    <user name="carl" password="carlpwd" />

    <group name="AuthorizedGroup">
        <member name="alice" />
    </group>
</basicRegistry>

 <administrator-role>
     <user>bob</user>
     <group>AuthorizedGroup</group>
 </administrator-role>
```
2. 認証が OpenID Connect や SAML などのシングル・サインオン・サービスによって実行される場合、または JSON Web Token (JWT) などの検証可能なセキュリティー・トークンによって認証される場合は、ユーザー名またはグループ名の代わりに administrator 役割をユーザーまたはグループ access-id にマップします。
```
 <administrator-role>
     <user-access-id>user:https://idp.example.com/bob</user-access-id>
     <group-access-id>group:https://idp.example.com/ManagingGroup</group-access-id>
 </administrator-role>
```

例

以下の例では、クライアントは MicroProfile JWT を使用して認証されます。ユーザー・プリンシパル名 (upn) クレームは tom@example.com、発行者 (iss) クレームは https://idp.example.com であり、グループ・クレームには ManagingGroup が含まれています。

{
  ...
  "sub": "tom",
  "upn": "tom@example.com",
  "groups": [
    "admin"
  ],
  "iss": "https://idp.example.com",
  ...
}

以下の例は、 administrator role を JWT 内のサブジェクトにマップするための 2 つの異なるサンプル構成を示しています。

<user-access-id>を使用して administrator role を JWT 内のサブジェクトにマップするには、以下の構成を使用します。

 <administrator-role>
     <user-access-id>user:https://idp.example.com/tom@example.com</user-access-id>
  </administrator-role>

<group-access-id>を使用して administrator role を JWT 内のサブジェクトにマップするには、以下の構成を使用します。

 <administrator-role>
     <group-access-id>group:https://idp.example.com/admin</group-access-id>
  </administrator-role>

administrator ロールのマッピングについて詳しくは、 Liberty の管理者ロールのマッピングを参照してください。