LoginSignup
4
3

[OpenShift Virtualization] ロギングってどうなるの?syslog取得&OpenShift Loggingとの統合具合

Last updated at Posted at 2024-06-04

はじめに

今回はOpenShift Virtualizationのロギング周りについて挙動を確認していきます。
ざっくり2つの観点で見ていきます。

  • syslog周りの運用
  • OpenShift Loggingとの統合具合を確認

また、これらを試す過程で、OpenShift上のVMにyumでパッケージをインストールしてみたり、VMをインターネットに公開したりといった事も試します。

syslog周りの運用

まずはsyslogの取得についてです。前回の記事で2台のVMを同じOverlay Networkに接続して疎通させた内容を活かしてやってみます。1台のVMlog-exportervar/log/messageをもう1台のVMlog-serverに転送できるのかを実験します。

image.png

先に結論を言ってしまうと、特に何の問題も無くできます。つまり、これまでの仮想マシンのロギング運用は、OpenShift Virtualizationにおいても変わりなく実行できると言えます。

やってみます。

Fedora VMを2台起動

前回の記事を参考にして、Fedora VMを2台建てます。ホスト名と2つめのvNICに振る静的IPアドレスについては以下のようにしておきました。

  • fedora-log-exporter: 192.168.100.11/24
  • fedora-log-server: 192.168.100.21/24

fedora-log-exporterを設定

Fedoraはデフォルトだとvar/log/messageが存在しないため、まずはrsyslogをインストールしておきます。前回の記事を参考にして、fedora-log-exporterにローカルマシンからSSHして操作します。

[fedora@fedora-log-exporter ~]$ sudo yum install rsyslog -y
[fedora@fedora-log-exporter ~]$ systemctl start rsyslog.service
[fedora@fedora-log-exporter ~]$ systemctl enable rsyslog.service

OpenShift Virtualization上のRed Hat系Linuxはyumコマンドで「Redhat Package Manage(RPM)」 を用いたパッケージのインストールも問題なくできます。

一応rsyslogが動いているか、tailコマンドでみておきます。

[fedora@fedora-log-exporter ~]$ sudo tail /var/log/message
May 31 00:44:40 fedora-log-exporter systemd[1]:hogehoge

大丈夫っぽいです。次に、fedora-log-exporterをHTTPサーバとして起動させることにします。

[fedora@fedora-log-exporter ~]$ sudo yum install httpd -y
[fedora@fedora-log-exporter ~]$ sudo service httpd start
Redirecting to /bin/systemctl start httpd.service

良さげです。さて、せっかくなのでfedora-log-exporterで起動しているApacheにインターネットからアクセスしてみたいです。

VMをインターネットに公開する

OpenShift Virtualizationで起動しているVMは、その実態はPodであるとこちらの記事で触れました。つまり、Kubernetes/OpenShiftのリソースであるServiceRouteを使ってインターネットに公開できます。ここはこれまでOpenShiftを利用した事のある方からすると、とても自然だと思います。

今から以下の様にServiceRouteを付けます。

image.png

Serviceを使って80番ポートでExposeする

httpdはホストの80番ポートでアクセスを受け付けています。
VM詳細画面から実態であるPodの詳細画面に入ります。

image.png

すでにデフォルトでLabelが付いています。ホスト名で特定可能なvm.kubevirt.io/name=fedora-log-exporterSelectorにします。VMはNameSpace=virtual-machineにDeployしているので、以下のServiceも同じNameSpaceoc applyします。

service-fedora-log-exporter.yaml
apiVersion: v1
kind: Service
metadata:
  name: service-fedora-log-exporter
  namespace: virtual-machine
spec:
  selector:
    vm.kubevirt.io/name: fedora-log-exporter
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

これでCluster内部に対して、80番ポートでExposeされました。

Routeでインターネットに公開

次にRouteoc applyします。

route-fedora-log-exporter.yaml
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: route-fedora-log-exporter
  namespace: virtual-machine
spec:
  to:
    kind: Service
    name: service-fedora-log-exporter
  port:
    targetPort: 80

これでRouteからURLが払い出されました。アクセスしてみます。

image.png

無事、fedora-log-exporterがインターネットに公開されました。とても簡単でした!

fedora-log-exporterのログ転送設定をする

rsyslogの設定ファイルをいじって、fedora-log-server(IPアドレスは192.168.100.21)に対してudpの514番ポートで転送する設定をします。

[fedora@fedora-log-exporter ~]$ sudo nano /etc/rsyslog.conf

エディタが開いたら、以下の行を追加して保存 (ctrl+s)・終了 (ctrl+x) してください。
(もしtcpで転送したい場合は@が2つになります。)

*.* @192.168.100.21:514

どうしてもいつものクセでviエディタを使いがちですが、nanoエディタのほうが使い勝手良いし、普段のコピペも使えて便利です。若い人にはnanoで十分な気も...

設定変更を反映させる為にhttpdを再起動します。

[fedora@fedora-log-exporter ~]$ sudo systemctl restart rsyslog

これでfedora-log-exporter側の設定は完了です。

fedora-log-serverを設定

同様にfedora-log-serverにもrsyslogをインストールします。

[fedora@fedora-log-exporter ~]$ sudo yum install rsyslog -y
[fedora@fedora-log-exporter ~]$ systemctl start rsyslog.service
[fedora@fedora-log-exporter ~]$ systemctl enable rsyslog.service

fedora-log-serverにディレクトリとファイルを作成し、fedora-log-exporterから受信した/var/log/messageを格納する場所を用意しておきます。

[fedora@fedora-log-server ~]$ sudo mkdir /var/log/remote
[fedora@fedora-log-server ~]$ sudo touch message

続いて、fedora-log-server側でもログの受信設定をします。

[fedora@fedora-log-server ~]$ sudo nano /etc/rsyslog.conf

設定ファイルに以下の行を追加します。

module(load="imudp")
input(type="imudp" port="514")
if $fromhost-ip == '192.168.100.11' then /var/log/remote/messages
& stop

fedora-log-serverudp514番ポートがリッスンされ、192.168.100.11から受信したログはvar/log/remote/messageに格納される様に設定しました。

これにて、fedora-log-servervar/log/remote/messagefedora@fedora-log-exporter/var/log/messageが転送されるようになりました。

ではfedora-log-serverにSSHしてからログが転送されてくるか確認します。
その前に、fedora@fedora-log-exporterの方でなんらかログを発生させておきます。

[fedora@fedora-log-exporter ~]$ service httpd restart
Redirecting to /bin/systemctl restart httpd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to restart 'httpd.service'.
Authenticating as: fedora Cloud User (fedora)
Password: 
==== AUTHENTICATION COMPLETE ====
[fedora@fedora-log-exporter ~]$ 

sudo無しでhttpdを起動しようとしてrootPasswordを求められたので正しいPasswordを入力、無事httpdを起動しています。

さて、このログがfedora-log-serverでも確認できるでしょうか?

[fedora@fedora-log-server ~]$ sudo tail /var/log/remote/messages
May 31 12:30:12 fedora-log-exporter httpd[3609]: Server configured, listening on: port 80

取得できていそうです。ホスト名もfedora-log-exporter/var/log/messageが転送されています。VMがコンテナの中で動いているからと言ってこれまでのVMのロギング運用が変わってしまう事はないと言えるわけです。

OpenShift Loggingとの統合具合を確認

先に結論から言ってしまうと、VMの標準出力に出力されたログメッセージをOpenShift LoggingがApplication logとして取得することは、“現時点”(OpenShift ver4.15時点)ではできません。ちょっと試してみます。

log-testアプリをコンテナ/VMでDeployして挙動の差を見る

こちらNode.jsのアプリを用意しました。OpenShift上にNameSpace=log-testを作り、コンテナとしてDeployしました。方法はSource to Image(S2I)でも、DockerfileでもOK。

image.png

Routeからアクセスするとこんな感じです。

image.png

現在アプリが起動しているホスト名(コンテナの場合はPod名)が表示され、入力フォームが存在します。この入力フォームに文字列を入力してSubmitします。

image.png

すると、入力した文字列が標準出力とlog.txtファイルに保存されます。

image.png

image.png

OpenShift Loggingで確認すると同様のログを確認できます。

image.png

ここまでがOpenShift Loggingにおけるコンテナアプリケーションのアプリケーションログの確認でした。同様のアプリをfedora-log-exporterにデプロイしてみます。

VMに同様のlog-testアプリをDeployして挙動を確認する

[fedora@fedora-log-exporter ~]$ $ sudo yum install git -y
[fedora@fedora-log-exporter ~]$ $ sudo yum install nodejs -y
[fedora@fedora-log-exporter ~]$ $ sudo npm install express
[fedora@fedora-log-exporter ~]$ $ sudo npm install ejs
[fedora@fedora-log-exporter ~]$ $ git clone https://gitlab.com/masaki-oomura/log-test.git
[fedora@fedora-log-exporter ~]$ $ cd log-test
[fedora@fedora-log-exporter log-test]$ npm start

> log-test@1.0.0 start
> node app.js

Server is listening at http://localhost:3000

さて、fedora-log-exporterは現在Serviceで80番ポートを公開していたので、service-fedora-log-exporter.yaml及びroute-fedora-log-exporter.yamlを編集しておきます。

service-fedora-log-exporter.yaml
apiVersion: v1
kind: Service
metadata:
  name: service-fedora-log-exporter
  namespace: virtual-machine
spec:
  selector:
    vm.kubevirt.io/name: fedora-log-exporter
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
route-fedora-log-exporter.yaml
kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: route-fedora-log-exporter
  namespace: virtual-machine
spec:
  to:
    kind: Service
    name: service-fedora-log-exporter
  port:
    targetPort: 3000

RouteのURLからアプリにアクセスしました。ホスト名のところがVMのホスト名になっています。

image.png

さて、先ほどコンテナでやったのと同様にVMの標準出力にログを出してみます。

image.png

SSHしているターミナルにログが出ました。

[fedora@fedora-log-exporter log-test]$ npm start

> log-test@1.0.0 start
> node app.js

Server is listening at http://localhost:3000
入力された文字列: digimon
メッセージがlog.txtに保存されました。

OpenShift Loggingでアプリケーションのログを見てみます。

image.png

わけわからない{"component":"virt-launcher", hogehogeとかいうログが大量に出ております。これはなにかというと、VMfedora-log-exporterの実態(インスタンス)であるところのPodvirt-launcher-fedora-log-exporter-gv9xhの詳細で見ることができるコンテナのログです。

image.png

つまり、VMの標準出力にログを出していても、OpenShift Loggingで確認する事はできないです。

実はVMのシリアルコンソールに出力されるものはOpenShift Loggingで確認できる

OpenShift Virualization機能が提供するCustom ResourceであるHyperConvergedのインスタンスkubevirt-hyperconvergedはデフォルトではVMのシリアルコンソールログがdisableとなっています。

詳細はOpenShiftのドキュメントを参照ください。ただし、ドキュメントの項目の通り、こちらはどちらかというとトラブルシューティングを目的とした機能です。

上記のドキュメントに従ってdisableSerialConsoleLog: falseに書き換えます。
(デフォルトはdisabletrueなので、要は機能が「無効」になっています)

image.png

VMの詳細画面でシリアルコンソールを使う事ができます。

image.png

シリアルコンソールに出力されるログはOpenShift Loggingでも確認することができます。

image.png

おわりに

以上が、OpenShift Virtualization上でのVMのロギング運用の状況でした。これまで通りのVMのロギングはOpenShift上のVMであろうと、特に大きな変更は必要無いであろうことがお分かりいただけたと思います。ただし、OpenShift Loggingとの統合はまだまだこれからに期待なところが多そうです。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3