観測可能性プラグインエージェントの削除

• ob plugin のサポート終了後は、各コンポーネントを個別に削除する必要があります。

  1. デーモンセットとコンフィグマップをクリーンアップする。

      kubectl delete daemonset logdna-agent -n ibm-observe
      kubectl delete daemonset sysdig-agent -n ibm-observe
      kubectl delete configmap <logdna-configmap> -n ibm-observe
      kubectl delete configmap <sysdig-configmap> -n ibm-observe
      ```
  1. オプション：ネームスペースを削除する。 ネームスペースで他のリソースが実行されていない後。
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

プラグインを削除した後、クラスターダッシュボード、Terraform、または手動で、クラスター内のロギングおよびモニタリングエージェントを再インストールしてください。

詳しくは、以下のリンクを参照してください。

• IBM Cloud Kubernetes Service のログデータを IBM Cloud Logs に送信する。
• Kubernetes クラスターのモニター

外部サーバーへのログ転送について

クラスタ内のソースについて、外部サーバーへ転送するためのロギング設定を作成すると、 Fluentd クラスタ内にコンポーネントが作成されます。 Fluentd は、そのソースのパスからログを収集し、そのログを外部サーバーに転送します。 ソースからロギング・サービスの取り込みポートへのトラフィックは暗号化されます。

ログ転送の設定ができるソースにはどのようなものがありますか？

次の画像では、ログ記録の設定が可能であるソースの領域を確認できます。

1. worker: ユーザーがワーカー・ノードに指定したインフラストラクチャー構成に固有の情報。 syslog には、オペレータログが記録され、そこにはオペレーティングシステムのイベントが含まれています。 auth.log には、OS に対して行われた認証要求に関する情報が含まれます。

   パス

   • /var/log/syslog
   • /var/log/auth.log

2. container: 実行中のコンテナによって記録される情報。 パス : STDOUT または STDERR`` に書き込まれるすべての内容。

3. application: アプリケーション・レベルで発生するイベントに関する情報。 これは、ログインの成功、ストレージに関する警告、またはアプリレベルで実行可能なその他の操作など、何らかのイベントが発生したことを通知するものです。 転送先 ：ログを転送する先を設定できます。 ただし、ロギング構成で絶対パスを使用しないとログが送信されないため、ログを読み取ることができません。 パスがワーカーノードにマウントされている場合、シンボリックリンクが作成されている可能性があります。 例：指定されたパスが /usr/local/spark/work/app-0546/0/stderr であるにもかかわらず、実際にはログが /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr に保存されている場合、そのログを読み取ることができません。

4. storage: クラスター内にセットアップされた永続ストレージに関する情報。 ストレージ・ログは、DevOps パイプラインおよび製品リリースの一部として問題判別ダッシュボードおよびアラートをセットアップするのに役立ちます。 注: パス /var/log/kubelet.log および /var/log/syslog にもストレージ・ログが含まれていますが、これらのパスにあるログは kubernetes および worker ログ・ソースによって収集されます。

   パス

   /var/log/ibmc-s3fs.log

   /var/log/ibmc-block.log

   ポッド

   portworx-***

   ibmcloud-block-storage-attacher-***

   ibmcloud-block-storage-driver-***

   ibmcloud-block-storage-plugin-***

   ibmcloud-object-storage-plugin-***

5. kubernetes: ワーカー・ノードの kube-system 名前空間内で発生する kubelet、kube-proxy、その他の Kubernetes イベントからの情報。

   パス

   /var/log/kubelet.log

   /var/log/kube-proxy.log

   /var/log/event-exporter/1..log

6. ingress: Ingress ALB を介してクラスターに伝送されるネットワーク・トラフィックに関する情報。

   パス

   /var/log/alb/ids/*.log

   /var/log/alb/ids/*.err

   /var/log/alb/customerlogs/*.log

   /var/log/alb/customerlogs/*.err

7. kube-audit: Kubernetes API サーバーに送信されるクラスター関連アクションに関する情報。時間、ユーザー、および影響を受けるリソースを含みます。 kube-audit ソースは、Webhook を使用して構成できます。 詳しくは、「外部サーバーへの Kubernetes API 監査ログの転送 (Forwarding Kubernetes API audit logs to an external server)」を参照してください。

Fluentd の更新は私の責任ですか？

ロギングやフィルターの構成を変更するには、Fluentd ロギング・コンポーネントが最新バージョンである必要があります。 デフォルトでは、このアドオンに対する自動更新が有効になっています。 自動更新を使用不可にするには、クラスターのコンポーネントの更新: ロギング用の Fluentdを参照してください。

クラスタ内の1つのソースから、一部のログのみを転送し、他のログは転送しないようにすることはできますか？

はい。 例えば、特にログ量の多いポッドがある場合に、そのポッドのログでログ・ストレージ・スペースが占有されないようにして、他のポッドのログを転送したいことがあります。 特定のポッドのログを転送しないようにする方法については、ログのフィルタリングを参照してください。

クラスターとアプリのログの転送

クラスターとアプリのロギングの構成を作成します。 オプションを使用することで、さまざまなロギングオプションを区別することができます。

ロギングを構成する際に使用できる各種オプションとその説明は、次の表のとおりです。

udp または tcp プロトコルを介してユーザー自身のサーバーにログを転送する

1. エディターまたは管理者の IBM Cloud IAM プラットフォーム・アクセス役割があることを確認してください。

2. ログ・ソースがあるクラスターの場合: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

3. syslog プロトコルを受け付けるサーバーを、以下の2つの方法のいずれかで設定します： : 独自のサーバーをセットアップして管理するか、プロバイダーが管理するサーバーを使用します。 プロバイダーがサーバーを管理する場合は、ロギング・プロバイダーからロギング・エンドポイントを取得します。

   : コンテナから syslog を実行します。 たとえば、この デプロイ用.yaml ファイルを使用すると、 Docker のパブリックイメージを取得し、クラスター内でコンテナを実行することができます。 このイメージは、パブリック・クラスター IP アドレスのポート 514 を公開し、このパブリック・クラスター IP アドレスを使用して syslog ホストを構成します。

   syslog というプレフィックスを削除すれば、ログを有効な JSON として確認できます。 そのためには、 rsyslog サーバーが稼働している etc/rsyslog.conf ファイルの先頭に、以下のコードを追加してください： $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. ログ転送構成を作成します。 パラメーターについて詳しくは、ロギング構成オプションの表についてを参照してください。

   ibmcloud ks logging config create --cluster CLUSTER_NAME_OR_ID --logsource LOG_SOURCE --namespace KUBERNETES_NAMESPACE --hostname LOG_SERVER_HOSTNAME_OR_IP --port LOG_SERVER_PORT --type syslog --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS --syslog-protocol PROTOCOL
   

tls プロトコルを介してユーザー自身のサーバーにログを転送する

1. 以下の IBM Cloud IAM 役割があることを確認します。

   • クラスターに対するエディターまたは管理者のプラットフォーム・アクセス役割
   • ** 名前空間に対するライターまたは**管理者kube-systemのサービス・アクセス役割

2. ログ・ソースがあるクラスターの場合: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

3. syslog プロトコルを受け付けるサーバーを、以下の2つの方法のいずれかで設定します：

   • 独自のサーバーをセットアップして管理するか、プロバイダーが管理するサーバーを使用します。 プロバイダーがサーバーを管理する場合は、ロギング・プロバイダーからロギング・エンドポイントを取得します。

   • コンテナから syslog を実行します。 たとえば、この デプロイ用.yaml ファイルを使用すると、クラスター内でコンテナを実行する「 Docker 」のパブリックイメージを取得できます。 このイメージは、パブリッククラスタIPアドレスに対してポート 514 を公開し、このパブリッククラスタIPアドレスを使用して syslog ホストを設定します。 関連する認証局証明書およびサーバー・サイド証明書を注入し、syslog.conf を更新して、サーバー上で tls を有効にする必要があります。

4. 認証局証明書を ca-cert という名前のファイルに保存します。 この名前のとおりでなければなりません。

5. kube-system ファイル用のシークレットを ca-cert 名前空間に作成します。 ロギング設定を作成する際は、「 --ca-cert 」オプションにシークレット名を使用してください。

   kubectl -n kube-system create secret generic --from-file=ca-cert
   

6. ログ転送構成を作成します。 パラメーターについて詳しくは、ロギング構成オプションの表についてを参照してください。

   ibmcloud ks logging config create --cluster <cluster name or id> --logsource <log source> --type syslog --syslog-protocol tls --hostname <ip address of syslog server> --port <port for syslog server, 514 is default> --ca-cert <secret name> --verify-mode <defaults to verify-none>
   

転送されるログのフィルタリング

一定期間における特定のログをフィルターで除外することで、外部サーバーに転送するログを選択できます。 オプションを使用することで、さまざまなフィルタリングオプションを区別することができます。

1. ロギング・フィルターを作成します。

   ibmcloud ks logging filter create --cluster CLUSTER_NAME_OR_ID --type LOG_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

2. 作成したログ・フィルターを表示します。

   ibmcloud ks logging filter get --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --show-matching-configs
   

3. 作成したログ・フィルターを更新します。

   ibmcloud ks logging filter update --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --type SERVER_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

4. 作成したログ・フィルターを削除します。

   ibmcloud ks logging filter rm --cluster CLUSTER_NAME_OR_ID --id FILTER_ID [--all]
   

ログ転送構成の確認、更新、および削除

ibmcloud ks logging config update --cluster CLUSTER_NAME_OR_ID --id LOG_CONFIG_ID --namespace NAMESPACE --type SERVER_TYPE --syslog-protocol PROTOCOL --logsource SOURCE --hostname HOSTNAME_OR_INGESTION_URL --port PORT --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS