原文はこちら。
https://blogs.oracle.com/weblogicserver/using-prometheus-to-automatically-scale-weblogic-clusters-on-kubernetes-v5
WebLogic Serverクラスタの弾力性(スケールアップまたはスケールダウン)は、需要に基づいてリソースを管理できる利点をもたらし、リソースコストを管理しながらお客様のアプリケーションの信頼性を向上させます。Kubernetes環境でWebLogic Serverクラスタの自動スケーリングをトリガする方法にはいくつかありますが、WebLogic Server Elasticityコンポーネントのアーキテクチャと、WebLogic診断フレームワーク(WLDF)ポリシーを使用してWebLogicクラスタをスケールアップする方法の詳細は、「Automatic Scaling of WebLogic Clusters on Kubernetes」のブログエントリをご覧ください。
Kubernetes環境のPodで実行されているすべてのコンポーネントを下図で示しています。
Kubernetesクラスタで動作するWebLogicドメインは以下を構成要素としています。
create-operator-inputs.yaml
create-domain-job-inputs.yaml
以前のブログエントリでは、クラスタで実行されている管理対象サーバにWebLogic Monitoring Exporterをデプロイして、Kubernetes環境のWebLogic Serverインスタンスの起動、実行方法をご紹介しました。
DockerClusterの外部アクセス用NodePortを確認します。
To make sure that the WebLogic Monitoring Exporterがデプロイされ、実行中であることを確認するため、以下のURLを使ってアプリケーションにアクセスします。
Promethus Alertmanagerで設定したいアラートルールがWebLogic Exporterで構成済みのメトリックと一致することを確認しましょう。以下は今回使用したアラートルールの例です。
WebLogic Kubernetes Operatorのデプロイで利用する weblogic-operator.yaml に含まれるプロパティinternalOperatorCertの値で webhook-deployment.yaml ファイルのプロパティINTERNAL_OPERATOR_CERTを更新します。
webhook、Prometheus、Alertmanagerを起動し、管理対象サーバインスタンスを監視します。
http://[ hostname ]:32000にアクセスし、Prometheusが全管理対象サーバを監視していることを確認しましょう。
Insert metric at cursor プルダウンメニューを確認しましょう。WebLogic Monitoring Exporter webアプリケーションの現在の構成に基づいたメトリック名が並んでいるはずです。
http://[hostname]:32000/alertsにアクセスしてPrometheus Alert Settingを確認できます。
prometheus-deployment.yaml 構成ファイルに並べた構成済みのルールが表示されているはずです。
今回のサンプルファイルの構成の場合、初期時点では2個の管理対象サーバPodのみを起動しました。現在実行中の全Podをチェックしましょう。
今回のAlert Ruleの構成では、クラスタでtestwebappというアプリケーションに対するセッションの個数が15を超える場合スケールアップが発生します。curl.shwアプリケーションURLを17回呼び出してみましょう。Let’s invoke the application URL 17 times using curl.sh :
AlertmanagerがHTTP POSTでwebhookに送信したことを確認するには、以下のwebhook Podのログを確認します。
webhookのエンドポイントが呼び出されると、execute-commandプロパティで指定されたコマンドが呼び出されます。今回の場合、該当するコマンドは/var/scripts/scaleUpAction.shです。scaleUpAction.shスクリプトはWebLogic Kubernetes Operatorが提供するscalingAction.shスクリプトへのパラメータを渡します。scalingAction.shスクリプトはOperator Server REST URLに対しスケールのリクエストを発行します。
スケールアップ(訳注:本来スケールアウトですが、原文に従っています)操作を確認するには、実行中の管理対象サーバのPodの個数を確認します。3個の実行中Podに増えているはずです。
https://blogs.oracle.com/weblogicserver/using-prometheus-to-automatically-scale-weblogic-clusters-on-kubernetes-v5
WebLogic Serverクラスタの弾力性(スケールアップまたはスケールダウン)は、需要に基づいてリソースを管理できる利点をもたらし、リソースコストを管理しながらお客様のアプリケーションの信頼性を向上させます。Kubernetes環境でWebLogic Serverクラスタの自動スケーリングをトリガする方法にはいくつかありますが、WebLogic Server Elasticityコンポーネントのアーキテクチャと、WebLogic診断フレームワーク(WLDF)ポリシーを使用してWebLogicクラスタをスケールアップする方法の詳細は、「Automatic Scaling of WebLogic Clusters on Kubernetes」のブログエントリをご覧ください。
Automatic Scaling of WebLogic Clusters on Kubernetesこのデモでは、Kubernetes上のWebLogicクラスタを自動的に拡張する別の方法、つまりPrometheusを使用する方法をご紹介します。Prometheusは利用可能なすべてのWebLogicメトリクスデータにアクセスできるため、ユーザはメトリックを使ってスケーラビリティのためのルールを指定できます。収集されたメトリックデータと設定されたアラートルールの条件に基づいて、PrometheusのAlertmanagerは、アラートを送信して、WebLogic Serverクラスタ内で実行中の管理対象サーバの数を変更します。
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
https://orablogs-jp.blogspot.com/2018/01/automatic-scaling-of-weblogic-clusters.html
PrometheusWebLogic Monitoring Exporterを使用して、特定のWebLogic Serverインスタンスの実行時メトリックを取得しPrometheusに流します。
https://prometheus.io/
Prometheus Alertmanager
https://prometheus.io/docs/alerting/alertmanager/
WebLogic Monitoring Exporterまた、スケーリングアラートイベントが発生したときに呼び出されるユーザー定義のRESTサービスであるwebhookレシーバーを使用して、カスタム通知の統合を実装します。
https://github.com/oracle/weblogic-monitoring-exporter
webhook_configアラートルールが指定された条件に一致すると、Prometheus Alert Managerは、スケーリングアクションを要求するwebhookとして指定されたURLにHTTPリクエストを送信します。このサンプルデモで使用しているwebhookの詳細については、以下のリンクを参照ください。
https://prometheus.io/docs/alerting/configuration/#webhook_config
adnanh/webhookこのブログでは、Kubernetesクラスタで動作するWebLogic Serverインスタンスの自動スケーリングを実行するために、Prometheus、Prometheus Alertmanager、Webhookを構成する方法を学習します。
https://github.com/adnanh/webhook/
Kubernetes環境のPodで実行されているすべてのコンポーネントを下図で示しています。
Kubernetesクラスタで動作するWebLogicドメインは以下を構成要素としています。
- 管理サーバ(AS)インスタンスはDockerコンテナで動作し、独自のPod(POD1)を持つ。
- WebLogic Serverクラスタは管理対象サーバインスタンスで構成されており、各インスタンスはDockerコンテナで動作し、それぞれ独自のPod(POD2~POD5)を持つ。
- WebLogic Monitoring Exporter WebアプリケーションはWebLogic Serverクラスタにデプロイされている。
- Prometheus
- Prometheus Alert Manager
- WebLogic Kubernetes Operator
- Webhookサーバ
Installation and Deployment of the Components in the Kubernetes Cluster
インストール手順に従い、WebLogic Kubernetes Operatorおよびドメインを作成します。このエントリでは、以下のパラメータを使ってWebLogic Kubernetes OperatorとWebLogicドメインを作成します。Installation - WebLogic Kubernetes Operator1. WebLogic Kubernetes Operatorのデプロイ( create-weblogic-operator.sh )
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/installation.md
create-operator-inputs.yaml
2. ドメインの作成ならびに開始 ( create-domain-job.sh )serviceAccount: weblogic-operator
targetNamespaces: domain1
namespace: weblogic-operator
weblogicOperatorImage: container-registry.oracle.com/middleware/weblogic-kubernetes-operator:latest
weblogicOperatorImagePullPolicy: IfNotPresent
externalRestOption: SELF_SIGNED_CERT
externalRestHttpsPort: 31001
externalSans: DNS:slc13kef
externalOperatorCert:
externalOperatorKey:
remoteDebugNodePortEnabled: false
internalDebugHttpPort: 30999
externalDebugHttpPort: 30999
javaLoggingLevel: INFO
create-domain-job-inputs.yaml
3. 以下のコマンドを実行してコンソールにアクセスするための管理NodePortを識別するdomainUid: domain1
managedServerCount: 4
managedServerStartCount: 2
namespace: weblogic-domain
adminPort: 7001
adminServerName: adminserver
startupControl: AUTO
managedServerNameBase: managed-server
managedServerPort: 8001
weblogicDomainStorageType: HOST_PATH
weblogicDomainStoragePath: /scratch/external-domain-home/pv001
weblogicDomainStorageReclaimPolicy: Retain
weblogicDomainStorageSize: 10Gi
productionModeEnabled: true
weblogicCredentialsSecretName: domain1-weblogic-credentials
exposeAdminT3Channel: true
adminNodePort: 30701
exposeAdminNodePort: true
namespace: weblogic-domain
loadBalancer: TRAEFIK
loadBalancerWebPort: 30305
loadBalancerDashboardPort: 30315
下図にあるweblogic-domainは、WebLogicドメインPodがデプロイされている名前空間です。kubectl -n weblogic-domain describe service domain1-adminserver
以前のブログエントリでは、クラスタで実行されている管理対象サーバにWebLogic Monitoring Exporterをデプロイして、Kubernetes環境のWebLogic Serverインスタンスの起動、実行方法をご紹介しました。
Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes以下のURLでWebLogic Server管理コンソールにアクセスします(資格証明はweblogic/welcome1)。
https://blogs.oracle.com/weblogicserver/use-prometheus-and-grafana-to-monitor-weblogic-server-on-kubernetes
https://orablogs-jp.blogspot.com/2017/12/using-prometheus-and-grafana-to-monitor.html
http://[hostname]:30701/consoleこの例では、testwebapp.warというwebアプリケーションが開いたセッションの個数を基にしてアラートルールを設定します。
bhabermaas/kubernetes-projects/testwebapp.warDeploy the testwebapp.warアプリケーションと、WebLogic Monitoring Exporter(wls-exporter.war)をDockerClusterにデプロイします。
https://github.com/bhabermaas/kubernetes-projects/blob/master/apps/testwebapp.war
bhabermaas/kubernetes-projects/wls-exporter.war
https://github.com/bhabermaas/kubernetes-projects/blob/master/apps/wls-exporter.war
DockerClusterの外部アクセス用NodePortを確認します。
kubectl -n weblogic-domain describe service domain1-dockercluster-traefik
To make sure that the WebLogic Monitoring Exporterがデプロイされ、実行中であることを確認するため、以下のURLを使ってアプリケーションにアクセスします。
http://[ hostname ]:30305/wls-exporter/metricsメトリックデータにアクセスするために必要なWebLogicユーザーの資格証明を求められるので、weblogic/welcome1を入力します。メトリックページはWebLogic Monitoring Exporter用に構成されたメトリックを表示します。
Promethus Alertmanagerで設定したいアラートルールがWebLogic Exporterで構成済みのメトリックと一致することを確認しましょう。以下は今回使用したアラートルールの例です。
ここで利用したメトリック ‘webapp_config_open_sessions_current_count’ は、メトリックのWebページに表示されている必要があります。if sum(webapp_config_open_sessions_current_count{webapp=”testwebapp”) > 15 ;
Setting Up the Webhook for Alert Manager
この例では、webhookアプリケーションを使いました。bhabermaas/kubernetes-projectsDockerイメージ構築のため、以下のディレクトリ構造を作成します。
https://github.com/bhabermaas/kubernetes-projects/tree/master/apps
- apps
- scripts
- webhooks
scalingAction.shscriptsディレクトリでscaleUpAction.shファイルを作成し、以下のコードをペーストします。
https://github.com/oracle/weblogic-kubernetes-operator/blob/master/src/scripts/scaling/scalingAction.sh
2. Create a Docker file for the webhook用のDockerファイル(Docker.webhook)を以下のように作成します。#!/bin/bash
echo scale up action >> scaleup.log
MASTER=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT
echo Kubernetes master is $MASTER
source /var/scripts/scalingAction.sh --action=scaleUp --domain_uid=domain1 --cluster_name=DockerCluster --kubernetes_master=$MASTER --wls_domain_namespace=domain1
3. hooks.json ファイルをwebhooksディレクトリを作成します。以下はその例です。FROM store/oracle/serverjre:8
COPY apps/webhook /bin/webhook
COPY webhooks/hooks.json /etc/webhook/
COPY scripts/scaleUpAction.sh /var/scripts/
COPY scripts/scalingAction.sh /var/scripts/
CMD ["-verbose", "-hooks=/etc/webhook/hooks.json", "-hotreload"]
ENTRYPOINT ["/bin/webhook"]
4. ‘webhook’ Dockerイメージを作成します。[
{
"id": "scaleup",
"execute-command": "/var/scripts/scaleUpAction.sh",
"command-working-directory": "/var/scripts",
"response-message": "scale-up call ok\n"
}
]
docker rmi webhook:latest
docker build -t webhook:latest -f Dockerfile.webhook .
Deploying Prometheus, Alert Manager, and Webhook
Prometheus、Alertmanagerとwebhook Podをmonitoringという名前空間で実行します。以下のコマンドを実行して、monitoringという名前空間を作成します。PrometheusインスタンスをKubernetesにデプロイするために、 prometheus-kubernetes.yml というPrometheusの構成ファイルを作成します。サンプルファイルは以下のURLから入手できます。kubectl create namespace monitoring
prometheus-deployment.yamlPrometheus構成ファイルのサンプルでは、以下の情報を設定しています。
https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/prometheus-deployment.yaml
- ユーザー資格証明(weblogic/welcome1)
- WebLogic Serverのメトリックアップデート間隔(5秒)
- Prometheusダッシュボードアクセスのための外部ポート(32000)
- スケーリング・ルール
- Alertmanagerは9093/tcpをリスニングするよう構成
ALERT scaleup if sum(webapp_config_open_sessions_current_count{webapp=”testwebapp”}) > 15 ANNOTATIONS { summary = "Scale up when current sessions is greater than 15", description = "Firing when total sessions active greater than 15" }
QUERYING PROMETHEUSアラートを生成するには、Prometheus AlertmanagerをDockerコンテナで動作する別のPodとしてデプロイする必要があります。サンプルとして提供しているPrometheus Alertmanagerの構成ファイルでは、webhookを利用しています。
https://prometheus.io/docs/querying/basics/
alertmanager-deployment.yaml
https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/alertmanager-deployment.yaml
WebLogic Kubernetes Operatorのデプロイで利用する weblogic-operator.yaml に含まれるプロパティinternalOperatorCertの値で webhook-deployment.yaml ファイルのプロパティINTERNAL_OPERATOR_CERTを更新します。
webhook-deployment.yaml以下はその例です。
https://github.com/bhabermaas/kubernetes-projects/blob/master/kubernetes/webhook-deployment.yaml
webhook、Prometheus、Alertmanagerを起動し、管理対象サーバインスタンスを監視します。
全てのPodが起動したことを確認しましょう。kubectl apply -f alertmanager-deployment.yaml
kubectl apply –f prometheus-deployment.yaml
kubectl apply –f webhook-deployment.yaml
http://[ hostname ]:32000にアクセスし、Prometheusが全管理対象サーバを監視していることを確認しましょう。
Insert metric at cursor プルダウンメニューを確認しましょう。WebLogic Monitoring Exporter webアプリケーションの現在の構成に基づいたメトリック名が並んでいるはずです。
http://[hostname]:32000/alertsにアクセスしてPrometheus Alert Settingを確認できます。
prometheus-deployment.yaml 構成ファイルに並べた構成済みのルールが表示されているはずです。
Auto Scaling of WebLogic Clusters in K8s
このデモでは、2個の実行中の管理対象サーバをもつよう各WebLogic Serverクラスタを構成し、管理対象サーバの個数がちょうど4になるようにしました。configuredManagedServerCount と initialManagedServerReplicas という、create-domain-job-inputs.yamlファイルに含まれるこれらのパラメータを変更し、クラスタ内で実行する管理対象サーバの所望の個数と、許容するレプリカの最大個数を反映することができます。今回のサンプルファイルの構成の場合、初期時点では2個の管理対象サーバPodのみを起動しました。現在実行中の全Podをチェックしましょう。
今回のAlert Ruleの構成では、クラスタでtestwebappというアプリケーションに対するセッションの個数が15を超える場合スケールアップが発生します。curl.shwアプリケーションURLを17回呼び出してみましょう。Let’s invoke the application URL 17 times using curl.sh :
コマンドを発行します。#!/bin/bash
COUNTER=0
MAXCURL=17
while [ $COUNTER -lt $MAXCURL ]; do
OUTPUT="$(curl http:/$1:30305/testwebapp/)"
if [ "$OUTPUT" != "404 page not found" ]; then
echo $OUTPUT
let COUNTER=COUNTER+1
sleep 1
fi
done
testwebappアプリケーションに対するセッションの合計が15を超えると、PrometheusはAlertmanagerを通じてアラートを発生します。現在のアラートの状態をhttp://[hostname]:32000/alertにアクセスして確認できます。. ./curl.sh [hostname]
AlertmanagerがHTTP POSTでwebhookに送信したことを確認するには、以下のwebhook Podのログを確認します。
webhookのエンドポイントが呼び出されると、execute-commandプロパティで指定されたコマンドが呼び出されます。今回の場合、該当するコマンドは/var/scripts/scaleUpAction.shです。scaleUpAction.shスクリプトはWebLogic Kubernetes Operatorが提供するscalingAction.shスクリプトへのパラメータを渡します。scalingAction.shスクリプトはOperator Server REST URLに対しスケールのリクエストを発行します。
スケールアップ(訳注:本来スケールアウトですが、原文に従っています)操作を確認するには、実行中の管理対象サーバのPodの個数を確認します。3個の実行中Podに増えているはずです。