2.3. 操作のトラブルシューティング

本セクションでは、OpenShift で表示するために 3scale 監査ロギングを設定する方法と、OpenShift で 3scale ログおよびジョブキューにアクセスする方法を説明します。

2.3.1. OpenShift での 3scale 監査ロギングの設定

この設定により、すべてのログが 1 箇所に集約され、Elasticsearch、Fluentd、および Kibana (EFK) ロギングツールでクエリーすることができます。これらのツールにより、3scale の設定にいつ誰がどのような変更を加えたかについての可視性が向上します。たとえば、これには、請求、アプリケーションプラン、API 設定などへの変更が含まれます。

前提条件

  • 3scale 2.11 デプロイメント

手順

すべてのアプリケーションログを標準の OpenShift Pod ログに転送するように、監査ロギングを stdout に設定します。

留意事項

  • 3scale がオンプレミスでデプロイされる場合、デフォルトでは stdout への監査ログの送付は無効です。この機能が完全に動作するように設定する必要があります。
  • ホスト型 3scale では、stdout への監査ログの送付を利用することはできません。

2.3.2. 監査ロギングの有効化

3scale は、features.yml 設定ファイルを使用して、一部のグローバル機能を有効にします。stdout への監査ログの送付を有効化するには、このファイルを ConfigMap からマウントして、デフォルトのファイルと置き換える必要があります。features.yml に依存する OpenShift Pod は、system-app および system-sidekiq です。

前提条件

  • OpenShift でのクラスター管理者アクセス権限がある。

手順

  1. 以下のコマンドを入力して、stdout への監査ログの送付を有効にします。 

    oc patch configmap system -p '{"data": {"features.yml": "features: &default\n  logging:\n    audits_to_stdout: true\n\nproduction:\n  <<: *default\n"}}'

  2. 以下の環境変数をエクスポートします。 

    export PATCH_SYSTEM_VOLUMES='{"spec":{"template":{"spec":{"volumes":[{"emptyDir":{"medium":"Memory"},"name":"system-tmp"},{"configMap":{"items":[{"key":"zync.yml","path":"zync.yml"},{"key":"rolling_updates.yml","path":"rolling_updates.yml"},{"key":"service_discovery.yml","path":"service_discovery.yml"},{"key":"features.yml","path":"features.yml"}],"name":"system"},"name":"system-config"}]}}}}'

  3. 以下のコマンドを入力して、更新されたデプロイメント設定を関連する OpenShift Pod に適用します。 

    oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES
oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES

2.3.3. EFK ロギングの設定

stdout への監査ログの送付を有効にして 3scale アプリケーションログが OpenShift に転送されるようになったら、EFK ロギングツールを使用して 3scale アプリケーションを監視することができます。

OpenShift での EFK ロギングの設定方法については、以下のドキュメントを参照してください。

2.3.4. ログへのアクセス

各コンポーネントのデプロイメント設定には、アクセスと例外のログが含まれます。デプロイメントで問題が発生した場合には、これらのログで詳細を確認してください。

3scale のログにアクセスするには、以下の手順に従います。

手順

  1. ログを必要とする Pod の ID を確認します。 

    oc get pods

  2. oc logs と選択した Pod の ID を入力します。 

    oc logs <pod>

    システム Pod にはコンテナーが 2 つあり、それぞれに別個のログがあります。コンテナーのログにアクセスするには、--container パラメーターで system-provider と system-developer Pod を指定します。 

    oc logs <pod> --container=system-provider
oc logs <pod> --container=system-developer

2.3.5. ジョブキューの確認

ジョブキューには、system-sidekiq Pod から送られる情報のログが含まれます。これらのログを使用して、クラスターがデータを処理しているかどうかを確認します。OpenShift CLI を使用してログを照会することができます。 

oc get jobs
oc logs <job>

2.3.6. 単調増加の防止

単調増加を防止するために、3scale はデフォルトで以下のテーブルの自動パージをスケジュールします。

  • user_sessions: クリーンアップは週 1 回トリガーされ、2 週間より前のレコードを削除します。
  • audits: クリーンアップは 1 日 1 回トリガーされ、3 カ月より前のレコードを削除します。
  • log_entries: クリーンアップは 1 日 1 回トリガーされ、6 カ月より前のレコードを削除します。
  • event_store_events: クリーンアップは週 1 回トリガーされ、1 週間より前のレコードを削除します。

以下の表は例外で、データベース管理者が手動でパージする必要があります。

  • alerts

表2.1 SQL パージコマンド

データベースタイプSQL コマンド

MySQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL 14 DAY;

PostgreSQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL '14 day';

Oracle 

DELETE FROM alerts WHERE timestamp <= TRUNC(SYSDATE) - 14;

本セクションで説明しない他のテーブルについては、データベース管理者は、システムで自動的にパージされないテーブルを手動でクリーンアップする必要があります。

関連情報