OpenShift 上の JBoss EAP の統計情報を Prometheus で確認する
結構苦労したのですが、自分のOpenShift local 環境で JBoss EAP の統計情報を Prometheus で確認した際の作業メモを整理します。 設定手順としての一例になるかと思いますので参考になれば幸いです。
事前準備
- 任意のプロジェクトを作成します。
oc new-project eapdemo
- テンプレートを取り込みます。
oc_project="$(oc project -q)"
for resource in \
eap74-basic-s2i.json
do
oc -n "$oc_project" create -f \
https://raw.githubusercontent.com/jboss-container-images/jboss-eap-openshift-templates/eap74/templates/${resource}
done
JBoss EAP 環境の用意
- eap74-basic-s2i テンプレートを利用しながら QuickStarts の kitchensink アプリをデプロイします。（時間が掛かるので暫く待機します）
（補足）最後の2行で JBoss EAP の統計情報を取得する機能を有効にしています。この定義によって 9799 Port を用いた JMX Exporter が動作します。
oc new-app --template=eap74-basic-s2i \
-p IMAGE_STREAM_NAMESPACE=openshift \
-p SOURCE_REPOSITORY_URL="https://github.com/jboss-developer/jboss-eap-quickstarts" \
-p SOURCE_REPOSITORY_REF=openshift \
-p CONTEXT_DIR=kitchensink \
-e AB_PROMETHEUS_ENABLE=true \
-e JAVA_OPTS_APPEND=-Dwildfly.statistics-enabled=true
wildfly.statistics-enabled = true
java.class.path = /opt/eap/jboss-modules.jar:/opt/jboss/container/jolokia/jolokia.jar:/opt/jboss/container/prometheus/jmx_prometheus_javaagent.jar
- kitchensink アプリが動作することを確認します。
JBoss EAP の統計情報を監視するための設定
- 9799 ポートを利用した JMX Exporter 用 Service を登録します。
oc apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
labels:
app: monitor_sample
name: eap-app-metrics
namespace: "$oc_project"
spec:
selector:
deploymentConfig: eap-app
ports:
- name: metrics
port: 9799
protocol: TCP
targetPort: 9799
EOF
- OpenShift のモニター機能を有効にするために ConfigMap を作成します。
（補足） cluster-monitoring-config が存在しない場合は、edit の代わりに create を実行します。
oc -n openshift-monitoring edit configmap cluster-monitoring-config
- 以下のように
enableUserWorkload: true定義を追加し、保存します。
apiVersion: v1
data:
config.yaml: |
enableUserWorkload: true
- 上記設定を実施後にモニター機能を処理する各 Pod が起動していることを確認します。
（補足）環境によって prometheus-user-workload-1 や thanos-ruler-user-workload-1 が存在することがあります。
$ oc -n openshift-user-workload-monitoring get pod
NAME READY STATUS RESTARTS AGE
prometheus-operator-c7bdc5c48-49lhp 2/2 Running 8 8d
prometheus-user-workload-0 6/6 Running 24 8d
thanos-ruler-user-workload-0 3/3 Running 22 (3h6m ago) 8d
- 利用しているユーザーへロールを付与します。
（補足）ユーザー名は適宜変更してください。
oc policy add-role-to-user monitoring-rules-view <<ユーザー名>> -n "$oc_project"
oc policy add-role-to-user monitoring-rules-edit <<ユーザー名>> -n "$oc_project"
oc policy add-role-to-user monitoring-edit <<ユーザー名>> -n "$oc_project"
- ServiceMonitor 定義を登録します。
（補足）Service 登録時に定義したラベルapp: monitor_sampleを指定し、モニター対象の Service を特定する（マッチングする）ことが重要となります。
oc apply -f - << EOF
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: monitor
namespace: "$oc_project"
spec:
endpoints:
- port: metrics
selector:
matchLabels:
app: monitor_sample
EOF
JBoss EAP の統計情報を確認
- OpenShift の Web コンソールへログインし、Administrator パースペクティブへ切り替え、[監視] -> [ターゲット] メニューへ遷移します。
- 指定した ServiceMonitor 名と Namespace で以下のような一覧が出力されていることを確認します。（少し待機していると表示されるようになります）
http://10.xxx.xxx.xxx:9799/metrics ServiceMonitor monitor アップ Namespace eapdemo 進行中 240.5 ms
- Developer パースペクティブへ変更し、[監視] -> [メトリクス] メニューへ遷移します。
- カスタムクエリー欄へ
jboss_undertow_active_sessionsのような項目名を入力すると以下のようなグラフに表示されることを確認します。
まとめ
以上のような手順で JBoss EAP の統計情報が Prometheus で確認することができました。あとは Prometheus の使い方を覚えると良い感じで統計情報を可視化することが可能になります。
メガドライブミニ２の準備のために HDMI 音声分離器を購入しました
メガドライブミニ２を予約
私は大昔、友達と一緒にセガ・マークIIIを購入してファンタジーゾーンや北斗の拳にハマって、Beep の北斗の拳の比較記事を読んでやっぱりセガだよなと思ったりした往年のセガファンなのですが、来月リリースされるメガドライブミニ２を予約してしまいました。
その当時、私はメガドライブは持ってなくて友達のところに行ってライトに遊んでいる感じでメガドライブに対してそれ程思い入れはないのですが、収録タイトル を見たら、シルフィード、ソーサリアン、ぎゅわんぶらあ自己中心派など、当時 PC-8801mkIISR でリリースされて羨しく思っていたタイトルが揃っていたので思わず予約してしまいました。他にもスプライトの回転拡大縮小機能を実現したスペースハリアーとか、新たに開発されたファンタジーゾーンなどアーケードに近い移植タイトルも多かったのでこれは買わないといかんなと思いました。
メガドライブミニ２が届く前に
メガドライブミニ２を接続する予定の外部ディスプレイは仕事用に買ったものでスピーカーがないため、以下の HDMI 音声分離器を購入し、3台の PC（Linux PC x 2、Windows PC x 1）を接続して確認したところ、Linux PC は2台とも音声が分離できたのですが、何故か Windows 11 はスピーカー付きディスプレイとして認識されませんでした。でも、Windows PC から外部ディスプレイへ HDMI 接続する場合は音声だけは PC 本体から聴くことで対応すれば問題ありません。（そのうち Windows 11 でも正しくディスプレイが認識されることを期待しています）
まとめ
これであとはメガドライブミニ２が届くのを待つばかりとなりましたが、お仕事でも外部スピーカーの良い音を聞きながら Web 会議へ参加できるようになったのでゲーム用途以外でも環境が改善できて良かったです。
グラディウスはバブルメモリで動作していたらしいです
バブルメモリからグラディウスへ繋がった話
中学時代に一緒にコンピューターにハマっていた友人からバブルメモリのことを聞いた時に、チップの中に泡みないなものが存在するのかなと妄想していたのですが、そんな時代をふと思い出してバブルメモリを調べてみたら、グラディウスのアーケード基板にバブルメモリが使われていた情報を見つけました。
グラディウス - アーケード版の筐体基板が、磁気バブルメモリを使用したバブルシステム（右の写真も参照）。
気になって調べてみたら、コナミが開発したバブルシステムと言うアーケード基板にはバブルメモリが使われていたことが分かりました。
ツインビーやグラディウスはこの基板上で動作していてバブルメモリにゲームのプログラムが保存されていたようです。（沙羅曼蛇は違うとのこと）
ちなみに私はオリジナル X68000 を今でも持っているのですが、グラディウスはかなり思い入れのあるゲームです。
追記
バブルメモリと言ったら FM-8 ですが、我が愛しの FM-7 では利用できなくなってしまったんですよね。（自分が買ったのは FM-New7 でしたが）
FM シリーズといったら Z80 カードを追加すると CP/M が利用できたようですが、強者は CP/M 上でテキストアドベンチャーゲームの Zork を遊んでいたそうで、実際、友達の行っていた高校の同級生はそんなことをしていたそうです。そんな感じで Zork とかのテキストアドベンチャーゲームはテキスト処理のみなのでいろいろな OS に移植されてましたね。
外付け Web カメラの NexiGo N60 1080P を購入してみました
個人所有の Windows PC の内蔵カメラの動作がおかしくなったため、この際だからと Linux でも使える外付け Web カメラの NexiGo N60 1080P を購入してみました。
本当に Linux でも使えるのか心配でしたが、Red Hat Enterprise Linux 8.6 と Fedora Linux 36 の2つの環境で、USB 接続しただけで Google Meet や MS Teams などで利用可能なカメラとして自動的に認識されてました。
Windows 環境では USB を接続するだけでカメラもマイクも問題なく動作し、Linux 環境でもカメラは問題なく動作したので心配は杞憂に終わりました。Linux 環境でマイクが動作しないのは事前に知っていたので影響はありません。
リモートワークでの Web 会議の品質がかなり良くなったので意味のある投資になりました。（Amazon ポイントで購入したのでお金は掛けてませんが…）
SQL Server が Oracle DB よりデッドロックが発生しやすいと思われる件について
自分の中でうる覚えだった SQL Server が Oracle DB よりデッドロックが発生しやすいと思われる件について、改めて調べてみたらかなり参考となるページが沢山見つかりました。
もう以下の2つのページに答えが書いてある感じですが、SQL Server のデフォルト設定だとトランザクション中での読み取り処理を行うとその行に対して共有ロックを実施するとのことで、この動作に起因して Oracle DB を利用する場合よりもデッドロックが発生しやすくなる理解で問題なさそうです。
上記ページにも記載されていた MVCC（マルチバージョンコンカレントコントロール）を採用している DB は結構あるようで、SQL Server も 2005 のバージョン以降であれば READ_COMMITTED_SNAPSHOT オプションを ON に設定すると MVCC の動作となるようです。
あと、以下のページでロックコストと同時実行性の関係が分かりやすく説明されておりました。恐らく、デフォルト設定の SQL Server では並列で大きな範囲でデータを更新しようとするとロックエスカレーションも発生することになり、よりデッドロックが発生しやすい状況になると思われます。
ちなみに、以下のページにあるように SQL Server Management Studio（SSMS）で自動コミットをオフにすると、SSMS 上で実行したクエリーだけではなく SQL Server エンジンそのものの挙動も変わるみたいです。そのように理解した理由として、以前、SSMS での自動コミットをオフにした状態で Blue Prism の設定画面で定義を変更したら応答が戻ってこなくなる事象に遭遇したためです。（イメージ的にはデッドロックが発生した感じでした） その後、SSMS の設定を自動コミット・オンへ戻すと Blue Prism 設定画面の動作も正常に戻りました。
いやー、DB は奥が深いですね。
ビル・バッチさんの情報を改めて調べてみました
JBoss EAP の CLI を利用してデータソースの統計情報を抽出する
JBoss EAP の CLI を利用してデータソースの統計情報を抽出する手順を整理します。
（このネタも殆ど同じ会社の方に教えていただいた情報ですが…）
- 5秒毎に任意のデータソースの統計情報から ActiveCount の行を抽出し、値の右側にあるカンマを削除するサンプル
while true; do $JBOSS_HOME/bin/jboss-cli.sh -c --command="/subsystem=datasources/data-source=<データソース名>/statistics=pool:read-resource(include-runtime=true)" | grep "ActiveCount" | awk '{print $3}' | sed -e 's/,//'; sleep 5; done
5
5
5
5
$JBOSS_HOME/bin/jboss-cli.sh -c --command="/subsystem=datasources/data-source=<データソース名>/statistics=pool:read-resource(include-runtime=true)"
{
"outcome" => "success",
"result" => {
"ActiveCount" => 5,
"AvailableCount" => 4,
"AverageBlockingTime" => 3L,
"AverageCreationTime" => 252L,
"AverageGetTime" => 3L,
"AveragePoolTime" => 26L,
"AverageUsageTime" => 5L,
"BlockingFailureCount" => 0,
"CreatedCount" => 5,
"DestroyedCount" => 0,
"IdleCount" => 4,
"InUseCount" => 1,
"MaxCreationTime" => 724L,
"MaxGetTime" => 140L,
"MaxPoolTime" => 142980L,
"MaxUsageTime" => 175L,
"MaxUsedCount" => 5,
"MaxWaitCount" => 4,
"MaxWaitTime" => 37L,
"TimedOut" => 0,
"TotalBlockingTime" => 8261L,
"TotalCreationTime" => 1262L,
"TotalGetTime" => 591603L,
"TotalPoolTime" => 5243097L,
"TotalUsageTime" => 1138902L,
"WaitCount" => 1236,
"XACommitAverageTime" => 0L,
"XACommitCount" => 0L,
"XACommitMaxTime" => 0L,
"XACommitTotalTime" => 0L,
"XAEndAverageTime" => 0L,
"XAEndCount" => 0L,
"XAEndMaxTime" => 0L,
"XAEndTotalTime" => 0L,
"XAForgetAverageTime" => 0L,
"XAForgetCount" => 0L,
"XAForgetMaxTime" => 0L,
"XAForgetTotalTime" => 0L,
"XAPrepareAverageTime" => 0L,
"XAPrepareCount" => 0L,
"XAPrepareMaxTime" => 0L,
"XAPrepareTotalTime" => 0L,
"XARecoverAverageTime" => 0L,
"XARecoverCount" => 0L,
"XARecoverMaxTime" => 0L,
"XARecoverTotalTime" => 0L,
"XARollbackAverageTime" => 0L,
"XARollbackCount" => 0L,
"XARollbackMaxTime" => 0L,
"XARollbackTotalTime" => 0L,
"XAStartAverageTime" => 0L,
"XAStartCount" => 0L,
"XAStartMaxTime" => 0L,
"XAStartTotalTime" => 0L,
"statistics-enabled" => true
}
}
$JBOSS_HOME/bin/jboss-cli.sh -c --output-json --command="/subsystem=datasources/data-source=<データソース名>/statistics=pool:read-resource(include-runtime=true)" | jq '[.result.ActiveCount,.result.IdleCount,.result.InUseCount,.result.MaxUsedCount] | @csv'
"5,2,3,5"
- 上記処理をループして5秒毎に CSV テキストを出力するサンプル
while true; do $JBOSS_HOME/bin/jboss-cli.sh -c --output-json --command="/subsystem=datasources/data-source=<データソース名>/statistics=pool:read-resource(include-runtime=true)" | jq '[.result.ActiveCount,.result.IdleCount,.result.InUseCount,.result.MaxUsedCount] | @csv'; sleep 5; done
"5,4,1,5"
"5,3,2,5"
"5,3,2,5"
"5,4,1,5"
本格的に利用する場合は、実行タイミングで時刻情報も出力するような改良が必要ですね…。
こんなサンプルですが何か参考になれば幸いです。
（追記）
- 上記処理の先頭に日付時刻情報を出力するようにしたサンプル
while true; do date '+%Y%m%d-%H%M%S' | tr '\n' ' '; $JBOSS_HOME/bin/jboss-cli.sh -c --output-json --command="/subsystem=datasources/data-source=<データソース名>/statistics=pool:read-resource(include-runtime=true)" | jq '[.result.ActiveCount,.result.IdleCount,.result.InUseCount,.result.MaxUsedCount] | @csv'; sleep 5; done
20220810-212010 "5,2,3,5"
20220810-212023 "5,4,1,5"
20220810-212037 "5,3,2,5"
20220810-212052 "5,3,2,5"
