Skip to main content
Data Infrastructure Insights
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Kubernetes Monitoring Operatorのインストールと設定

共同作成者
PDF

Data Infrastructure Insightsは、Kubernetesコレクション向けの「Kubernetes Monitoring Operator」を提供しています。新しいオペレータを導入するには、* Kubernetes > Collectors >+ Kubernetes Collector *に移動します。

Kubernetes Monitoring Operatorをインストールする前に

Kubernetes Monitoring Operatorをインストールまたはアップグレードする前に、ドキュメントを参照してください"前提条件"。

Kubernetes Monitoring Operatorのインストール

モニタリングオペレータの指示 モニタリングオペレータの指示

KubernetesにKubernetes Monitoring Operatorエージェントをインストールする手順は次のとおりです。

  1. 一意のクラスタ名およびネームスペースを入力してください。以前のKubernetes Operatorの場合はアップグレード、同じクラスタ名とネームスペースを使用します。

  2. これらを入力すると、ダウンロードコマンドスニペットをクリップボードにコピーできます。

  3. スニペットを a_bash_window に貼り付け、実行します。Operatorインストールファイルがダウンロードされます。スニペットには固有のキーがあり、24時間有効です。

  4. カスタムリポジトリまたはプライベートリポジトリがある場合は、オプションのImage Pullスニペットをコピーし、a_bash_shellに貼り付けて実行します。画像がプルされたら、プライベートリポジトリにコピーします。必ず同じタグとフォルダ構造を維持してください。_operator-deployment.yaml_のパスと_operator-config.yaml_のDockerリポジトリ設定を更新します。

  5. 必要に応じて、プロキシやプライベートリポジトリの設定など、使用可能な設定オプションを確認します。あなたはについてもっと読むことができます"設定オプション"。

  6. 準備ができたら、kubectl Applyスニペットをコピーしてダウンロードし、実行してOperatorをデプロイします。

  7. インストールが自動的に開始されます。完了したら、[Next]ボタンをクリックします。

  8. インストールが完了したら、[Next]ボタンをクリックします。また、_operator-secrets.yaml_fileを削除するか、安全に保存してください。

プロキシを使用している場合は、「について」を参照してくださいプロキシを設定します。

カスタムリポジトリがある場合は、を参照してくださいカスタム/プライベートDockerリポジトリを使用する。

Kubernetes監視コンポーネント

Data Infrastructure Insights Kubernetes Monitoringは、次の4つの監視コンポーネントで構成されます。

  • クラスタ指標

  • ネットワークパフォーマンスとマップ（オプション）

  • イベントログ（オプション）

  • 変更分析（オプション）

上記のオプションコンポーネントは、各Kubernetesコレクタに対してデフォルトで有効になっています。特定のコレクタ用のコンポーネントが必要ないと判断した場合は、* Kubernetes > Collectors *に移動し、画面右側のコレクタの「three dots」メニューから_Modify Deployment_を選択して無効にできます。

Kubernetes CollectorリストページのModify deploymentメニュー

画面には各コンポーネントの現在の状態が表示され、必要に応じてそのコレクタのコンポーネントを無効または有効にすることができます。

展開オプションの変更、幅= 700

最新のKubernetes Monitoring Operatorへのアップグレード

既存のOperatorにAgentConfigurationが存在するかどうかを確認します（ネームスペースがdefault_netapp-monitoring_でない場合は、適切なネームスペースに置き換えてください）。

 kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration
AgentConfigurationが存在する場合：

AgentConfigurationが存在しない場合は、次の手順を実行します。

  • クラスタ名がData Infrastructure Insightsで認識される名前であることをメモします（ネームスペースがデフォルトのNetApp監視機能でない場合は、適切なネームスペースで置き換えてください）。

     kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'
* 既存のOperatorのバックアップを作成します（ネームスペースがデフォルトのネットアップ監視機能になっていない場合は、適切なネームスペースで置き換えてください）。
     kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml
* <<to-remove-the-kubernetes-monitoring-operator,アンインストール>>既存の演算子。
* <<installing-the-kubernetes-monitoring-operator,インストール>>最新の演算子。

    • 同じクラスタ名を使用してください。

    • 最新のOperator YAMLファイルをダウンロードしたら、展開する前に、agent_backup.yamlにあるカスタマイズをダウンロードしたoperator-config.yamlに移植します。

    • カスタムリポジトリを使用している場合は、使用していることを確認して最新のコンテナイメージを取得しますください。

Kubernetes Monitoring Operatorの停止と起動

Kubernetes Monitoring Operatorを停止するには：

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
Kubernetes Monitoring Operatorを起動するには：
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1

アンインストール中です

Kubernetes Monitoring Operatorを削除するには

Kubernetes Monitoring Operatorのデフォルトのネームスペースは「netapp-monitoring」です。独自のネームスペースを設定した場合は、それらのネームスペースと、以降のすべてのコマンドおよびファイルを置き換えます。

新しいバージョンの監視オペレータは、次のコマンドを使用してアンインストールできます。

kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE>
kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>

監視オペレータが専用のネームスペースに配置されている場合は、ネームスペースを削除します。

 kubectl delete ns <NAMESPACE>
最初のコマンドが「リソースが見つかりません」を返した場合は、次の手順に従って古いバージョンの監視オペレータをアンインストールします。

次の各コマンドを順番に実行します。現在のインストール状況によっては、これらのコマンドの一部で「オブジェクトが見つかりません」というメッセージが返される場合があります。これらのメッセージは無視してかまいません。

kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp
kubectl delete crd agents.monitoring.netapp.com
kubectl -n <NAMESPACE> delete role agent-leader-election-role
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged
kubectl delete <NAMESPACE>-psp-nkmo
kubectl delete ns <NAMESPACE>

セキュリティコンテキスト制約が事前に作成されている場合は、次の手順を実行します。

kubectl delete scc telegraf-hostaccess

Kubeステートメトリックについて

NetApp Kubernetes Monitoring Operatorは、他のインスタンスとの競合を回避するために独自のkube-state-metricsをインストールします。

Kube-State-Metricsの詳細については、を参照してください"このページです"。

オペレータの設定/カスタマイズ

これらのセクションでは、オペレータ設定のカスタマイズ、プロキシの操作、カスタムまたはプライベートDockerリポジトリの使用、OpenShiftの操作について説明します。

設定オプション

最も一般的に変更される設定は、_AgentConfiguration_customリソースで構成できます。オペレータを配備する前に、_operator-config.yaml_fileを編集して、このリソースを編集できます。このファイルには、コメントアウトされた設定例が含まれています。演算子の最新バージョンについては、のリストを参照してください"使用可能な設定"。

オペレータが配備された後で、次のコマンドを使用してこのリソースを編集することもできます。

 kubectl -n netapp-monitoring edit AgentConfiguration
展開したオペレータのバージョンがAgentConfigurationをサポートしているかどうかを確認するには、次のコマンドを実行します。
 kubectl get crd agentconfigurations.monitoring.netapp.com
「Error from server (NotFound)」というメッセージが表示された場合は、AgentConfigurationを使用する前にオペレータをアップグレードする必要があります。

プロキシサポートを設定しています

Kubernetes Monitoring Operatorをインストールするために、テナントでプロキシを使用できる場所は2つあります。同じプロキシシステムでも、別のプロキシシステムでもかまいません。

  • インストールコードスニペット（「curl」を使用）の実行中に、スニペットが実行されるシステムをData Infrastructure Insights環境に接続するために必要なプロキシ

  • ターゲットのKubernetesクラスタがData Infrastructure Insights環境と通信するために必要なプロキシ

これらのいずれかまたは両方にプロキシを使用する場合、Kubernetes Operating Monitorをインストールするには、まず、Data Infrastructure Insights環境との通信が良好になるようにプロキシが設定されていることを確認する必要があります。プロキシがあり、Operatorをインストールするサーバ/ VMからData Infrastructure Insightsにアクセスできる場合は、プロキシが適切に設定されている可能性があります。

Kubernetes Operating Monitorのインストールに使用するプロキシについては、Operatorをインストールする前に、_http_proxy/https_proxy_environment変数を設定します。一部のプロキシ環境では'_no_proxy環境変数も設定する必要があります

変数を設定するには、Kubernetes Monitoring Operatorをインストールする前に、システム*で次の手順を実行します。

  1. 現在のユーザの https_proxy 変数と _http_proxy_environment 変数を設定します。

    1. セットアップするプロキシに認証（ユーザ名/パスワード）がない場合は、次のコマンドを実行します。

       export https_proxy=<proxy_server>:<proxy_port>
.. セットアップするプロキシに認証（ユーザ名/パスワード）が設定されている場合は、次のコマンドを実行します。
      export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>

KubernetesクラスタがData Infrastructure Insights環境と通信するために使用するプロキシの場合は、以下の手順をすべて読んでからKubernetes Monitoring Operatorをインストールします。

Kubernetes Monitoring Operatorをデプロイする前に、operator-config.yamlのAgentConfigurationのプロキシセクションを設定します。

agent:
  ...
  proxy:
    server: <server for proxy>
    port: <port for proxy>
    username: <username for proxy>
    password: <password for proxy>

    # In the noproxy section, enter a comma-separated list of
    # IP addresses and/or resolvable hostnames that should bypass
    # the proxy
    noproxy: <comma separated list>

    isTelegrafProxyEnabled: true
    isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
    isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
    isAuProxyEnabled: <true or false> # true if AU enabled
  ...
...

カスタムまたはプライベートのDockerリポジトリを使用する

Kubernetes監視オペレータは、デフォルトで、Data Infrastructure Insightsリポジトリからコンテナイメージを取得します。監視のターゲットとして使用されているKubernetesクラスタがあり、そのクラスタがカスタムまたはプライベートのDockerリポジトリまたはコンテナレジストリからコンテナイメージのみをプルするように構成されている場合は、Kubernetes Monitoring Operatorが必要とするコンテナへのアクセスを設定する必要があります。

NetApp Monitoring Operatorのインストールタイルから[Image Pull Snippet]を実行します。このコマンドを実行すると、Data Infrastructure Insightsリポジトリにログインし、オペレータが必要とするすべてのイメージを取得して、Data Infrastructure Insightsリポジトリからログアウトします。プロンプトが表示されたら、指定したリポジトリの一時パスワードを入力します。このコマンドは、オプション機能を含む、オペレータが使用するすべてのイメージをダウンロードします。これらの画像がどの機能に使用されるかについては、以下を参照してください。

Core Operator Functionality and Kubernetes Monitoringの略

  • ネットアップによる監視

  • ci-kube-rbac-proxy

  • CI-KSM

  • CI-テレグラフ

  • distroless-root-user

イベントログ

  • CI-fluent-bit

  • ci-kubernetes-event-exporter

ネットワークのパフォーマンスとマップ

  • ci-net-observerの略

社内のポリシーに従って、オペレータ用の Docker イメージをプライベート / ローカル / エンタープライズ Docker リポジトリにプッシュします。リポジトリ内のこれらのイメージへのイメージタグとディレクトリパスが、Data Infrastructure Insightsリポジトリ内のイメージタグとディレクトリパスと一致していることを確認します。

operator-deployment.yamlでmonitoring-operatorデプロイメントを編集し、プライベートDockerリポジトリを使用するようにすべてのイメージ参照を変更します。

image: <docker repo of the enterprise/corp docker repo>/ci-kube-rbac-proxy:<ci-kube-rbac-proxy version>
image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>

operator-config.yamlのAgentConfigurationを編集して、新しいDockerリポジトリの場所を反映します。プライベートリポジトリ用に新しいimagePullSecretを作成します。詳細については、_ https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/_を参照してください

agent:
  ...
  # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry
  # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository
  dockerRepo: your.docker.repo/long/path/to/test
  # Optional: A docker image pull secret that maybe needed for your private docker registry
  dockerImagePullSecret: docker-secret-name

OpenShift の手順

OpenShift 4.6以降で実行している場合は、_runPrivileged_settingを有効にするには、_operator-config.yaml_でAgentConfigurationを編集する必要があります。

# Set runPrivileged to true SELinux is enabled on your kubernetes nodes
runPrivileged: true

OpenShiftは、一部のKubernetesコンポーネントへのアクセスをブロックする可能性のある追加のセキュリティレベルを実装する場合があります。

公差と接線（Tolerations and Taints）

NetApp-ci-telegraf-ds_、NetApp-CI-fluent-bit-ds、および_NetApp-CI-net-observer-l4-DS_DaemonSetsは、すべてのノードのデータを正しく収集するために、クラスタ内のすべてのノードでポッドをスケジュールする必要があります。オペレータは、いくつかの既知の*テイント*に耐えられるように設定されています。ノードにカスタムのtaintsを設定して、すべてのノードでポッドが実行されないようにしている場合は、それらのtaintsに* toleration *を作成できます"（AgentConfiguration）をクリックします"。クラスタ内のすべてのノードにカスタムテイントを適用した場合は、オペレータの導入に必要な許容範囲を追加して、オペレータポッドをスケジュールおよび実行できるようにする必要があります。

Kubernetesの詳細はこちら"塗料および耐性"をご覧ください。

に戻ります。"* NetApp Kubernetes監視オペレータのインストール*ページ"

秘密に関する注意事項

Kubernetes Monitoring Operatorのシークレットをクラスタ全体で表示する権限を削除するには、インストール前に_operator-setup.yaml_fileから次のリソースを削除します。

 ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

アップグレードの場合は、クラスタからリソースも削除します。

 kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

変更分析が有効になっている場合は、_AgentConfiguration_or_operator -config.yaml_を変更して、変更管理セクションのコメントを解除し、変更管理セクションの下に_kindsToIgnoreFromWatch：'"secrets"'_を含めます。この行の一重引用符と二重引用符の存在と位置に注意してください。

# change-management:
  ...
  # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector
  # # Each kind will have to be prefixed by its apigroup
  # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"'
  kindsToIgnoreFromWatch: '"secrets"'
  ...

Kubernetes Monitoring Operatorイメージシグネチャの確認

オペレータ用のイメージと、展開するすべての関連イメージは、NetAppによって署名されています。インストール前にcosignツールを使用してイメージを手動で検証するか、Kubernetesアドミッションコントローラを設定できます。詳細については、を参照してください"Kubernetes のドキュメント"。

イメージシグネチャの検証に使用する公開キーは、Monitoring Operatorインストールタイルの_オプションで使用できます。オペレータイメージをプライベートリポジトリにアップロード> Image Signature Public Key_

画像折丁を手動で確認するには、次の手順に従います。

  1. 画像プルスニペットをコピーして実行する

  2. プロンプトが表示されたら、リポジトリパスワードをコピーして入力します。

  3. イメージ署名公開キーを保存します（この例ではdii-image-signing.pub）。

  4. コサインを使用して画像を確認します。次のcosignの使用例を参照してください。

$ cosign verify --key dii-image-signing.pub --insecure-ignore-sct --insecure-ignore-tlog <repository>/<image>:<tag>
Verification for <repository>/<image>:<tag> --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
[{"critical":{"identity":{"docker-reference":"<repository>/<image>"},"image":{"docker-manifest-digest":"sha256:<hash>"},"type":"cosign container image signature"},"optional":null}]

トラブルシューティング

Kubernetes Monitoring Operatorの設定で問題が発生した場合に試すべきこと：

問題 次の操作を実行します

Kubernetes 永続ボリュームと対応するバックエンドストレージデバイスの間にハイパーリンク / 接続がありません。My Kubernetes Persistent Volume がストレージサーバのホスト名を使用して設定されます。

手順に従って既存の Tegraf エージェントをアンインストールし、最新の Tegraf エージェントを再インストールします。Telegrafバージョン2.0以降を使用しており、KubernetesクラスタストレージがData Infrastructure Insightsによってアクティブに監視されている必要があります。

E0901 15:21:39.962145 1 reflector.go:178]k8s.io/kube-state-metrics/internal/store/builder.go:352: List*v1.MutatingWebhookConfiguration:サーバはリクエストされたリソースE0901 15:21:43.168161を見つけることができませんでした。

これらのメッセージは、1.20より前のバージョンのKubernetesでkube-state-metricsバージョン2.0.0以上を実行している場合に発生する可能性があります。Kubernetes のバージョンを取得するには、次の Leubectl version_ kbe-state-metrics バージョンを取得します。 kubectl デプロイ /kube-state-metrics -o jsonpath='{.image}' これらのメッセージが発生しないようにするには、 kube-state-metrics デプロイを修正して、次の Leases 設定を具体的に無効にしてください。 _hookates_web_volumeconfigurations resources= 証明リクエスト , configmaps,cronjobs,demonsets,horizontalscalers,ingleers,jobs,limitrange,scapers,networkpolicies , nodes,persistentvolumes,persistentvolumesalims,persistentvolumes,podeters, replicaSets,replicaSets,replicationcontrollers ,residetodポッド ,residetappeditors,appers,uns,uns,uns,uns,sets,uns,uns,uns,uns,uns,sets,uns,sets,uns,sets,uns,uns,sets,uns,uns,sets,uns,uns,uns,wodecodeclieticecodetics,sets,sets,sets,sets,uns,sets,uns,uns,sets,sets,sets,un 検証する Web フック設定 ' ボリュームの添付ファイル

Telegrafから次のようなエラーメッセージが表示されますが、Telegrafは起動して実行されます。10月11日14:23:41 IP-172-31-39-47 systemd[1]: InfluxDBにメトリックを報告するために、プラグイン駆動のサーバーエージェントを起動しました。10月11日14：23：41 IP-172-31-39-47 telegraf [1827]：time="2021-10-11T14：23：41Z" level=error msg="failed to create cache directory./etc/telegraf/.cache/snowflake、err:mkdir /etc/telegraf/.ca che: permission denied.ignored \n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120" Oct 11 14:23:41 ip-172-31-39-47 telegrafaf [1827]無視されました。open /etc/telegraf/.cache/snowflake/ocsp_response_cache.json:該当するファイルまたはディレクトリがありません\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120" Oct 11 14:23:41 ip-172-31-39-47 telegrZ [1827]: 2021-T1114:114:114Telegraf 1.19.3 を起動しています

これは問題と呼ばれています。"この GitHub の記事"詳細については、を参照してください。Tegraf が起動して動作している限り、ユーザはこのエラーメッセージを無視できます。

Kubernetes で、 Telegraf ポッドが次のエラーを報告しています。 "Error in processing mountstats info: failed to open mountstats file: /hostfs /proc/1/mountstats 、 error: open /hostfs /proc/1/mountstats ： permission denied"

SELinuxを有効にして強制すると、TelegrafポッドがKubernetesノードの/proc/1/mountstatsファイルにアクセスできなくなる可能性があります。この制限を克服するには、agentconfigurationを編集し、runPrivileged設定を有効にします。詳細については、を参照して"OpenShift の手順"ください。

Kubernetes で、 Telegraf ReplicaSet ポッドから次のエラーが報告されています。 [ プラグインの inputs.prometheus] エラー： Could not load keypair /etc/Kubernetes /pki/ etcd/server.crt ： /etc/Kubernetes /pki/ etcd/server.key ： open /etc/Kubernetes /pki/ etcd/server.key ：特定のディレクトリまたは crt ファイルをロードできませんでした

Telegraf ReplicaSet ポッドは、マスターまたは etcd 用に指定されたノード上で実行することを目的としています。これらのノードのいずれかで ReplicaSet ポッドが実行されていない場合は、これらのエラーが発生します。マスター / etcd ノードに汚染があるかどうかを確認します。その場合は、 Telegraf ReplicaSet 、テレグラム af-RS に必要な忍容を追加します。たとえば、 ReplicaSet…​kubectl を編集して RS テレグラムを編集し、仕様に適切な公差を追加します。次に、 ReplicaSet ポッドを再起動します。

PSP/PSA環境があります。これはモニタリングオペレータに影響しますか？

KubernetesクラスタがPod Security Policy（PSP）またはPod Security Admission（PSA）を使用して実行されている場合は、最新のKubernetes Monitoring Operatorにアップグレードする必要があります。PSP/PSAをサポートしている現在のオペレータにアップグレードするには、次の手順に従います。アンインストール以前の監視演算子: kubectl delete agent-monitoring-cr-n NetApp kubectl delete ns NetApp -monitoring kubectl delete crd agents.monitoring.com kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader kubectl delete clusterrolebinding agent-manager-manager-rolebinding agent-manager-manager-rolebinding NetApp NetAppインストールモニタリングオペレータの最新バージョン。

Operatorを展開しようとして問題が発生しましたが、PSP/PSAを使用しています。

1.次のコマンドを使用してエージェントを編集します。kubectl -n <name-space> edit agent 2.「security-policy enabled」を「false」に設定します。これにより、PodセキュリティポリシーとPodセキュリティアドミッションが無効になり、オペレータが展開できるようになります。次のコマンドを使用して確認します。kubectl get psp（should show Pod Security Policy removed）kubectl get all -n <namespace>

grep -i psp（should show that nothing is found）

「ImagePullBackoff」エラーが発生しました

これらのエラーは、カスタムまたはプライベートのDockerリポジトリがあり、Kubernetes Monitoring Operatorを適切に認識するように設定していない場合に表示されることがあります。詳細はこちらカスタム/プライベートリポジトリの構成について

監視オペレータの配置に問題 を使用していますが、現在のドキュメントでは解決できません。

次のコマンドの出力をキャプチャまたはメモし、テクニカルサポートチームに連絡します。

 kubectl -n netapp-monitoring get all
 kubectl -n netapp-monitoring describe all
 kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true
 kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true

Operator名前空間のNet-Observer（ワークロードマップ）ポッドがCrashLoopBackOffにある

これらのポッドは、Network ObservabilityのWorkload Mapデータコレクタに対応しています。以下を試してみてください:•いずれかのポッドのログをチェックして、カーネルの最小バージョンを確認してください。例：---｛"ci-tenant-id"："your-tenant-id"、"collector-cluster"："your-k8s-cluster-name"、"environment"："prod"、"level"："error"、"msg"："検証に失敗しました。理由:カーネルバージョン3.10.0が最小カーネルバージョン4.18.0よりも小さい、"time":"2022-11-09T08:23:08Z"}---•Net-observerポッドを使用するには、Linuxカーネルバージョンが4.18.0以上である必要があります。「uname -r」コマンドを使用してカーネルのバージョンを確認し、4.18.0以上であることを確認します

PodはOperatorネームスペース（デフォルト：netapp-monitoring）で実行されているが、QueriesのワークロードマップまたはKubernetes指標のデータがUIに表示されない

K8Sクラスタのノードの時間設定を確認します。監査およびデータレポートを正確に作成するには、Network Time Protocol（NTP；ネットワークタイムプロトコル）またはSimple Network Time Protocol（SNTP；簡易ネットワークタイムプロトコル）を使用してAgentマシンの時刻を同期することを強く推奨します。

Operator名前空間の一部のnet-observerポッドがPending状態です

net-observerはデーモンセットであり、Kubernetesクラスタの各ノードでポッドを実行します。•保留状態のポッドをメモし、CPUまたはメモリのリソース問題 が発生しているかどうかを確認します。必要なメモリとCPUがノードにあることを確認します。

Kubernetes監視演算子をインストールした直後にログに次のようなメッセージが表示されます。[ inputs.prometheus]プラグインエラー:\ http://kube-state-metricsへのHTTPリクエストの作成エラー。<namespace>.svc.cluster.local：8080/metrics：get\ http://kube-state-metrics <namespace>.svc.cluster.local：808080/metrics：dial tcp：lookup kube-state-metrics .<namespace>.svc.svc.cluster.local tc.local

このメッセージが表示されるのは、通常、_KSM_PODが起動する前に、新しいオペレータがインストールされ、_テレ グラム-RS_PODが稼働している場合のみです。これらのメッセージは、すべてのポッドが実行されると停止します。

クラスタに存在するKubernetes CronJobsについて収集された指標が表示されません。

Kubernetesのバージョンを確認します（例： kubectl version）。v1.20.x以下の場合、これは想定される制限です。Kubernetes Monitoring Operatorで導入されたkube-state-metricsリリースでは、v1.cronjobのみがサポートされます。Kubernetes 1.20.x以前では、cronjobリソースはv1beta.cronjobにあります。その結果、kube-state-metricsはcronjobリソースを見つけることができません。

オペレータのインストール後、telegraf-DSポッドがCrashLoopBackOffに入り、PODログに「su：Authentication failure」と表示されます。

_AgentConfiguration_のtelegrafセクションを編集し、set_dockerMetricCollectionEnabled_をfalseに設定します。詳細については、オペレータのを参照して"設定オプション"ください。…​spec:…​telegraf:…​           -name：docker       run-mode：       -DaemonSet      置換：       -key：docker_unix_sock_placeholder        値：unix：//run/docker.sock…​…​

Telegrafログに次のようなエラーメッセージが繰り返し表示されます。[agent]出力への書き込み中にエラーが発生しました。http：Post "\https：//<tenant_url>/rest/v1/lake/ingest/influxdb"：context deadline exceeded (Client. ヘッダー待機中にタイムアウトを超過しました）

_AgentConfiguration_およびincrease_outputTimeout_のtelegrafセクションを10秒に編集します。詳細については、オペレータのを参照して"設定オプション"ください。

一部のイベントログの_involvedobject_dataが見つかりません。

上記の手順を実行していることを確認して"権限"ください。

2つの監視オペレータポッド（netapp-ci-monitoring-operator-pod <pod>とmonitoring-operator-pod）が実行されているのはなぜ<pod>ですか？

2023年10月12日付けで、Data Infrastructure Insightsは、ユーザへのサービス向上のためにオペレータをリファクタリングしました。これらの変更を完全に採用するには古いオペレータを削除します。、とが必要です。新しいものを取り付ける

Kubernetesイベントが予期せずData Infrastructure Insightsに報告されなくなりました。

event-exporterポッドの名前を取得します。

`kubectl -n netapp-monitoring get pods

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
「netapp-ci-event-exporter」または「event-exporter」のいずれかにする必要があります。次に、監視エージェントを編集し kubectl -n netapp-monitoring edit agent、前の手順で見つけた適切なイベントエクスポータポッド名を反映するようにlog_fileの値を設定します。具体的には、log_fileは「/var/log/containers/netapp-ci-event-exporter.log」または「/var/log/containers/event-exporter 。log」のいずれかに設定する必要があります。

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter.log
…​
…​.
あるいは、1つはまた、再インストールエージェントをすることができますアンインストール。

リソースが不足しているため、Kubernetes Monitoring Operatorによってデプロイされたポッドがクラッシュしています。

CPUやメモリの制限を必要に応じて増やすには、Kubernetes Monitoring Operatorを参照して"設定オプション"ください。

イメージがないか無効な設定が原因で、netapp-ci-kube-state-metricsポッドが起動しないか準備完了状態になりました。これでStatefulSetが停止し、設定の変更がnetapp-ci-kube-state-metricsポッドに適用されなくなりました。

StatefulSetはステートに"切断"あります。設定の問題を修正したら、netapp-ci-kube-state-metricsポッドをバウンスします。

NetApp-ci-kube-state-metricsポッドがKubernetes Operatorのアップグレード実行後に起動せず、ErrImagePullがスローされる（イメージをプルできない）。

ポッドを手動でリセットしてみてください。

Kubernetesクラスタの[Log Analysis]で、「Event discarded as being older then maxEventAgeSeconds」というメッセージが確認されています。

Operator_agentconfiguration_を変更し、event-exporter-maxEventAgeSeconds（60秒）、event-exporter-kubeQPS（100）、および_event-exporter-kubeBurst_（500）を増やします。これらの設定オプションの詳細については、ページを参照して"設定オプション"ください。

Telegrafが警告するか、ロック可能なメモリが不足しているためにクラッシュします。

基盤となるオペレーティングシステム/ノードでTelegrafのロック可能メモリの制限を増やしてみてください。制限値を増やすことができない場合は'NKMOエージェントの構成を変更して'_unprotected_to_true_に設定しますこれにより、Telegrafはロックされたメモリページを予約しないように指示します。復号化されたシークレットがディスクにスワップアウトされる可能性があるため、セキュリティリスクが発生する可能性がありますが、ロックされたメモリを予約できない環境では実行できます。_unprotected_configurationオプションの詳細については、ページを参照してください"設定オプション"。

Telegrafから次のような警告メッセージが表示されます。[inputs.diskio]「vdc」のディスク名を収集できません：/dev/vdcの読み取り中にエラーが発生しました：該当するファイルまたはディレクトリがありません_

Kubernetes Monitoring Operatorの場合、これらの警告メッセージは問題なく無視してかまいません。  または、AgentConfigurationでtelegrafセクションを編集し、_runDsPrivileged_をtrueに設定します。詳細については、を参照して"オペレータの設定オプション"ください。

Fluent-bitポッドが次のエラーで失敗しています。[2024/10/16 14:16:23][error][/src/fluent-bit/plugins/in tail/tail_fs_inotify.c:360 errno=24]開いているファイルが多すぎます[2024/10/16 14:16:23][error] failed initialize initialization failed.

クラスタの_fsnotify_settingsを変更してみます。

 sudo sysctl fs.inotify.max_user_instances (take note of setting)

 sudo sysctl fs.inotify.max_user_instances=<something larger than current setting>

 sudo sysctl fs.inotify.max_user_watches (take note of setting)

 sudo sysctl fs.inotify.max_user_watches=<something larger than current setting>

Fluent-bitを再起動します。

注：これらの設定をノードの再起動後も維持するには、_/etc/sysctl.conf_に次の行を追加する必要があります。

 fs.inotify.max_user_instances=<something larger than current setting>
 fs.inotify.max_user_watches=<something larger than current setting>

詳細については、のページまたはを"Data Collector サポートマトリックス"参照して"サポート"ください。