IBM Log Analysis with LogDNA でKubernetes (IKS)のNFSマウント先ログファイル監視検証

18967 ワード
ibmcloud IKS LogDNA kubernetes kubernetes テキストリンク
はじめに

IBM Kubernetes Services (IKS) のログ監視にはサービスで提供されている IBM Log Analysis with LogDNA を使用することが可能です。

参考：IBM Log Analysis with LogDNA による Kubernetes クラスター・ログの管理

IBM Log Analysis with LogDNA で標準提供されている定義では、Pod の標準出力は拾えるようですが、独自のアプリログは対象にはありません。

この記事では、Pod のNFS(Network File System)マウント先をLogDNAの監視対象にできるかどうかを確認しました。

(使用しているIKS環境ではPod のアプリログをNFSマウント先に出力しているため、アプリログをLogDNAで監視できるかどうかの前段階のテスト検証です。)

環境

使用する IBM Cloud サービス：
・IBM Cloud Kubernetes Service (1 master / 1 worker, Tokyo Region)
・IBM Log Analysis with LogDNA (Tokyo, Light Plan)
・IBM Cloud File Storage (NFS マウント先のストレージ)

実装方法

＊ IKS はすでに存在する前提です。
＊ File Storage は 対象の IKS を Authorized Host に設定済みです。

LogDNA の設定

①IBM Log Analysis with LogDNA サービス・インスタンス作成

マニュアルの通りに実行
(ライトプランのインスタンスを作成)
参考：ステップ 1. IBM Log Analysis with LogDNA サービス・インスタンスをプロビジョンする

②取り込み鍵の設定

マニュアルの通りに実行
参考：ステップ 2. 取り込み鍵を取得する

③ログ送信設定

マニュアルの③ logDNA 取り込み鍵を保管するための Kubernetes シークレット作成まで実施します。

参考：ステップ 3: LogDNA インスタンスにログを送信するように Kubernetes クラスターを構成する

〜ここからカスタマイズです〜

マニュアルのページが変わりますが、次に記載がある東京(jp-tok) のパブリック・エンドポイントの構成ファイルをダウンロードします。

参考：ステップ 4. LogDNA エージェントをクラスターにデプロイする

jo-tok の構成ファイルを取得 -> https://assets.jp-tok.logging.cloud.ibm.com/clients/logdna-agent-ds.yaml

[変更内容]
・/logs ディレクトリをLOGDNA_LOGDIR として定義
・/var/log/、/var/data/ 下のその他ログは排除
・volumeMounts に /logs を追加。 /logs は PersistentVolumeClaim に接続。

logdna-agent-ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: logdna-agent
  labels:
    app: logdna-agent
spec:
  selector:
    matchLabels:
      app: logdna-agent
  template:
    metadata:
      labels:
        app: logdna-agent
    spec:
      containers:
      - name: logdna-agent
        image: logdna/logdna-agent:latest
        imagePullPolicy: Always
        env:
        - name: LOGDNA_AGENT_KEY
          valueFrom:
            secretKeyRef:
              name: logdna-agent-key
              key: logdna-agent-key
        - name: LDAPIHOST
          value: api.jp-tok.logging.cloud.ibm.com
        - name: LDLOGHOST
          value: logs.jp-tok.logging.cloud.ibm.com
        - name: LOGDNA_PLATFORM
          value: k8s
        - name: LOGDNA_EXCLUDE   #<= 追加
          value: /var/log/containers/*_kube-system_*,/var/log/containers/*ibm-observe_*,/var/log/containerd.log,/var/log/kubelet.log,/var/log/syslog,/var/log/ntpstats/*,/var/log/alb/*,/var/data/*       #<= 追加
        # - name: LOGDNA_TAGS
        #   value: production,cluster1,othertags
        resources:
          requests:
            cpu: 20m
          limits:
            memory: 500Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: vardata
          mountPath: /var/data
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: mnt
          mountPath: /mnt
          readOnly: true
        - name: docker
          mountPath: /var/run/docker.sock
        - name: osrelease
          mountPath: /etc/os-release
        - name: logdnahostname
          mountPath: /etc/logdna-hostname
        - name: testpvc                     #<= 追加
          mountPath: /logs                  #<= 追加
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: vardata
        hostPath:
          path: /var/data
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: mnt
        hostPath:
          path: /mnt
      - name: docker
        hostPath:
          path: /var/run/docker.sock
      - name: osrelease
        hostPath:
          path: /etc/os-release
      - name: logdnahostname
        hostPath:
          path: /etc/hostname
      - name: testpvc　　　　　　　　　　　　　　  #<= 追加
        persistentVolumeClaim:             　 #<= 追加
          claimName: testpvc　　　　　　　　　　 #<= 追加
  updateStrategy: 
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 100%

->「#<= 追加」部分の行を追加しています。
-> LogDNAのログファイル除外は次を参照ください。ログファイルの除外

PersistentVolume と、PersistentVolumeClaim 定義も合わせて設定します。(使用するファイル pv-pvc-est.yml)

参考の定義例です。

pv-pvc-test.yml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: testpvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: testpvc
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: testpvc
spec:
  storageClassName: testpvc
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 10Gi
  nfs:
    path: /<FileStorageHostName>/data01/test/       #<= マウントするパス
    server: fsf-tokxxxxx.service.softlayer.com      #<= FileStorageホスト名
  mountOptions:
  - nfsvers=3

④ pv, pvc 定義の作成

これまでの経験上、PV,PVCが作られていないとPod作成に失敗することが何度かあったので、先にボリューム定義を作成します。NameSpace 「ibm-observe 」に定義します。

$ kubectl create -f pv-pvc-test.yml -n ibm-observe
persistentvolumeclaim/testpvc created
persistentvolume/testpvc created

⑤編集したLogDNA エージェントのデプロイ

$ kubectl create -f logdna-agent-ds_pv.yaml -n ibm-observe
daemonset.apps/logdna-agent created

確認

$ kubectl get po -n ibm-observe
NAME                 READY   STATUS    RESTARTS   AGE
logdna-agent-xxxxx   1/1     Running   0          93s

logdna-agent が対象のIKS上に作成されました。
これでロギング構成完了です。

テスト

① logdna agent へのログイン

$ kubectl exec -it logdna-agent-xxxxx /bin/sh -n ibm-observe
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl kubectl exec [POD] -- [COMMAND] instead.
# ls
bin  boot  dev  etc  home  lib  lib64  logs  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

上記の書き方でのexec コマンドでのログインはDeprecateなのですね...。でもログインしたまま使いたいのでこのまま実施します。

  • 追記 ちなみに、こう書けばw WARNINGは出ませんでした。。exec コマンドのオプションが変更されて「--」が必要になったのですね。
$ kubectl exec -it logdna-agent-xxxxx -- /bin/sh -n ibm-observe

test.log と app.log というテストファイルを作成し、適当に記載してログがLogDNA上に表示されるか確認します。

# cd logs
# ls -l
total 0
# touch test.log
# touch app.log
# ls -l
total 0
-rw-r--r-- 1 root root 0 Jan  7 05:21 app.log
-rw-r--r-- 1 root root 0 Jan  7 05:21 test.log

# echo testtest >> test.log
# date
Thu Jan  7 05:23:20 UTC 2021
# echo testtest >> test.log
# echo app >> app.log
# date
Thu Jan  7 05:24:26 UTC 2021
#

LogDNA のWebUI で確認

=> LogDNAの表示を押します

Pod内のNFSマウント先に作成したファイルのログが出力されていることが確認できました!

(参考)LogDNAのView定義

参考：ステップ 7. ビューを作成する

上のテストでの表示はLogDNAのView定義でtest.log、app.logのみを表示する定義を設定していました。

定義例です。
LogDNA WebUI の Everything で"Apps" を選択。

表示されるログファイルの対象"app.log、test.log" にチェックを入れます。

Applyを押します。

この状態だとUnsaved View のため、新しいView として定義します。

Name に 任意の名前「testlog」　を記入し、SaveViewを押します。

testlog view ができました。

終わりに

NFSマウント先のテスト・ファイルをLogDNAの取り込み対象とすることができました。
環境で使用しているNFSマウント先のアプリログを転送してLogDNAの監視対象にする期待が持てそうです。

(注意) マニュアルにないことを実装しますので、サポート等の保証は不明です。この記事を参考にして実装される場合は、Own Risk でお願いします。

参考：
IBM Cloud資料 IBM Log Analysis with LogDNA
IBM Cloud資料 FileStorage