観測用プラグインエージェントの削除

• 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
     

  2. オプション：名前空間を削除します。 その名前空間で実行中のリソースが他にない場合。

     kubectl delete namespace ibm-observe
     

プラグインが削除された後、クラスタダッシュボード、Terraform、または手動で、クラスタにロギングエージェントとモニタリングエージェントを再インストールします。

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

• IBM Cloud Kubernetes Service クラスタのログ収集エージェントの管理。
• 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> --skip-validation
   

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>