がとらぼ

家のWindows PCは最近NASの仕事も別のホストに奪われたのでほぼテレビの録画のためだけに存在している。だから24/365稼働もすでにしていない。
そのテレビ録画だが、なんか番組の頭が1,2分くらい撮れていない。数秒程度なら現在のテレビ放送の仕組みとしては理解できなくもないが、1分を超えるのは尋常じゃない。マザボの電池切れのときのような数時間ドカンとズレるとか何年も巻き戻るとかじゃないからクロックオシレータがおかしいのかしら。
と、思って調べたら、直近のWindowsクリーンインストールの後に時刻同期設定をするのを忘れてた。

Q. 何でWindowsの時刻同期設定を忘れたら時間が狂うの？
A. 現在のWindowsの初期値では時刻同期してくれないから。

いやいやtime.windows.comと定期的に同期するよね？
それは7日ごとの決まった時間(日曜日の深夜1時)に運良くWindowsが起動していて、且つtime.windows.comが正常に時刻を返してくれたらというハードルの高い条件付きよ。こんなので時刻合わせできると期待しちゃダメ。

そこで、時刻同期する設定を行う。

変なトリガー起動サービス削除

まず、Windowsに最初から設定されている週1実行のトリガー起動サービスを削除する。こいつが有効だと週1回の時刻同期の後にActive Directoryドメイン非参加のPCではw32timeサービスが(動いていたら)停められてしまう。マイクロソフトらしいなんとも意味不明なアホアホ仕様。

Windows10を最新状態に更新しているなら「スタートボタン」を左クリック、「Windowsシステムツール」を左クリック、「コマンドプロンプト」を右クリック、「その他」「管理者として実行」で管理者権限のコマンドプロンブトを開く。 Windows10が古い状態ならスタートボタンを右クリックして「コマンドプロンプト(管理者)」をクリック。
以下この記事中のコマンドはPowerShellでは絶対に実行しないこと。

C:\Windows\system32> sc triggerinfo w32time delete
[SC] ChangeServiceConfig2 SUCCESS

緑字のコマンドを入力して[Enter]、SUCCESSが返れば成功。

w32timeサービスの自動開始設定

C:\Windows\system32>  sc config w32time start= delayed-auto
[SC] ChangeServiceConfig SUCCESS

これでw32timeのサービス起動設定が「自動(遅延実行)」になった。

確認コマンドを実行。

C:\Windows\system32> sc qc w32time
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: w32time
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START  (DELAYED)
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Windows\system32\svchost.exe -k LocalService
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Time
        DEPENDENCIES       :
        SERVICE_START_NAME : NT AUTHORITY\LocalService

START_TYPE が AUTO_START (DELAYED) になっていればOK.

w32timeサービスを起動

C:\Windows\system32>  sc start w32time

SERVICE_NAME: w32time
        TYPE               : 30  WIN32
        STATE              : 2  START_PENDING
                                (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x7d0
        PID                : 4772
        FLAGS              :

このコマンドでw32timeサービスを起動。すぐに結果を返してくれるのは良いが、まだSTATEがSTART_PENDINGになっている。

C:\Windows\system32>  sc query w32time

SERVICE_NAME: w32time
        TYPE               : 30  WIN32
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

このコマンドはw32timeサービスの起動コマンド実行から10秒以上経ってから実行。
STATEがRUNNINGになっていれば「実行中」になっている。これでOK.

個人的にはWindowsのGUI画面の情報なんか全然信用してなくてCUIの文字情報を盲目的に信じる傾向があるが、世の中には逆の人もいるということで、一応Windows窓アプリの画面で確認。

サービスの状態確認
スタートボタンを左クリック、「Windows 管理ツール」から「サービス」を起動して右列のリストを下にスクロールして「Windows Time」を探す。
状態が「実行中」でスタートアップの種類が「自動(遅延開始)」になっている筈。これだけのこと。

同期先指定

C:\Windows\system32> w32tm /config /manualpeerlist:"192.168.0.1,0x9"
コマンドは正しく完了しました。

C:\Windows\system32> w32tm /config /syncfromflags:manual /update
コマンドは正しく完了しました。

上のコマンドの192.168.0.1の部分は同期させたいNTPサーバのアドレスに置き換えて。LAN内にNTPサーバがあるならそのアドレスを指定。家庭用ルーターにNTPサーバ機能があって有効にしているならそのルーターのアドレスを指定する。
NTPソースは複数指定できるので「192.168.0.1,0x9 192.168.0.2,0x2」のように半角スペースを挟んで指定する。
上では2つのw32tm /config を実行しているが、オプションを纏めて1回の実行でも構わない。

基本的に家庭や職場・学校の個々の端末から公開NTPサーバに時刻を取りに行くのは無しの方向で。特に福岡大のNTPサーバは今後時期不明に停止するとのことなので設定しないこと。家庭内・組織内にNTPサーバなんか無いよということであればヘタに公開NTPサーバを指定するよりは寧ろ初期値のtime.windows.comにしたままの方がマシ。(こっちは混んでもmicrosoftの自業自得)
どうしてもtime.windows.com以外の公開NTPサーバから時刻を貰わなくてはならない場合は同期頻度を1日1回(orそれ以下)に下げること。

以前(一時期だけど) INTAA.NETのNTPサーバをpool.ntp.orgに参加させたらNTPサーバとルーターが悲鳴を上げたので公開NTPサーバって大変だなって思った。だから公開NTPサーバの負荷にならないよう皆で協力しようね。

サーバアドレスの後の,0x?はフラグ。

0x1: 指定するとSpecialInterval(同期間隔固定)、指定しないとMaxPollIntervalとMinPollIntervalを使用
0x2: UseAsFallbackOnly (フォールバック用NTPサーバのフラグに付ける)
0x4: SymmetricActive (相互同期モード NTPサーバ用かと)
0x8: Client (NTPクライアントとして要求)
0x9: 0x1 + 0x8 (NTPクライアントとして固定間隔で時刻を取る)
0xa: 0x2 + 0x8 (NTPクライアントとして代替NTPから時刻を取る)

上のコマンドで反映されるレジストリの値は
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\ParametersのNtpServer文字列値。だからレジストリファイルをダブルクリックで設定を適用という方法もある。(下の方にダウンロードリンク)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"NtpServer"="192.168.0.1,0x9"
"Type"="NTP"

同期間隔指定

SpecialPollInterval : 固定間隔 Windows独自の設定
MaxPollInterval : 最大間隔
MinPollInterval : 最小間隔

3つの値の内、SpecialPollIntervalとMaxPollInterval&MinPollIntervalは排他設定っぽいけど実際の動作は違う(不明な)ようなので注意。

SpecialPollIntervalは値(秒)毎に時刻同期するという指定で、10進数の秒で指定する。
MaxPollInterval(最大間隔)とMinPollInterval(最小間隔) の値は単純な秒数ではなく2の「べき乗」の秒数なので値が7なら7秒ではなく2⁷(=128秒: 2分と少し)、値が8なら2⁸(=256秒 : 約4分ちょっと)になるので注意。

実際にMaxPollInterval, MinPollIntervalの指定で使いそうな範囲

2⁹ : 512秒 (約8分半)
2¹⁰ : 1024秒 (約17分)
2¹¹ : 2048秒 (約34分)
2¹² : 4096秒 (約1時間8分)
2¹³ : 8192秒 (約2時間16分半)
2¹⁴ : 16384秒 (約4時間33分)
2¹⁵ : 32768秒 (約9時間6分)
2¹⁶ : 65536秒 (約18時間12分)
2¹⁷ : 131072秒 (約1日と12時間24分半)
2¹⁸ : 262144秒 (約3日と49分)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00000384

16進数で384は10進数で900 = 15分。30分はdword:00000708、1時間はdword:0000e10、2時間はdword:00001c20 。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"MaxPollInterval"=dword:0000000f
"MinPollInterval"=dword:0000000a

dword:0000000fは10進数では15でこの値では2¹⁵秒の意味なので9時間余り、dword:0000000aは10進数では10で2¹⁰秒(約17分)、これが初期値。 SpecialPollIntervalを使うつもりでもMaxPollInterval, MinPollIntervalに影響されるようなので、SpecialPollIntervalと矛盾しない範囲でそれぞれ設定しておく。SpecialPollIntervalがMaxPollInterval&MinPollIntervalの値の範囲内にあるようにすると矛盾しない。

レジストリファイル

レジストリを変更するコマンドもあるが、間違ったレジストリのコマンドが通ってしまうので怖い、同様にレジストリエディタで直に変更もあまり好ましく思っていないので、レジストリファイルを使って登録することにしている。(次回以降のクリーンインストール後の設定でも使えるし)まぁ、コマンドをバッチファイルでも良いんだけど。

ntp_server_name.reg NTPサーバ指定用レジストリ
ntp_interval.reg ポーリング間隔指定用レジストリ

「がとらぼ」のウェブサーバーではレジストリファイルをクリックするとテキストファイルとして表示されるようになっているので上のリンクを右クリックしてファイルとして保存する。
ダウンロードしたらメモ帳やエディタで開いて必要に応じて値の変更を行ってから上書き保存し、ファイルをダブルクリックするとレジストリが適用される。

ローカルグループポリシーエディタで変更

Windows 10 Proエディション以上の場合はローカルグループポリシーエディタでの設定も可(ただし、前述のNTPサーバ指定とSpecialPollIntervalだけ)。

時刻同期確認 5
ローカルグループポリシーエディタの左列から「コンピューターの構成」「管理用テンプレート」「システム」「Windows タイムサービス」「タイムプロバイダー」を辿る。
右列から「Windows NTPクライアントを構成する」をダブルクリック

時刻同期確認 6
上部の「有効」ラジオボタンを選択する。
NtpServerにNTPサーバとフラグを指定する。(前述参照)
SpecialPollIntervalの秒数を指定。(普通の10進数の整数)
「適用」「OK」を押す。

同様の手順で1つ前の画像の右列「Windows NTPクライアントを有効にする」の項目の上部の「有効」ラジオボタンを選択して適用・OKを押す。

確認

C:\Windows\system32> w32tm /query /status /verbose
閏インジケーター: 0 (警告なし)
階層: 4 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.1493977s
ルート分散: 8.3389868s
参照 ID: 0xC0A80001 (ソース IP:  192.168.0.1)
最終正常同期時刻: 2018/03/04 19:18:20
ソース: 192.168.0.1,0x9
ポーリング間隔: 10 (1024s)

フェーズ オフセット: 0.4989077s
クロック レート: 0.0156250s
State Machine: 1 (保留)
タイム ソース フラグ: 0 (なし)
サーバーのロール: 0 (なし)
最終同期エラー: 0 (コマンドは正しく完了しました。)
最終正常同期時刻からの時間: 171.9005943s

コマンドプロンプトだとこんな感じ。
指定はSpecialPollInterval 900秒(15分)の筈だけどポーリング間隔は2¹⁰(=1024)秒で約17分になってる。いろいろ試したけど2ⁿな値にしかならないのでSpecialPollIntervalが使われないのは何でかしら。なんかドキュメントどおりじゃなくて納得できないけど、そういうものなのかな、所詮Windowsだし。というか「固定間隔」というWindows独自の変なのは使えない方が良いのか・・

一応、GUI画面でも確認しておく。

時刻同期確認 1
デスクトップの時計をクリックし、「日付と時刻の設定」をクリックする。

時刻同期確認 2
下にスクロールして、「日付、時刻、地域の追加設定」をクリックする。

時刻同期確認 3
「日付と時刻」または、「日付と時刻の設定」をクリックする。

時刻同期確認 4
「日付と時刻」窓の上部の「インターネット時刻」タブを選択する。
指定したNTPサーバと同期できていること、次回の同期予定日時と前回正常に同期した日時を比較して指定どおりかそれに近い間隔になっていることを確認する。

この画面の「設定の変更」を触るとここまで行った変更が上書きされる可能性があるので手を付けないのが無難。

監視対象ホストの状態をkibanaのダッシュボードで確認していたら昨日まで正常に表示されていた筈のNTPサーバのoffset等のグラフがゼロ(0)で動かなくなっていた。グラフに線が表示されないなら値が取れていないと思われるがゼロに張り付いているということは値が取れていてそれがゼロということ。では、取得している値が本当にゼロになっているのかとDiscoverから確認するとゼロではない値が取得されている。ただし、1より遥かに小さい値。

これはインデックスで扱っている数値の型が間違っている可能性が高そう。

elasticsearch インデックスのスキーマが勝手に変わる対処 1
上の画像の赤枠のグラフが値がゼロで張り付いてしまっている。

elasticsearch インデックスのスキーマが勝手に変わる対処 2
正常な頃は上の画像の左半分のようなグラフが表示されていた。
それがこの日の午前9時頃を境に全ての値がゼロになっている。

elasticsearch インデックスのスキーマが勝手に変わる対処 3
Kibanaの左列から Dev Tools をクリックし、中央列のテキストボックスにマッピング確認コマンドを入力する。

GET logstash-2018.02.22/_mapping

インデックスlogstash-2018.02.22 (2018年2月22日)のスキーマ(マッピング)を取得。
_mappingの後に ?pretty または ?pretty=1 を付けても付けなくてもJSON Pretty-Printで返されるようだけど何か勘違いしてるかしら。
入力したら (実行)ボタンを押す。結果は右列に表示される。

もちろん、kibanaからじゃなくて従来通りターミナルでコマンド打ちでも良い。

% curl -XGET '127.0.0.1:9200/logstash-2018.02.22/_mapping?pretty=1'

FreeBSDのports/pkgでインストールしたcurlで実行するならGETの後ろはシングルクォーテーションで囲むこと。

正常な表示だったころ(2018年2月22日)のスキーマでvalueの型を確認。

{
  "logstash-2018.02.22": {
    "mappings": {
      "collectd": {
        "properties": {
          "value": {
            "type": "float"
          }
        }
      }
    }
  }
}

上の結果は関係ない部分を全て省略している。

値が全てゼロになってしまっている日(2018年2月25日)のスキーマでvalueの型を確認。

{
  "logstash-2018.02.25": {
    "mappings": {
      "collectd": {
        "properties": {
          "value": {
            "type": "long"
          }
        }
      }
    }
  }
}

上の結果は関係ない部分を全て省略している。

正常な頃のスキーマはvalueの型がfloat (32bit浮動小数点数)だったので小数点以下があったが、値がゼロになっているスキーマではそれがlong (64bit符号付整数)になっているので整数しか扱われないと見て良さそう。

インデックスの作り直しは面倒なので今回は無しとして、次に作られるインデックスからはvalueがlongではなくdoubleになるようにしておきたい。 (今回は好みでdoubleにしたがfloatでも可)

Kibanaの左列から Dev Tools をクリックし、中央列のテキストボックスにテンプレートを入力する。今回はvalueだけ型を指定する内容にしているが他も同時に指定してもちろんOK.

PUT /_template/logstash
{
 "template" : "logstash-*",
 "order" : 1,
 "mappings": {
  "collectd": {
   "properties": {
    "value": {
     "type": "double"
    }
   }
  }
 }
}

elasticsearch インデックスのスキーマが勝手に変わる対処 4
入力したら1行目の右端の (実行)ボタンを押す。右列に acknowleded : true の表示が出たら実行が成功している。

新しいインデックスが作られてから確認する。下は2018年2月26日のインデックスのマッピングを確認する内容。

GET logstash-2018.02.26/_mapping

{
  "logstash-2018.02.26": {
    "mappings": {
      "collectd": {
        "properties": {
          "value": {
            "type": "double"
          }
        }
      }
    }
  }
}

上の結果は関係ない部分を全て省略している。

elasticsearch インデックスのスキーマが勝手に変わる対処 5
指定したとおりvalueがdouble型になっている。これで安心。

ちなみにインデックスをデータごと一掃したいという場合は同様にDev Toolsで DELETE logstash-* を実行する。

Windows 10の時刻同期設定

変なトリガー起動サービス削除

w32timeサービスの自動開始設定

w32timeサービスを起動

同期先指定

同期間隔指定

レジストリファイル

ローカルグループポリシーエディタで変更

確認

ELK Stackでシステム監視 elasticsearchインデックスのスキーマが勝手に変わる対処テンプレート作成