ラズパイ4にElasticsearch+Kibanaインストール
暇だったのでラズパイ4にElaticsearchとKibanaをインストールしたときのメモ。
ちなみにすでにラズパイ4にはCentOS8が入っていてJava11もインストール済み。
Java8以降が必須になるみたいなので、ない場合は事前にインストールしておく。
すごくレベルの低い記事だと思う。
インストール
インストール方法を書こうかと思ったけど公式が正義なので割愛。
インストール手順を書いてもいずれ古くなるのでこういう場合は書かない方がいいと思う。
英語力0でも基礎中の基礎のLinuxの知識があれば問題なし。
Kibanaのインストール
Elasticsearchのインストール
firewall設定
# firewall-cmd --add-port=5601/tcp --permanent # firewall-cmd --reload
http://192.168.11.17:5601/ でブラウザにアクセスしてKibanaが表示されれば問題なし。
ハマったところ
Kibana server is not ready yet
公式の手順を踏まずに適当にインストールしてみたらKibanaの動作確認中にエラー発生。
ブラウザで表示したところ「Kibana server is not ready yet」とでる。
activeになっているのに何故？
# systemctl status kibana.service
● kibana.service - Kibana
Loaded: loaded (/etc/systemd/system/kibana.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-05-29 07:44:43 UTC; 4s ago
Docs: https://www.elastic.co
Main PID: 370443 (node)
Tasks: 14 (limit: 23888)
CGroup: /system.slice/kibana.service
├─370443 /usr/share/kibana/bin/../node/bin/node /usr/share/kibana/bin/../src/cli/dist --logging.dest=/var/log/kibana/kibana.log --pid.file=/run/kibana/kibana.pid
└─370455 /usr/share/kibana/node/bin/node --preserve-symlinks-main --preserve-symlinks /usr/share/kibana/src/cli/dist --logging.dest=/var/log/kibana/kibana.log --pid.file=/run/kibana/kibana.pid
ログを確認してみると以下の記載があった。
{"type":"log","@timestamp":"2021-05-29T07:38:29+00:00","tags":["error","savedobjects-service"],"pid":370285,"message":"This version of Kibana (v7.13.0) is incompatible with the following Elasticsearch nodes in your cluster: v7.10.2 @ 127.0.0.1:9200 (127.0.0.1)"}
ElasticsearchとKibanaのバージョンが異なっているとのこと。 これは公式の手順通りreinstallすれば直った。
Kibana起動失敗
# systemctl start elasticsearch.service Job for elasticsearch.service failed because the control process exited with error code. See "systemctl status elasticsearch.service" and "journalctl -xe" for details.
journalctl -xe で確認詳細を確認しろとでているが、ログを見た方が早かった
cat /var/log/elasticsearch/elasticsearch.log
Caused by: java.nio.file.AccessDeniedException: /var/lib/elasticsearch/nodes/0/node.lock
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:182) ~[?:?]
at java.nio.channels.FileChannel.open(FileChannel.java:292) ~[?:?]
at java.nio.channels.FileChannel.open(FileChannel.java:345) ~[?:?]
at org.apache.lucene.store.NativeFSLockFactory.obtainFSLock(NativeFSLockFactory.java:125) ~[lucene-core-8.8.2.jar:8.8.2 a92a05e195b775b30ca410bc0a26e8e79e7b3bfb - mdrob - 2021-04-06 16:33:27]
at org.apache.lucene.store.FSLockFactory.obtainLock(FSLockFactory.java:41) ~[lucene-core-8.8.2.jar:8.8.2 a92a05e195b775b30ca410bc0a26e8e79e7b3bfb - mdrob - 2021-04-06 16:33:27]
at org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45) ~[lucene-core-8.8.2.jar:8.8.2 a92a05e195b775b30ca410bc0a26e8e79e7b3bfb - mdrob - 2021-04-06 16:33:27]
at org.elasticsearch.env.NodeEnvironment$NodeLock.<init>(NodeEnvironment.java:207) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:262) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.node.Node.<init>(Node.java:368) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.node.Node.<init>(Node.java:278) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:217) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:217) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:397) ~[elasticsearch-7.13.0.jar:7.13.0]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) ~[elasticsearch-7.13.0.jar:7.13.0]
どうやらlockファイルにアクセスできていない模様だったので下記を実行。
chown -R elasticsearch:elasticsearch /var/lib/elasticsearch
これで素直に起動できました。
# systemctl status kibana.service
● kibana.service - Kibana
Loaded: loaded (/etc/systemd/system/kibana.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2021-05-29 08:06:23 UTC; 6s ago
Docs: https://www.elastic.co
Main PID: 371737 (node)
Tasks: 14 (limit: 23888)
CGroup: /system.slice/kibana.service
├─371737 /usr/share/kibana/bin/../node/bin/node /usr/share/kibana/bin/../src/cli/dist --logging.dest=/var/log/kibana/kibana.log --pid.file=/run/kibana/kibana.pid
└─371749 /usr/share/kibana/node/bin/node --preserve-symlinks-main --preserve-symlinks /usr/share/kibana/src/cli/dist --logging.dest=/var/log/kibana/kibana.log --pid.file=/run/kibana/kibana.pid
SEOメモ②
2021/5月からGoogleの検索順位にCoreWebVitalsが影響すると正式に発表された。
CoreWebVitalsが何の指標なのかは各所で言及されているので特筆しないし、ユーザにメリットがあるようにサイト構築をするのはSEO対策の基本。
ちなみに各指標についてはweb.devを参考にするのが一番いい。
今回はWebページの高速化のため改善事項を探るTipsみたいなものをメモする。
まずはPageSpeedInsightで各種指標を確認する。
はてなブログの場合、テンプレートによって差異が発生するが、現状はこんな感じ。
LCPの値が悪い。LCPが悪化する要因はだいたい以下。
- サーバのレスポンス速度が遅い
- レンダリングブロックが発生している。
- CSS/JavaScript等のリソースが重い
CSS/JavaScript等のリソースが重い
ここで気をつけたいのは minifiy しているかや、gzip圧縮をしているか、不要な記述がないか等を探る。
CSS/JavaScriptの不要な記述削除は困難。そもそも大量のファイルをloadしているようなサイト(ページ)だと原因箇所を特定しにくい。
Chrome dev tools の Coverageを使うとわかりやすい。
Coverageパネルはデフォルトだと非表示になっているので RunCommandから「coverage」と入力して表示させる。
「Usage Visualization」の赤いバー不要。
「Unused Bytes」の降順でソートできたりもして便利。
広告を貼っているサイトだと改善のしようながないがあるので、「URL filter」に自サイトのドメイン等を入力してフィルタリングしてあげると見つけやすい。
SEOメモ①
SEOについて勉強する機会があったのでメモしておく。
SEO対策についてはど素人ですが、「目に見えてダメな部分を直す」が特効薬として機能し、基本的には「コンテンツの質を高める」ことが重要。
何かを対策してみたところで目に見えて改善されるケースは少ない（気がする）。
MFI
モバイルファーストインデックスのこと。
2015/4月に実施されたモバイルフレンドリーアップデートから始まる。
スマホで読みやすいページが有利になり、その逆であったりそもそもスマよようのページがない場合はGoogleのオーガニック検索で順位を落とすことになった。
MFIと呼ばれるようになったのは以下の2016年に実施されたアップデートから。
上記のリンクより引用
そこでユーザーにとってさらに価値ある検索結果を提供するために、Google ではモバイル ファーストのインデックス登録に向けた実験を開始しています。Google 検索のインデックスは、サイトやアプリについての単一のインデックスとして存続しますが、将来的に Google のアルゴリズムはモバイル版のコンテンツを主に使用するようになります。つまり、ページのランキングを決定したり、構造化データを理解したり、検索結果にスニペットを表示する際も、モバイル版のコンテンツが使用されるようになります。もちろん、Google のインデックスがモバイル版のコンテンツで形成されるようになっても、デスクトップ端末かモバイル端末かに関わらず、すべてのユーザーに素晴らしい検索体験を提供し続ける点は変わりません。
ざっくり言うとこれまでPC版のページを評価していたが、スマホ版(向け)のページを評価するようになり、今後スマホ版のページが検索結果に入ってくるというもの。
2019/7移行は全ての新規ウェブサイトはデフォルトでMFIの対象。以前から存在するウェブサイトについてはGoogleが評価して切り替わっていく。
MFIに移行したかどうかはSearchConsoleで確認可能。
MFIに移行するとスマホのQAを持つクローラがインデックスし始める。完全にPC版のクローラが来ないというわけではないが、インデックスはされるコンテンツは1つなので検索結果に乗るページは徐々にスマホ版へと切り替わっていく。
リッチリザルト
構造化データとも呼ばれる。
リッチリザルトとその名前の通り、「検索結果でリッチに表示される」もので検索結果の順位そのものには基本的に影響しない。
ただ、コンテンツの質が上がったと解釈されて影響がでる可能性もある。
品質に関するガイドラインも規定されているので、誤った情報を記載すれば悪影響もある。
様々な構造化データタイプがあるので自身のウェブページにあったものを選択して実装する。
実装した結果はリッチリザルトテストで検証することができる。
ただし、クローラが到達できるウェブサイトであることが条件になるのでdevelop環境等のクローズドな環境では使用できない。
リリース前に確認するにはコードスニペットを使用して確認できるのでそちらを使用する。
CentOS8環境にdockerを入れる
docker入れたい
dnfコマンドを使って入れていく。
本当はansibleで入れてみたかったけどとりあえず動かしたいので入れる。
repository登録
$ dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo Adding repo from: https://download.docker.com/linux/centos/docker-ce.repo
$ dnf repolist repo id repo name appstream CentOS Linux 8 - AppStream baseos CentOS Linux 8 - BaseOS docker-ce-stable Docker CE Stable - aarch64 extras CentOS Linux 8 - Extras [root@localhost ~]# dnf -y install docker-ce docker-ce-cli containerd.io Docker CE Stable - aarch64 24 kB/s | 9.2 kB 00:00 Last metadata expiration check: 0:00:01 ago on Sun 07 Feb 2021 10:18:59 AM UTC. Dependencies resolved. ======================================================================================================================================================================================================================= Package Architecture Version Repository Size ======================================================================================================================================================================================================================= Installing: containerd.io aarch64 1.4.3-3.1.el8 docker-ce-stable 26 M docker-ce aarch64 3:20.10.3-3.el8 docker-ce-stable 18 M docker-ce-cli aarch64 1:20.10.3-3.el8 docker-ce-stable 29 M Installing dependencies: checkpolicy aarch64 2.9-1.el8 baseos 338 k container-selinux noarch 2:2.144.0-1.module_el8.3.0+475+c50ce30b appstream 49 k docker-ce-rootless-extras aarch64 20.10.3-3.el8 docker-ce-stable 8.3 M fuse-overlayfs aarch64 1.1.2-3.module_el8.3.0+507+aa0970ae appstream 62 k fuse3-libs aarch64 3.2.1-12.el8 baseos 90 k libcgroup aarch64 0.41-19.el8 baseos 68 k libslirp aarch64 4.3.1-1.module_el8.3.0+475+c50ce30b appstream 65 k policycoreutils-python-utils noarch 2.9-9.el8 baseos 251 k python3-audit aarch64 3.0-0.17.20191104git1c2f876.el8 baseos 84 k python3-libsemanage aarch64 2.9-3.el8 baseos 124 k python3-policycoreutils noarch 2.9-9.el8 baseos 2.2 M python3-setools aarch64 4.3.0-2.el8 baseos 528 k slirp4netns aarch64 1.1.4-2.module_el8.3.0+475+c50ce30b appstream 49 k tar aarch64 2:1.30-5.el8 baseos 829 k Enabling module streams: container-tools rhel8 Transaction Summary ======================================================================================================================================================================================================================= Install 17 Packages ... Installed: checkpolicy-2.9-1.el8.aarch64 container-selinux-2:2.144.0-1.module_el8.3.0+475+c50ce30b.noarch containerd.io-1.4.3-3.1.el8.aarch64 docker-ce-3:20.10.3-3.el8.aarch64 docker-ce-cli-1:20.10.3-3.el8.aarch64 docker-ce-rootless-extras-20.10.3-3.el8.aarch64 fuse-overlayfs-1.1.2-3.module_el8.3.0+507+aa0970ae.aarch64 fuse3-libs-3.2.1-12.el8.aarch64 libcgroup-0.41-19.el8.aarch64 libslirp-4.3.1-1.module_el8.3.0+475+c50ce30b.aarch64 policycoreutils-python-utils-2.9-9.el8.noarch python3-audit-3.0-0.17.20191104git1c2f876.el8.aarch64 python3-libsemanage-2.9-3.el8.aarch64 python3-policycoreutils-2.9-9.el8.noarch python3-setools-4.3.0-2.el8.aarch64 slirp4netns-1.1.4-2.module_el8.3.0+475+c50ce30b.aarch64 tar-2:1.30-5.el8.aarch64 Complete!
dockerのサービス登録
[root@localhost ~]# systemctl start docker
[root@localhost ~]# systemctl enable docker
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service.
[root@localhost ~]# systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2021-02-07 10:21:44 UTC; 9s ago
Docs: https://docs.docker.com
Main PID: 3783 (dockerd)
Tasks: 13
CGroup: /system.slice/docker.service
└─3783 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
Feb 07 10:21:42 localhost dockerd[3783]: time="2021-02-07T10:21:42.099871862Z" level=warning msg="Your kernel does not support cgroup blkio weight"
Feb 07 10:21:42 localhost dockerd[3783]: time="2021-02-07T10:21:42.099895528Z" level=warning msg="Your kernel does not support cgroup blkio weight_device"
Feb 07 10:21:42 localhost dockerd[3783]: time="2021-02-07T10:21:42.100400981Z" level=info msg="Loading containers: start."
Feb 07 10:21:43 localhost dockerd[3783]: time="2021-02-07T10:21:43.366532114Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferr>
Feb 07 10:21:43 localhost dockerd[3783]: time="2021-02-07T10:21:43.650196576Z" level=info msg="Firewalld: interface docker0 already part of docker zone, returning"
Feb 07 10:21:43 localhost dockerd[3783]: time="2021-02-07T10:21:43.969715664Z" level=info msg="Loading containers: done."
Feb 07 10:21:44 localhost dockerd[3783]: time="2021-02-07T10:21:44.080269229Z" level=info msg="Docker daemon" commit=46229ca graphdriver(s)=overlay2 version=20.10.3
Feb 07 10:21:44 localhost dockerd[3783]: time="2021-02-07T10:21:44.080964865Z" level=info msg="Daemon has completed initialization"
Feb 07 10:21:44 localhost systemd[1]: Started Docker Application Container Engine.
Feb 07 10:21:44 localhost dockerd[3783]: time="2021-02-07T10:21:44.190011069Z" level=info msg="API listen on /var/run/docker.sock"
[root@localhost ~]# docker --version
Docker version 20.10.3, build 48d30b5
Raspberry Pi4 ModelBにCentOS8を入れてみた
準備するもの
- Raspberry Pi
- 有線LAN
- キーボード
- マウス
- Raspberry Pi Imager(なくてもいい)
MicroSDにCentOS8のイメージを書き込む
公式のサイトから CentOSのイメージをダウンロード。
今回使用したのは CentOS-Userland-8-stream-aarch64-RaspberryPI-Minimal-4-sda.raw
ググってみるとこのイメージをddコマンドで書き込む記事が多かったけど、起動しなかったので別の手法をとる。
ずっとRaspberry Piが緑色のランプが点滅し続けていたのでうまく読み込みができていないみたいでした。
なのでRaspberry Pi Imagerを使いました。公式サイトからダウンロードします。
UIはシンプルで分かりやすいです。 ダウンロードしたイメージを選択するだけ。
MicroSDは勝手に認識します。
「WRITE」を押したら数分待ちます。
書き出しが終わればRaspberry PiにSDカードを入れて起動するだけ。
ddコマンドでは失敗しましたが、imagerを使うとうまく起動しました。
何が違うかは謎。公式から便利なツールが出ていることがわかったのでまぁよしとします。
カラフルな画像が表示されてからCLIに入ります。
デフォルトは root ユーザでパスワードはcentosです。
念のためpasswdコマンドで任意のパスワードに変更しておきました。
Raspberry Pi4は無線LANが使用できますが、モジュールが足りないのでダウンロードしてくる必要があります。
なので初回だけ有線LAN必須。
自宅に余っている有線LANがなかったので次はその手順をメモします。
Java並列処理実装について
軽くJavaの並列処理の実装について調べてみたのでメモしておく。
Javaのスレッド
基本的には1coreあたり1スレッドしか動作できないためスレッドを切り替えて動作することになる。
このスレッドの切り替えのことをコンテキストスイッチという。
コンテキストスイッチ
コンテキストスイッチを行うためにはスレッドが動いていた状態を再開するために保存しておく。
つまりメモリに状態を保存しておくことになる。
また、コンテキストスイッチには約1~100マイクロ秒かかるこの時間にはスレッドの処理時間は含まれていない。
並列処理をしてもコンテキストスイッチが頻繁に起こるようになればここがボトルネックとなり並列処理を実装してもアプリケーションの性能劣化を招く。
タスクの並列度はコア数を前提として考えなければならない。
スタックサイズ
64bit環境のJVMのデフォルトのスタックサイズは1MB。
つまり、1k個のスレッドは1GBのRAMを消費することになる。
Javaの並列処理実装へのアプローチ
実際にwhile loopの中で大量にThreadを作成するテストコードを書いてみるとOutOfMemoryエラーが発生した。
これはThreadの作成に失敗したことを意味しているらしい。
実際に仕事で並列処理を使うことは多そうなのでこのようなエラーに遭遇しないためにも適切なアプローチを学びたい。
java.lang.Thread
Java1.0からある老舗のクラス。
Javaの並列処理は全てこのクラスがベースになっている。
public class ExcecuteThread extends Thread{ public void run() { // 実行したい処理 } } } // こんな感じで実行 public class Main { public static void main(String[] args) { ExcecuteThread thread = new ExcecuteThread(); thread.start(); } }
このようにスレッドとタスクは1対1の関係性を伴う。
Threadクラスはどこでも作成でき、どこからでも実行することが可能だが、Threadの実行タイミングや現在実行されているスレッド数の管理が大変。
なのでThreadクラスを生で使うのではなくてAPIを使用して実装した方がよいとのこと
Parallel Stream
Streamの並列処理版というらしい。Java8から導入。
public class Main { public static void main(String[] args) { List<Integer> list = new ArrayList<>(); int num = 0; while(num < 1000) { list.add(num); num++; } list.parallelStream().forEach(i -> System.out.println(i)); } }
面白くも何もないコードですが、こんな感じでテストコードを書いてみました。
実行結果は並列処理なので順序はめちゃくちゃです。
streamをparallelStreamにすればいいだけなので簡単な実装ですが、実際には使い所がある模様。
並列処理をする要素数が多ければパフォーマンスの向上が見込めるが、逆に少ないとパフォーマンスとしては逐次実行より劣化するとのこと。
これはテストコードでいうところのlist変数の中の要素を分割してから並列処理と終端操作を行うためとのこと。
要素を分割するということは要素数が決まっていないlistなどに対しては要素の分割操作ができないためparallelStreamは使えないということ。
parallelStreamについては以下にベンチマーク結果があるみたいです。
