サーバー監視の手法として Windowsサーバーのメトリクスを SQL Serverに格納します。

Windowsのサーバーメトリクス(負荷情報など)を取得するパフォーマンスカウンタという機能がありますが、あそこに出力先を SQL Serverにする設定箇所があるんですよね。

実際のその機能を使った時に、どのようになるのか検証してみます。

環境は Windows Server 2022と SQL Server 2022でやります。
実際の運用では SQL Serverがリモートになるケースが多いと思いますが、所詮は DBの指し先が localhostからリモート先のサーバー名になる程度の差しかないと思いますので、Windows Server 2022のローカルにある SQL Serverを使いますね。

Windows Server 2022のインストールは「Windows Server 2022 インストール」に、
SQL Server 2022のインストールは「SQL Server 2022インストール」に、それぞれ書いています。

受け入れ先の SQL Serverには「testdb」というユーザーデータベースが既に作ってある前提です。
面倒くさいので、管理ユーザーである「sa」を使ってしまいますが、本当の環境ではちゃんと専用のユーザーを作りましょう。

パフォーマンスカウンタで取得した値を SQL Serverに飛ばすには、ODBCデータソースが必要になりますので先にそれを作っておきます。

スタートメニューより[Windows 管理ツール]-[ODBC データソース(64ビット)]を選択します。

ユーザーDSN・システムDSN・ファイルDSNがありますが、今回はパフォーマンスカウンタから実行させることになるので、システムDSN(タブを選ぶ)にしておきます。
追加を押します。


すみません、このOSには SQL Server 2022がインストールされているので、SQL Server用のドライバが色々入ってしまっています。
古い方が OS添付のものかと思って[ODBC Driver 17 for SQL Server]を選択しました。
もしかすると[SQL Server]かも知れません。
完了を押します。


[名前]は任意のものを。
[サーバー]には SQL Serverがインストールされているホスト名を入れます。
次へを押します。


ローカルの場合は[統合Windows認証を使う]を選んでおけば良いのですが、ここはリモートサーバーの SQL Serverを利用するケースを鑑み、あえて[ユーザーが入力するSQL Server用のログインIDとパスワードを使う]を選択しました。
一番下に、SQL Server 2022の管理者ユーザー「sa」とそのパスワードを設定しました。
次へを押します。


多分やらなくても大丈夫だと思いますが、一応[規定のデータベースを以下に変更する]にチェックして、[testdb]を選択しておきます。
データベースの一覧がリストに出てくるので、この時点で SQL Server 2022に接続できていることが分かります。
次へを押します。


完了を押します。


OKを押します。


OKを押します。


これで ODBCデータソースの設定は良いでしょう。


Windowsパフォーマンスカウンタを設定します。
具体的にはデータコレクタという枠を作って、その中にパフォーマンスカウンタの設定を入れる感じです。

スタートメニューより[Windows 管理ツール]-[パフォーマンス モニター]を選択します。

このウィンドウが開きますので、左にあるツリーから[パフォーマンス]-[データコレクタセット]-[ユーザー定義]と辿り、[ユーザー定義]で右クリックすると出てくるメニューから[新規作成]-[データコレクタセット]と選択します。


[名前]は任意で。
[手動で作成する]を選択し、次へを押します。


[データログを作成する]を選択し、[パフォーマンスカウンター]にチェックを入れ、次へを押します。


[サンプルの間隔]は好きにして良いのですが、私は1分が好きですので、そう設定しました。
追加を押します。


左上の窓で[Processor]-[Processor Time]を選択、左下の窓では[_total]を選択し、追加を押します。
CPUの使用率になります。


同様に[Memory]-[Available MBytes]を追加します。
メモリの空き MB数ですので、後で実装メモリ量から引くとメモリ使用量になります。
OKを押します。


次へを押します。


次へを押します。


[このデータコレクターセットのプロパティを開く]を選択し、完了を押します。


[全般]タブです。このまま。

[ディレクトリ]タブです。
ファイルに落とす時はここで様々な名前に変えられますが、後で SQL Serverに送信するせっていをするので、このままで良いでしょう。


[セキュリティ]タブです。このまま。


[スケジュール]タブです。このまま。


[停止条件]タブです。
SQL Serverに送る場合は何も設定する必要はないんですが、何となくファイルに落とす場合のために 10MBで次のファイルに変わるよう設定してしまいました。
単にクセです。


[スケジュール]タブです。このままでOKを押します。


[パフォーマンスモニター]のウィンドウに戻ってきました。
右側に今作った[DataCollector01]という名のパフォーマンスカウンターを選択し、右クリックすると出てくるメニューから[プロパティ]を選択します。


この画面になりますので、[ログフォーマット]に[SQL]を選択します。

[データソース名]に先程作った ODBCの DSN[SQL Server 2022]を選択し、OKを押します。


この画面に戻りますので、左のツリーの[SQL Serverに送る]を左クリックして出てくるメニューから、[開始]を選択します。


何故か失敗しました…


アプリケーションイベントログにこんなエラーが記録されています。
内容を読むと、「ユーザー " はログインできませんでした。」とか言っています。


？？？？

良く考えてみると、データーコレクタセットを作る過程に SQL Server 2022の sa ユーザーとそのパスワードを設定した覚えがありません。
作業を振り返って、それぞれの画面を見てみたのですが、それらしい箇所も無く…。

これは…、ODBCの設定では[ユーザーが入力するSQL Server用のログインIDとパスワードを使う]ってのを選択していましたよね。
この画面です。

この画面で saユーザーとパスワードを設定していますが、これはあくまで ODBC接続「設定中」にだけ使うもので、ODBC接続の DSNに埋め込んでいるものではありません。

そういえばこの DSNを Excelから使うときも、ユーザー名とパスワードを入力させられた事を思い出しました。

パフォーマンスカウンタだってユーザー無しには SQL Serverにログインできませんわなぁ。

この状況を分析してみると、パフォーマンスカウンタから SQL Serverにデータを飛ばすには Windows認証でないといけないのではないか？、という疑問が。

いや、疑問というより、そうなのでしょう。

この仕組みにおいてはマイクロソフトのヤル気の無さが見え隠れしており、Active Directoryで管理されているネットワーク環境しか相手にしていない感じです。

結局 AD環境下にない Windows Serverから SQL Serverへのデータ投入は無理そうです。
こうなるとローカルにある SQL Serverしか相手にできない訳でして、実用性が皆無…。


そういえば以前 Windows Server 2019と SQL Server 2019のセットで同じ検証をして同じ結論に至った記憶があるような無いような。

その結果「Windowsサーバーの負荷を自動でグラフ化」でやったように、Powershellでメトリクスを抜いて NoSQLデータベースに書くことにしたような気がします。

その後少し検証して、以下のセッティングでローカルの SQL Serverに書くことはできましたので、それを書いていきます。


●SQL Server 2022に書くには新しいドライバでないとだめ

上の例では ODBCの DSNを作る際に[ODBC Driver 17 for SQL Server](多分 Windows Server 2022付属)を選択しましたが、これだと古くて SQL Server 2022にテーブルを作れないようです。

代わりに[SQL Server]というドライバを使いましたが、これはタイムスタンプからすると SQL Server 2022のインストールによるもので、最新版とは言えないまでも SQL Server 2022に対応したものだと思います。


●データコレクタセットの実行ユーザーはビルトインユーザーではだめ

データコレクタセットを実行しているのはビルトインユーザー(OSに最初からあるシステム用のユーザー)「SYSTEM」でした。

コイツだと SQL Server 2022のユーザー管理設定のデフォルト状態だと Windows認証の対象にはなってないようで、ログインに失敗します。

実行ユーザーを Administrator に変えました。


まず ODBCのシステムDSNを作り直します。
追加を押します。


[SQL Server]を選択し、完了を押します。


[名前]は任意のものを。
[サーバー]には SQL Serverがインストールされているホスト名を入れます。
次へを押します。


[ネットワークへのログインIDで、Windows NT の認証メカニズムを使う]を選択し、次へを押します。


[規定のデータベースを以下に変更する]にチェックして、[testdb]を選択しておきます。
データベースの一覧がリストに出てくるので、この時点で SQL Server 2022に接続できていることが分かります。
次へを押します。


完了を押します。


データソースのテストを押します。


Administratorユーザーでログオンができています。
OKを押します。


OKを押します。


OKを押します。


これで ODBCデータソースの設定は良いでしょう。


Windowsパフォーマンスカウンタの設定を変更します。

左のツリーの[SQL Serverに送る]を左クリックして出てくるメニューから、[プロパティ]を選択します。


[別のユーザーとして実行:]にある変更を押します。


[ユーザー名]を「Administrator」にしてパスワードを入力し、OKを押します。


OKを押します。


またこれが出るので、パスワードを入力し、OKを押します。


この画面に戻りますので、左のツリーの[SQL Serverに送る]を左クリックして出てくるメニューから、[開始]を選択します。


[SQL Serverに送る]のところに緑の三角形(Playマークなんでしょう)が表示されていて、パフォーマンスカウンタを取得していることが分かります。


これで SQL Server 2022にパフォーマンスカウンタのデータ(サーバーメトリクス)が溜まっていっているはずです。


SQL Server 2022にはどんな風にデータが格納されているんでしょうか。

以下 3つのテーブルが自動で作成されまして、見たところこんな中身のようです。

DisplayToIDテーブルの内容です。
[GUID]カラムで CounterDataテーブルの行をログ毎に集約はできますが、マシン名との紐付けがないですね。


CounterDetailsテーブルの内容です。
[CounterID]カラムの番号はマシン毎に別になるのであれば CounterDataテーブルのデータをマシン名で集約できますが、個別になるかは未検証です。


CounterDataテーブルの内容です。



SQLをこねくり回して 3つのテーブルを結合(JOIN)すれば、マシン名を起点にカウンタ毎のデータを時系列で取り出せそうではあります。

それができれば、Grafanaでリアルタイムにグラフ表示するとか、Pythonの matplotlibでグラフを画像ファイルにするとかできますね。


ただ全体的な感想を言うと「分かりづらい」の一言で、労多くして益少しって感じですねぇ。

もう少しシンプルにならんものかと思われ、インターネット上にこの仕組みを使っている情報の少なさを見るに、推して知るべしなんでしょう。

これだと Prometheusの node-expoterなどサードパーティの方が使いやすく、マイクロソフトさんには頑張って欲しいところなんですが、残念ながらこの仕組みは少なくとも Win2008の頃から変わってない様子です。


今回のネタは徒労になってしまいました。
マイクロソフト製品でガチガチに固めた環境ならなんですけど、Linuxと相乗ってる会社さんとかで ADが全てではない環境では「ちょっとなぁ…」でしたね。

もし「こういう風にすればもっと上手く行くぞ！」という情報をお持ちの方がいらっしゃいましたら、ご教示頂けると幸いでございます。