Prometheus を使用した Monitoring

このガイドでは、あらゆる環境で Vantage 3.0 セルフホスト型のメトリクスを収集するために、セルフマネージドの Prometheus を設定します。AKS で Azure Monitor Workspace と Azure Managed Grafana を利用できる場合は、同じパターンをマネージドサービスとしてデプロイする方法について、Azure Managed Monitoring を参照してください。

例では kube-prometheus-stack を使用していますが、アプローチ自体は汎用的で、どの Prometheus デプロイにも適用できます。メッシュ固有の制約については、監視の概要を参照してください。

Vantage でのメトリクス公開方法

Vantage アプリケーションの pod には OpenTelemetry SDK が組み込まれており、コンテナーポート 8080 の /metrics-text で Prometheus 形式のメトリクスを公開します。このエンドポイントを公開するサービスには abbyy.platform.metrics.text.endpoint: "1" というラベルが付いており、サービスポート (通常は 80) が、ポート名 http のコンテナーポートにマップされます。Prometheus は ServiceMonitor を介してこれらのサービスを検出し、スクレイプします。そのため、メトリクス収集用に別途 OpenTelemetry Collector を用意する必要はありません。全体像とサービスメッシュの制約については、監視の概要を参照してください。

前提条件

Vantage がインストールされ、稼働中であること (operator とワークロードがデプロイ済み) 。
Helm 3。
クラスターに対する kubectl アクセス。
KEDA が有効な場合は、prometheus-operated.observability.svc.cluster.local:9090 でアクセス可能な Prometheus インスタンス。

Prometheus を設定する

OTLP メトリクスを取り込む場合は、otlp-write-receiver 機能を有効にし、Prometheus インスタンスに --web.enable-otlp-receiver 引数を渡します (OTLP取り込みを参照) 。 Helm リポジトリを追加します:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

values ファイル (observability-values.yaml) を作成します：

prometheus:
  prometheusSpec:
    enableFeatures:
      - otlp-write-receiver
    additionalArgs:
      - name: web.enable-otlp-receiver
        value: ""
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi
grafana:
  enabled: true
  adminPassword: "changeme"  # 本番環境では必ず変更してください
  persistence:
    enabled: true
    size: 10Gi
alertmanager:
  enabled: false
nodeExporter:
  enabled: true
kube-state-metrics:
  enabled: true
# マネージドKubernetes（AKS、EKS、GKEなど）はコントロールプレーンの
# エンドポイントを公開しません。スクレイプエラーを防ぐため、これらを無効にしてください。
kubeApiServer:
  enabled: false
kubeControllerManager:
  enabled: false
kubeScheduler:
  enabled: false
kubeEtcd:
  enabled: false
kubeProxy:
  enabled: false

インストール:

helm install observability prometheus-community/kube-prometheus-stack \
  -n observability --create-namespace \
  -f observability-values.yaml

pod が起動していることを確認します:

kubectl get pods -n observability

Prometheus、Grafana、operator、kube-state-metrics、node-exporter の各 pod が実行中であることを確認してください。node-exporter は DaemonSet として実行されるため、ノードのスケーリングがまだ進行中の場合は、保留中の pod があっても正常です。

Prometheus が Vantage をスクレイプするように設定する

vantage-selfhosted チャートでは、Vantage を監視するために必要な ServiceMonitor オブジェクトを作成できます。

helm upgrade --install abbyy-vantage \
  # ...
  --set observability.prometheus.serviceMonitor.create=true

その他のオプションについては、チャートのDocumentationを参照してください。 observability キーはトップレベルに配置する必要があり、vantage の下にネストしてはいけません。

Linkerd mTLS

Linkerd の既定の permissive ポリシーでは、Prometheus は通常、Linkerd でプロキシされた Vantage エンドポイントをプレーンテキスト経由でスクレイプできます。Prometheus を observability 名前空間にインストールし、Vantage の ServiceMonitor を有効にして、すべての Vantage ターゲットが UP であることを確認してください。厳格な Linkerd 認可ポリシーによってスクレイプがブロックされる場合は、次のいずれかの方法を使用してください。

observability 名前空間で Linkerd インジェクションを有効にし、Prometheus がメッシュに参加するようにします。
observability.prometheus.serviceMonitor.scheme: https と、Linkerd の構成によって Prometheus で利用可能になるクライアント証明書を参照する tlsConfig を設定します。

ScaledObject リソースで使用される Vantage メトリクスについて、Prometheus が最新の値を返すようになるまで、KEDA を有効にしないでください。確認用クエリと準備完了チェックについては、KEDA による自動スケーリングを参照してください。

Istio mTLS

Vantage を STRICT mTLS を使用する Istio メッシュに配置する場合 (ingress.enabled が true で ingress.type が istio の場合のデフォルト設定) 、Prometheus は service 名ではなく pod IP を直接使用するため、Prometheus と `ServiceMonitor“ は mTLS 経由でエンドポイントをスクレイプするように設定する必要があります。 Prometheus pod に次のアノテーションを設定します。

annotations:
  proxy.istio.io/config: |
    proxyMetadata:
      OUTPUT_CERTS: /etc/istio-output-certs
  sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'

および、次の volume と volumeMount (名前とパスはカスタマイズ可能です。以下の例ではこれらを使用しています) :

volumes:
  - name: istio-certs
    emptyDir:
      medium: Memory
volumeMounts:
  - name: istio-certs
    mountPath: /etc/prom-certs/
    readOnly: true

kube-prometheus-stack では、次の値を使用してこれを行えます。

prometheus:
  prometheusSpec:
    podMetadata:
      annotations:
        # Istio にローカルボリュームディレクトリへの証明書生成を強制する
        "proxy.istio.io/config": |
          proxyMetadata:
            OUTPUT_CERTS: /etc/istio-output-certs
        "sidecar.istio.io/userVolumeMount": '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
    # Istio が証明書を書き込む共有ボリューム
    volumes:
      - name: istio-certs
        emptyDir: {}
    volumeMounts:
      - name: istio-certs
        mountPath: /etc/prom-certs

または、Istio の公式ドキュメントを参照してください。次に、ServiceMonitor(s) がこれらの証明書を使用するよう設定されるように、vantage-selfhosted チャートをインストールします。

# values.vantage-selfhosted.yaml
observability:
  prometheus:
    serviceMonitor:
      scheme: https
      tlsConfig:
        caFile: /etc/prom-certs/root-cert.pem
        certFile: /etc/prom-certs/cert-chain.pem
        keyFile: /etc/prom-certs/key.pem
        insecureSkipVerify: true  # PrometheusはIstioのセキュリティ命名をサポートしていないため、ターゲットpodの証明書の検証をスキップする

メトリクスが送信されていることを確認する

Prometheus UI にポートフォワードします:

kubectl port-forward -n observability svc/observability-kube-prometheus-prometheus 9090:9090

Vantage のターゲットが検出され、正常に稼働していることを確認します:

curl -s http://localhost:9090/api/v1/targets \
  | jq '[.data.activeTargets[] | select(.scrapePool // "" | contains("vantage"))] | group_by(.health) | map({health: .[0].health, count: length})'

Vantage アプリケーションのメトリックを照会します:

curl -s "http://localhost:9090/api/v1/query?query=process_cpu_count" \
  | jq '.data.result | length'

結果が 0 以外であれば、メトリクスがスクレイプされていることを示します。http://localhost:9090/targets にアクセスすると、各ターゲットのスクレイプステータスも確認できます。

Grafana にアクセスする

kubectl port-forward -n observability svc/observability-grafana 3000:80

http://localhost:3000 を開きます。デフォルトの認証情報は、admin と values ファイルで設定したパスワードです。Prometheus はデータソースとして事前に設定されています。

利用可能なメトリクス

Vantage アプリケーションは、OpenTelemetry SDK を介して、プロセス、HTTP クライアント/サーバー、および ABBYY プラットフォームのメトリクスを公開します。これらにはすべて、service、pod、namespace、otel_scope_name のラベルが付与されています。全メトリクスの一覧については、利用可能なメトリクスを参照してください。

OTLP取り込み

OTLP取り込みはプッシュベースで、上記のスクレイプベースの ServiceMonitor フローとは独立しています。スクレイプエンドポイントを公開するサービスではなく、OpenTelemetry メトリクスをプッシュするサービスにのみ使用してください。

Prometheus で OTLP レシーバーを有効にして構成している場合 (--web.enable-otlp-receiver) 、HTTP 経由で OTLP メトリクスをプッシュするサービスであれば、どれでもそれらを次の宛先に送信できます。

http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics

​Vantage でのメトリクス公開方法

​前提条件

​Prometheus を設定する

​Prometheus が Vantage をスクレイプするように設定する

​Linkerd mTLS

​Istio mTLS

​メトリクスが送信されていることを確認する

​Grafana にアクセスする

​利用可能なメトリクス

​OTLP取り込み

Vantage でのメトリクス公開方法

前提条件

Prometheus を設定する

Prometheus が Vantage をスクレイプするように設定する

Linkerd mTLS

Istio mTLS

メトリクスが送信されていることを確認する

Grafana にアクセスする

利用可能なメトリクス

OTLP取り込み