がとらぼ
INTAA.NET

Elastic Stack 8系をFreeBSDにインストール

もしも、FreeBSDにElastic Stack 8をインストールしてみたら

今回はElastic Search 8とKibana 8をFreeBSDにインストールして使用できる状態にする。なお、この記事のタイトルは「Elastic Stack 8のインストール」だがLogstashは次回以降の予定。
「がとらぼ」では過去にElactic Stackの5系と6系のインストール記事を公開していますが、8系ではセキュリティー強化の影響で使えるようになるまでの手順が大幅に変わっています。古い系統のドキュメント参照すると「訳がわからない」「全然動かない？」ということになるので8系をインストールするなら8系向けのドキュメントを参照してください。7系については「がとらぼ」では触ったことがないので全く知りません。

インストール

いつものようにportsを使います。ElasticsearchはJava JDKと関連portsを必要とするのでJDK関連のビルド時間が長めです。KibanaはNode.jsを必要とするのでNode.jsのビルド時間が長めです。

# cd /usr/ports/textproc/elasticsearch8
# make install

configオプション
[x] DOCS Build and/or install documentation

# cd /usr/ports/textproc/kibana8
# make install

Javaを使えるようにするために 以下4つのファイルを編集

/etc/fstab (追記2行)
fdesc           /dev/fd         fdescfs rw      0       0
proc            /proc           procfs  rw      0       0
/boot/loader.conf (追記1行)
fdescfs_load="YES"
/.cshrc (追記1行)
setenv JAVA_HOME /usr/local/openjdk17
/.profile (追記1行)
export JAVA_HOME=/usr/local/openjdk17

Elastic Search本体の稼働で必要なJavaの環境設定は/usr/local/etc/rc.d/elasticsearchの中のES_JAVA_HOMEで行われていますが、Elastic Search本体以外のJavaプログラムの実行に/.cshrcや/.profileのJAVA_HOME変数が要ります。JAVA_HOMEだと警告がうるさいですが。

Elasticsearch 8の設定

/usr/local/etc/elasticsearch/jvm.options (2行の行頭の#を削除)
-Xms4g
-Xmx4g

ヒープサイズは自動設定される(設定ファイルの初期値はコメント状態)ということになっているが、搭載しているシステムメモリが少なめの場合は自動設定ではElasticSearchが起動しないよう。最初は1GB程度(-Xms1g -Xmx1g)で設定しておいて、運用開始後に必要に応じてサイズを大きい方に変更。

システムを再起動する。

システム再起動後
# df -a
Filesystem  1K-blocks      Used     Avail Capacity  Mounted on
/dev/ada0p2 472844096 122611692 312404880    28%    /
devfs               1         1         0   100%    /dev
/dev/ada0p1       767       131       636    17%    /boot/efi
fdescfs             1         1         0   100%    /dev/fd     ←この行があること
procfs              4         4         0   100%    /proc       ←この行があること

Elastic Searchの設定ファイルの編集

殆どはFreeBSDのports/pkgでインストールした設定のままで良い筈。逆に古いバージョンのElastic Searchのインストール/設定系の記事を見て迂闊な設定を行うとElastic Searchが動かくなくて悩むことになるかも。
少なくともElasticSearch 8系は、最初の起動時にlocalhost向けのTLS接続用証明書が作成されてlocalhostからの接続のみを許可する状態になるのでlocalhost以外からの接続を許すnetwork.host設定を行うと起動が失敗するようになるっぽい。旧系の設定では最初からLAN内OKだとかなんなら0.0.0.0(全世界OK)のような設定をしていたと思われるのでそこは注意。
Elasticsearch初起動時に証明書が作成されるのだが、ネットワークインターフェイスに割り当てられているIPアドレスとそのホスト名が正しく認識されないことがあるよう。localhostしか認識されずに証明書が作成されると後で苦労することがあるよう。/etc/hostsの記述が適切な状態にしてからElasticsearchを起動する方がより確実？

/usr/local/etc/elasticsearch/elasticsearch.yml (編集) 
node.name: node-1  (任意の名前)
path.data: /var/db/elasticsearch (FreeBSD ports/pkg初期値)
path.logs: /var/log/elasticsearch (FreeBSD ports/pkg初期値)

#network.host: 192.168.0.1      (コメントのままにしておくか network.host: 0.0.0.0)
http.port: 9200
transport.port: 9300
discovery.type: single-node  (Elasticsearchを1ノードで使用する場合)
xpack.ml.enabled: false  (FreeBSD ports/pkg初期値)
/etc/rc.conf (追記1行)
elasticsearch_enable="YES"
Elastic Searchサービスの起動
# service elasticsearch start

初回起動時に以下の設定が自動で追加される。

/usr/local/etc/elasticsearch/elasticsearch.yml (ファイル最後を確認)
# Enable security features
xpack.security.enabled: true

xpack.security.enrollment.enabled: true

# Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12     (/usr/local/etc/elasticsearch/certs下のこと)

# Enable encryption and mutual authentication between cluster nodes
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12
# Create a new cluster with the current node only
# Additional nodes can still join the cluster later
cluster.initial_master_nodes: ["node-1"]        (localhostのみ許可で起動すればノード名はこのelasticsearch.ymlで設定したnode.nameと同じなるかと)

最後のcluster.initial_master_nodes:の行はElasticsearchをシングルノードで使用する場合は削除する。設定次第だが、この行があるとElasticsearchが起動に失敗することがあるよう。

自動作成された証明書の確認

Elasticsearch初起動時に /usr/local/etc/elasticsearch/certsに CA証明書 http_ca.crt、Elasticsearchのxpack.security.http.sslで使われる http.p12、xpack.security.transport.sslで使われるtransport.p12の3つが全自動で作成されるが、http_ca.crtとtransport.p12はパスワードの入力も求められてなくて証明書の作成に関する表示も無かったのでそのパスワードが不明。 しかし、パスワードは管理されているらしくキーストアで確認できるよう。

# elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password
RSbq5dtTRXSuOsuUB4sumB   (← http.p12証明書のパスワードの例)

求めたパスワードを使用し、次のように証明書の中身を表示する。

# keytool -list -v -keystore /usr/local/etc/elasticsearch/certs/http.p12 -storetype PKCS12 -storepass 'RSaq5duTRXSuOsuUB3sumA'
Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: http
Creation date: Jan 12, 2023
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=node-1
Issuer: CN=Elasticsearch security auto-configuration HTTP CA
Serial number: f01242a44e58729d4857701b8d665ab9955f4265
Valid from: Thu Jan 12 22:37:13 JST 2023 until: Sat Jan 11 22:37:13 JST 2025
Certificate fingerprints:
         SHA1: 84:A3:83:58:87:EF:BE:D7:A5:10:C6:CC:B5:A6:C4:56:EF:D1:B5:AD
         SHA256: AF:66:2D:04:2E:83:BC:56:CE:8B:A0:8F:45:95:73:3E:56:F6:11:3F:75:A5:1A:1F:94:4C:92:2C:3F:10:65:FE
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

この後もズラズラ出てきます

ここで確認しておきたいのがSAN情報。中段あたりに「SubjectAlternativeName」があるのでそこに含まれるDNSホスト名とIPアドレスを確認します。

SubjectAlternativeName [
  DNSName: localhost
  IPAddress: 127.0.0.1
  IPAddress: 192.168.0.128
  DNSName: es.example.com
  IPAddress: 192.168.16.1
]

ここでループバックアドレスの127.0.0.1とlocalhostしかない場合はそのあと証明書の再作成が必要になると思われます。苦労されられそうなので /usr/local/etc/elasticsearch/certsとelasticsearch.keystore を削除し、 /usr/local/etc/elasticsearch/elasticsearch.yml の最後の方「BEGIN SECURITY AUTO CONFIGURATION 」の行から最後を全て削除します。xpack関係の設定がElasticsearch初起動時に自動で追加されたものです。
そしてElasticsearchを再起動して証明書が再作成されたら再びその証明書を確認します。

Elastic Searchにアクセスしてみる

# curl 'http://localhost:9200/'    (旧版と同じ方法で非HTTPS接続)
curl: (52) Empty reply from server
Elastic Searchからの返事は空でした。 
# curl 'https://localhost:9200'    (旧版と同じ方法でHTTPS接続)
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

# curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
TLS証明書の問題でダメでした。 
# curl --cacert /usr/local/etc/elasticsearch/certs/http_ca.crt 'https://localhost:9200'    (証明書を指定してHTTPS接続)
{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}

Elastic Searchから返事は受け取れましたがユーザー認証が要るようです。
Elastic Searchの特権ユーザーは「elastic」ですが、パスワードなんて知りません。ここは「elastic」ユーザーのパスワードをリセットします。

/usr/local/bin/elasticsearch-setup-passwordsでパスワードを生成します。
# elasticsearch-reset-password --auto --username elastic
warning: ignoring JAVA_HOME=/usr/local/openjdk17; using bundled JDK
This tool will reset the password of the [elastic] user to an autogenerated value.
The password will be printed in the console.
Please confirm that you would like to continue [y/N]y ( yを選択)

Password for the [elastic] user successfully reset.
New value: *i=1234himitsu_abc    (elasticユーザーの新しいパスワードが生成されたのでメモします)

elasticユーザーと発行したパスワードを使ってElasticsearchと通信してみる。

# curl --cacert /usr/local/etc/elasticsearch/certs/http_ca.crt -u elastic 'https://localhost:9200'
Enter host password for user 'elastic':  *i=1234himitsu_abc  (パスワード入力)
{
  "name" : "node-1",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "xOps88YeSGVcnQFQVxXHQ9",
  "version" : {
    "number" : "8.5.3",
    "build_flavor" : "default",
    "build_type" : "tar",
    "build_hash" : "4ed5ee9afac63de92ec98f404ccbed7d3ba9584e",
    "build_date" : "2022-12-05T18:22:22.226119656Z",
    "build_snapshot" : false,
    "lucene_version" : "9.4.2",
    "minimum_wire_compatibility_version" : "7.17.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "You Know, for Search"
}

通信できることを確認できました。

既にあるElasticsearchクラスタにノード登録する

稼働中のElasticsearchクラスタのElasticsearchサービスでエンロールメント(登録)・トークンを発行します。

# elasticsearch-create-enrollment-token -s node
a1b2c3-トークン文字列-7x8y9z

トークンは200文字以上ほどありますがコピーします。トークンは発行から30分間有効です。

発行したトークンを新しく動かすElasticsearchノードに適用します。

# elasticsearch --enrollment-token a1b2c3-トークン文字列-7x8y9z

当然ですが、Elasticsearchのホストが1台しかないのであればこのトークンの発行と登録は行いません。

Kibanaの設定

/usr/local/etc/kibana/kibana.yml
server.port: 5601
server.host: 192.168.2.16   Kibana(+Elastic Search)があるホストのIPアドレス等(ブラウザ側)
elasticsearch.hosts: ['https://localhost:9200']    (KibanaとElasticsearchが別ホストならElasticsearchのIPアドレス等を指定してください)
pid.file: /var/run/kibana.pid
i18n.locale: ja-JP
server.publicBaseUrl: "http://192.168.2.16:5601"

最も基本的な設定ですが、これだと実用的ではないかと思われます。

/usr/local/etc/kibana/kibana.yml (変更)
server.name: kibana.example.com
server.port: 5601
server.host: 0.0.0.0
server.ssl.enabled: true
server.ssl.certificate: /usr/local/etc/kibana/certs/fullchain.pem
server.ssl.key: /usr/local/etc/kibana/certs/privkey.pem
server.publicBaseUrl: 'https://kibana.example.com:5601'
elasticsearch.hosts: ['https://192.168.2.16:9200']
pid.file: /var/run/kibana.pid
i18n.locale: ja-JP

SSL/TLS対応の設定です。
Kibanaが1つのネットワークだけを相手にするならserver.hostには普通にネットワークインターフェイスに割り当てられたIPアドレスを指定しますが、beatsを使用するなどで複数のネットワークのIPアドレスを使うなら0.0.0.0の方が良さそうです。
192.168.2.16はElasticsearchがあるホストです。ElasticsearchとはHTTPSで通信するので https://192.168.2.16:9200 というURLを使用します。ElasticsearchとKibanaが同じホストで稼働するならhttps://localhost:9200というURLでも良いのですが、この次のトークン登録を行うと何故かループバックアドレスからネットワークインターフェイスに割り当てられたIPアドレスに書き換えられます。(理由は不明です)

ユーザーがブラウザでKibanaと通信する側は、server.ssl〜の設定です。elasticの公式ドキュメントではオレオレ証明書を使うようですが、ここではLet's Encryptの証明書を使用することにしました。ユーザーのブラウザ側でCA証明書を登録せずに済みます。ただし、certbotで普通に取得/更新した証明書ファイルはパーミッションの関係でKibanaが読み取れないためKibanaが起動に失敗するか起動してもブラウザでなにも表示できない状態になるかもしれません。
/usr/local/etc/kibana/cert のようなディレクトリを作成してLet's Encryptの証明書置き場(FreeBSDでcertbotを使って証明書を取得/更新しているなら /usr/local/etc//usr/local/etc/letsencrypt/live/ホスト名 )から fullchain.pem と privkey.pem をコピーしKibanaが読めるパーミッションを設定します。Let's Encryptの証明書は3ヶ月で期限を迎えるので自動更新の度に証明書ファイルのコピーとパーミッション設定の変更を行うようにしておきます。Kibanaサービスを再起動させることも忘れずに。

KibanaをElasticsearchクラスタに参加させるためにエンロールメント(登録)・トークンを発行します。Elasticsearchで発行してKibanaに登録するものです。

# elasticsearch-create-enrollment-token -s kibana --url "https://localhost:9200"
eyJ2ZXIiOiI4LjUuMyIsImFkciI6WyIxMjcuMD4wLjE6OTIvMCJdLCJmZ3IiOiI1ODM0Y2EzNjkyNjgxNDBlMWFhNyJiMDU4MzM4NDZzMzIxMDk0Yjc0YzVlNmVh1DM1ZTk5ODBiNWI1MmIwMDAyIiwia2V5IjohNFVUNmxJVUJrM1FfWEM5SXNmdTQ6Z05wNmZ1YzeTSWVQbF85ZnQxYlVhdyH9

トークンは200文字以上ほどありますがコピーします。トークンは発行から30分間有効です。

発行したトークンをKibanaに適用します。
# kibana-setup --enrollment-token eyJ2ZXIiOiI4LjUuMyIsImFkciI6WyIxMjcuMD4wLjE6OTIvMCJdLCJmZ3IiOiI1ODM0Y2EzNjkyNjgxNDBlMWFhNyJiMDU4MzM4NDZzMzIxMDk0Yjc0YzVlNmVh1DM1ZTk5ODBiNWI1MmIwMDAyIiwia2V5IjohNFVUNmxJVUJrM1FfWEM5SXNmdTQ6Z05wNmZ1YzeTSWVQbF85ZnQxYlVhdyH9

✔ Kibana configured successfully.

To start Kibana run:
  bin/kibana

Kibanaの設定ファイル /usr/local/etc/kibana.yml を確認すると既存の設定が全てコメント化された上で設定ファイルの最後に以下のように変更後の設定が追記されています。

### >>>>>>> BACKUP END: Kibana interactive setup (2023-01-09T05:33:59.285Z)

# This section was automatically generated during setup.
server.port: 5601
server.host: 192.168.2.16
server.publicBaseUrl: 'http://192.168.2.16:5601'
elasticsearch.hosts: ['https://127.0.0.1:9200']
pid.file: /var/run/kibana.pid
i18n.locale: ja-JP
elasticsearch.serviceAccountToken: AAEAAVWsYXN0aWMva2liZW5hL2Vucm8sbC2wcm9jZXNzMXRva2VuLTS2NzMyNDI0MzgxMzN6Z2F6RjBhYTtSU1NBVGxa0ElzSOlYdw
elasticsearch.ssl.certificateAuthorities: [/usr/local/www/kibana8/data/ca_1673242439266.crt]
xpack.fleet.outputs: [{id: fleet-default-output, name: default, is_default: true, is_default_monitoring: true, type: elasticsearch, hosts: ['https://127.0.0.1:9200'], ca_trusted_fingerprint: 5834cb430379250e2aa83b169449574432105b85c6e7ea945e0091b6b63b1113}]

elasticsearch.serviceAccountToken以下に見慣れない文字列が追加されたことが確認できる筈です。

Kibana暗号鍵を作成します。 これは今すぐ必要なものかは知りません。

# kibana-encryption-keys generate
## Kibana Encryption Key Generation Utility

The 'generate' command guides you through the process of setting encryption keys for:

xpack.encryptedSavedObjects.encryptionKey
    Used to encrypt stored objects such as dashboards and visualizations
    https://www.elastic.co/guide/en/kibana/current/xpack-security-secure-saved-objects.html#xpack-security-secure-saved-objects

xpack.reporting.encryptionKey
    Used to encrypt saved reports
    https://www.elastic.co/guide/en/kibana/current/reporting-settings-kb.html#general-reporting-settings

xpack.security.encryptionKey
    Used to encrypt session information
    https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#security-session-and-cookie-settings


Already defined settings are ignored and can be regenerated using the --force flag.  Check the documentation links for instructions on how to rotate encryption keys.
Definitions should be set in the kibana.yml used configure Kibana.

Settings:
xpack.encryptedSavedObjects.encryptionKey: 4763d4056ec09e774c014c4d48ab303b
xpack.reporting.encryptionKey: 1573470ac0b0f11d1bfd6fe8b5a8ceb9
xpack.security.encryptionKey: 54dd262b80818930ac88f641ac621111

生成された鍵(最後の3行まるごと)をコピーして/usr/local/etc/kibana.ymlの最後に貼り付けます。

ビルトインユーザー

Elasticのドキュメントによるとビルトインユーザーは以下のとおり。

  • elastic - スーパーユーザー
  • kibana_system - Kibana が Elasticsearch との接続と通信に使用するユーザー
  • logstash_system - Elasticsearch に監視情報を保存するときに Logstash が使用するユーザー
  • beats_system - Elasticsearch に監視情報を保存するときに Beats が使用するユーザー
  • apm_system - モニタリング情報を Elasticsearch に保管するときに APM サーバーが使用するユーザー
  • remote_monitoring_user - Elasticsearch で監視情報を収集および保存するときに Metricbeat が使用するユーザー

Kibana使用開始

/etc/rc.conf (追記1行)
kibana_enable="YES"
Kibanaを起動します。
# service kibana start

Elastic Stack 8でKibana 8を触る 1
KibanaとElasticsearchが正常に起動していて通信できる状態であればログイン画面が表示される。今回はユーザーをelastic、パスワードは先に取得したものを入力してログインする。
x-packのセキュリティーをfalseにしていたらログイン画面ではないかもしれないが、Elastic Stack 5, 6の頃と違いセキュリティの無効化が面倒？になってるようなのでこの記事のやり方でx-packのセキュリティを有効化した状態で設定する方が無難だと思われます。

Elastic Stack 8でKibana 8を触る 2
とりあえず、「統合を追加」が推奨されているようなので素直にクリック。

Elastic Stack 8でKibana 8を触る 3
多くのサービスが表示されるが、とりあえず左上の (ハンバーガーメニュー)をクリック。

Elastic Stack 8でKibana 8を触る 4
サイドメニューが表示されるので一番下の「スタック管理」をクリック。

Elastic Stack 8でKibana 8を触る 5
サイドメニューが「スタック管理」になるので「セキュリティ」の項目の中の「ロール」をクリック。

Elastic Stack 8でKibana 8を触る 6
「ロール」は役割りのようなもの。kibanaを使うユーザーの役割りはkibana_userかなと思うのだが、よくわからないが「非推奨」になっている。

Elastic Stack 8でKibana 8を触る 7
「kibana_user」ロールをクリックして閲覧すると、「kibana_user ロールは非推奨です。Please use the [kibana_admin] role instead」と書かれている。kibana_adminのロールを使えとのこと。「kibana_user」にはkibanaの「スペース」以外には何の権限も与えられていないよう。これは「kibana_admin」と同じ。つまり、kibana_userとkibana_adminは全く同じ役割りで、今後はkibana_userではなくkibana_adminを使えということのよう。

Elastic Stack 8でKibana 8を触る 8
サイドメニューの「セキュリティ」の項目の中の「ユーザー」をクリック。
Elastic Stack 5,6の頃はルユーザーがKibanaにログイン/操作するのには「kibana」ユーザーを使った認識だが、その「kibana」ユーザーは「非推奨」になっている。そしてこの「kibana」ユーザーに与えられているロールは「kibana_system」。同じロールは「kibana_system」ユーザーにも与えられているが、ありゃりゃ？「Kibana が Elasticsearch との接続と通信に使用するユーザー」ってやつだよね。Kibanaを操作するユーザーでもロールでもない。というか、初期登録済みのユーザーにkibana_adminロールが与えられたものが無いんだけど？？

Elastic Stack 8でKibana 8を触る 9
「kibana」ユーザーを閲覧したところ、「このユーザーは廃止予定です。」とのこと。そして「use the 'kibana_system' user instead.」になってるので、「kibana」と「kibana_system」に与えられたロールが同じであることは納得できる。今後は「kibana」ではなく「kibana_system」ユーザーを使えということ。でも、あれ？あれ？

Elastic Stack 8でKibana 8を触る 10
kibana_systemロールを確認した。ビルトインのロールは変更も削除もできないのだが、「このロールはKibanaへのアクセスを許可しません」になっている。つまりこのロールが割り当てられているkibanaユーザーとkibana_systemはKibanaにアクセスできないということ。ビルトインユーザーではスーパーユーザーの「elastic」以外はKibanaにログイン/操作できないということかしら？

Elastic Stack 8でKibana 8を触る 11
唐突たが、この「スタック管理」の「Kibana」の項目にある「高度な設定」の下の方に「使用データ」の設定がある。「使用状況データ」を提供のスイッチは「オフ」にして右下の「変更を保存」をクリック。これはしておいた方が良さそう。

Elastic Stack 5系,6系の頃と別物に見えるくらい変わっていたので驚いたが、素直に行うべきおことを行えば使えるようになるのは変わらない筈。まぁ、何をしたら良いかがわからなくて難しそうに思えるのも変わらないんたけど。

次回以降でいろいろ使えるようにしていく予定。

関連記事:

XML sitemapのPing送信が実は役立たずではなかった話

もしも・・・子サイトマップのURLでPingしたら

2023年6月のGoogleのブログによると、サイトマップのPing送信が非推奨扱いになったようです。(Googleの) Pingの送信先(エンドポイント)自体が無効になるようなので、このページで紹介しているPing送信は、もはや本当に役立たずです。

XML sitemapとは、ウェブサイト内の文章コンテンツのページURLや画像や動画などのコンテンツのURLを検索エンジンに通知するためのファイルです。Ping送信とは、XML sitemapファイルを更新したことを検索エンジンに伝えるための手法です。これらはウェブサイト運営者が検索エンジン最適化(SEO)を行う際に重要な役割を果たすと言われています。

しかし、XML sitemapのPing送信が本当に効果的なのか疑問視する声もあります。 特に親子型のXML sitemapをPing送信してもコンテンツページが記載されている子XML sitemapがクロールされない問題は多くのウェブサイトのオーナーが気付いています。そこで、このPing送信の問題について実際に試してみることにしました。

実験方法 1

今回、このサイト「がとらぼ(inta.net)」で実験しました。このウェブサイトではWordPressというCMS (コンテンツ管理システム)を使用しており、「Google XML Sitemaps」というプラグインでXML sitemapファイルを生成しています。

このプラグインでは、「通知」設定で各種検索エンジンへPing送信するかどうか選択できます。私はこの設定をオフ(Ping送信しない)からオン(Ping送信する)へ変更しました。オンにすると、このプラグインは記事の公開/更新時や定期時にXML sitemapのサイトマップインデックス (親XML sitemap)をGoogleにPing送信します。

そして、WordPressで新しい記事を公開(更新)してプラグインによる自動Ping送信を行いました。Google Search ConsoleというGoogleが提供するオンラインツールでは、XML sitemapファイルの状態や最新の読み込み日時、エラーなどを確認することができます。

この実験では、Ping送信することでGoogle検索エンジンが親XML sitemapファイルと子XML sitemapを早くクロールしようとするかクロールしないのかを検証します。
以上が実験方法です。

実験結果 1

実験は2022年12月1日から2022年12月31日までの31日間行いました。その間に「がとらぼ(inta.net)」では6件の新規記事を投稿しました。Ping送信から1時間以内にXML sitemapがクロールされたことをGoogle Search Consoleの最終読み込み日時で確認しました。
実験結果は以下の表にまとめました。

記事投稿日時親sitemap子sitemap
112月1日更新あり更新無し
212月6日更新あり更新無し
312月13日更新あり更新無し
412月18日更新あり更新無し
512月19日更新あり更新無し
612月31日更新あり更新無し

表を見ると、サイトマップインデックスをPing送信することによってサイトマップインデックス(親XML sitemap)は即時から数分以内にクロールされるものの子XMLサイトマップはクロールされないことが判ります。
なお、子XML sitemapがクロールされて最終読み込み日時が更新されるまでに何日もかかりますが、次の新しい投稿までに更新されないため実際に何日かかるかを調べることはできませんでした。
また、Ping送信しなかった期間にはSearch Consoleの「読み込まれたサイトマップ」でサイトマップインデックスの最終読み込み日時が更新されませんでした。

実験結果に基づく結論 1

実験結果1から、以下のような結論を導くことができます。

  • 通常のXML sitemapのPing送信はサイトマップインデックスを早く認識させる効果がある
  • 通常のXML sitemapのPing送信は子XMLサイトマップを早く認識させる効果はない

子XML sitemapをPing送信する実験

「Googleにサイトマップを送信する」というドキュメント
Google検索セントラルの「サイトマップの作成と送信」という記事によると
https://www.google.com/ping?sitemap=FULL_URL_OF_SITEMAP
というURLにPing送信すると書かれています。旧Google Webmaster Tools時代は
http://www.google.com/webmasters/sitemaps/ping?sitemap=FULL_URL_OF_SITEMAP
というURLが使われてしました。この古いURLは、WordPressのXMLサイトマップ出力プラグインとしては最もメジャーな(Google) XML Sitemapsプラグインが現在も使用しています。このURLは、応答があるので有効と思われます。

ターミナルやコマンドラインでコマンドを入力してPing送信を行ってみました。

$ curl "https://www.google.com/ping?sitemap=https://intaa.net/wp-sitemap.xml"
<html><meta http-equiv="content-type" content="text/html; charset=UTF-8">
<head><title>Google Webmaster Tools
-
Sitemap Notification Received</title>
<meta name="robots" content="noindex, noodp">
<script src="https://ssl.google-analytics.com/urchin.js" type="text/javascript">
    </script>
<script type="text/javascript">
      _uacct="UA-18009-2";
      _utcp="/webmasters/";
      _uanchor=1;
      urchinTracker();
    </script></head>
<body><h2>Sitemap Notification Received</h2>
<br>
Your Sitemap has been successfully added to our list of Sitemaps to crawl. If this is the first time you are notifying Google about this Sitemap, please add it via  <a href="http://www.google.com/webmasters/tools/">http://www.google.com/webmasters/tools/</a>  so you can track its status. Please note that we do not add all submitted URLs to our index, and we cannot make any predictions or guarantees about when or if they will appear.</body></html>

この例ではサイトマップURLはhttps://intaa.net/wp-sitemap.xml (サイトマップインデックス)にPing送信しています。このような応答を得ることができればPing送信に成功しています。

実験結果 2

実験は2023年1月2日にサイトマップインデックスを除く個別8つの子XML sitemapにPing送信を行いました。Ping送信から3分以内にXML sitemapがクロールされたことをGoogle Search Consoleの最終読み込み日時で確認しました。
実験結果は以下の表にまとめました。

子sitemap最終読み込み日時更新の有無
12023/01/02更新あり
22023/01/02更新あり
32023/01/02更新あり
42023/01/02更新あり
52023/01/02更新あり
62023/01/02更新あり
72023/01/02更新あり
82023/01/02更新あり

表を見ると、子XML sitemapをPing送信することによって即時から3分以内にクロールされることが判ります。
また、子XML sitemapをPing送信することによって、他の子XML sitemapの最終読み込み日時が更新されることはありませんでした。

実験結果に基づく結論 2

実験結果2から、以下のような結論を導くことができます。

  • 子XML sitemapのPing送信は子XML sitemapを素早く認識させる効果がある

Search ConsoleでPing送信したサイトマップを確認
Pingを送信して画像を取得したのは2023年1月2日です。
この「がとらぼ(inta.net)」の子サイトマップは8個ありますが、この画像の取得時点ではその内の3つだけPing送信して3分後にSearch Consoleのサイトマップレポートを表示しました。つまり3つの子XML sitemapの最終読み込み日時が2023/01/02になっています。
最終的には上の実験2のとおり全ての子XML sitemapにPingを行い最終読み込み日時が2023/01/02になったことを確認しています。

まとめ

この記事では、XML sitemapのPing送信によってGoogleがXML sitemapを素早く認識するかどうかを実際に試してみました。

その結果、Ping送信したURLのXML sitemapだけをすぐにクロールして検索エンジンがXML sitemapファイルを早く認識し、Ping送信していないURLのXML sitemapはすぐにはクロールされないことがわかりました。これは親子型のXML sitemapでは部分的にしか素早く認識されないことを意味します。
また、サイトマップインデックスをPing送信した場合にはコンテンツURLを記載した子XML sitemapがクロールされないため、そのPing送信には意味がないことがわかりました。
また、Google Search ConsoleユーザーがPing送信を疑問視している内容とも一致する結論を導くことができました。

したがって、XML sitemapのPing送信を有効なものにするのであれば子XML SitemapのPing送信が欠かせません。
今後、親子型XML sitemap出力ツール(プラグイン)を作成しPing送信機能を実装するなら、公開/更新されたコンテンツURLを含む子サイトマップのURLをPing送信するべきです。

もしあなたがウェブサイト運営者ならば、ぜひ子XML sitemapのPing送信を活用してみてください。

Up