動的プロパティフィルタリングによるKubernetes監視コストの最適化

LogicMonitorの LMコンテナ は、ミッションクリティカルなビジネス アプリケーションを実行している Kubernetes 環境を効果的に監視したいユーザーにとって優れた選択肢です。 今回、動的プロパティ フィルタリングと呼ばれる新しいコスト最適化機能を導入しました。これにより、ユーザーにさらなる柔軟性とカスタマイズが提供されます。 このブログ投稿では、永続ボリュームの状態に基づいて選択的に監視する例を段階的に示しながら、このエキサイティングな新機能について説明します。

動的プロパティ フィルタリングと静的プロパティ フィルタリング

LM Container は、デフォルトですべての Kubernetes リソースを検出して監視します。 ただし、ユーザーはフィルターを適用して、監視の範囲を特定のリソースに制限できます。 LMコンテナガイド Kubernetes リソースのフィルタリング Kubernetes リソースにフィルターを適用する方法について詳しく説明します。

以前は、LM Container には Kubernetes リソースを監視するためのフィルタリング オプションが限られており、ユーザーはオブジェクト ラベルなどの静的プロパティに基づいてフィルタリングすることしかできませんでした。 たとえば、ユーザーは「」というラベルが付いたすべてのサービスを削除できます。環境” と価値”開発」というフィルター式「type in (“se​​rvice”) && env == “development”」を使用します。 この機能により、ユーザーは必要なリソースのみを監視できるようになり、効率が向上し、監視のオーバーヘッドが削減されました。 ただし、動的プロパティ フィルタリングの追加により、LM Container ではユーザーが現在の状態に基づいてリソースをフィルタリングできるようになり、より正確な監視が可能になります。 これは、リソースが使用中の場合にのみ監視できるようになり、よりターゲットを絞った監視機能が提供されることを意味します。

動的プロパティフィルタリングの利点

LM Container の動的プロパティ フィルタリングは、Kubernetes モニタリングの効率とカスタマイズを向上させ、大きな経済的メリットをもたらします。 お客様が必要なリソースのみを監視できるようにすることで、監視コストを最適化し、投資から最大限の価値を得ることができます。 動的プロパティ フィルタリングは、顧客がさまざまな方法で監視コストを節約するのに役立ちます。

1. 監視するものに対して料金を支払う: 動的プロパティ フィルタリングを使用すると、アクティブに使用され、業務運営に関連するリソースに監視の取り組みを集中させることができます。 これは、運用に必須ではないリソースの監視を節約できることを意味します。
2. より高度なカスタマイズ: 動的プロパティ フィルタリングにより、監視設定を特定のニーズに合わせて調整でき、Kubernetes 環境の最も重要な側面を確実に可視化できます。
3. トラブルシューティングとサポートを合理化する: 重要なリソースのみを監視することで、IT チームは問題を迅速に特定して対処できます。 これにより、ダウンタイムが短縮され、トラブルシューティングやサポート作業にかかるコストが削減されます。
4. 効率的なスケーリング: Kubernetes 環境が拡大しても、動的プロパティ フィルタリングを使用すると、コストを簡単に抑えながら監視設定を拡張できます。 アクティブに使用されているリソースのみを監視することで、インフラストラクチャが拡大しても効率的でコスト効率の高い監視システムを維持できます。
5. 投資収益率 (ROI) を最大化する: 動的プロパティ フィルタリングを使用して監視設定を最適化することで、Kubernetes 監視への投資から最大限の価値を確実に得ることができます。 これにより、ROI が向上し、組織の全体的なパフォーマンスが向上します。

例: 動的プロパティフィルタリングを使用した永続ボリュームのオンデマンド監視

動的プロパティ フィルタリングの利点を理解するのに役立つように、プロパティを監視する段階的な例を見てみましょう。 永続ボリューム (PV) バウンドフェーズの場合のみ。 永続ボリューム (PV) がアクティブに使用されている場合、永続ボリュームはバインド段階に留まります。 永続ボリュームの要求 (PVC)。 PV がバウンド段階にある場合にのみ PV を監視すると、PV がアクティブに使用されている場合にのみ監視できるため、使用されていないときの監視コストを節約できます。

私が使用します ミニキューブ この練習のために。 ただし、任意の Kubernetes クラスターを使用できます。 MiniKube は、テストと開発の目的に最適な軽量の Kubernetes 実装です。 MiniKube について詳しくは、以下をご覧ください。 公式ドキュメント。 まず、次の手順に従って、最新バージョンの LM Container を Kubernetes クラスターにインストールします。 LMコンテナ設置ガイド。 インストール コマンドを実行して LM コンテナをデプロイする前に、生成された値ファイルに次のフィルター式を必ず追加してください。

argus:

  # ADD the following filter condition to the existing argus configuration

  filters:

    - type == "persistentvolume" && jsonGet(object, "status.phase") != "Bound"

上記のフィルター式により、バインドフェーズの PV のみが LM コンテナーによって監視されるようになります。 LM コンテナを Kubernetes クラスターにデプロイしたら、次のコマンドを実行して、PVC と PV を含む NGINX ポッドを作成します。

cat <<EOF | kubectl create -f -

kind: Pod

apiVersion: v1

metadata:

  name: task-pv-pod

  labels:

    app: demo

spec:

  volumes:

    - name: task-pv-storage

      persistentVolumeClaim:

        claimName: task-pv-claim

  containers:

    - name: task-pv-container

      image: nginx

      ports:

        - containerPort: 80

          name: "http-server"

      resources:

        limits:

          cpu: "1"

          memory: "512Mi"

      volumeMounts:

        - mountPath: "/usr/share/nginx/html"

          name: task-pv-storage

---

kind: PersistentVolume

apiVersion: v1

metadata:

  name: task-pv-volume

  labels:

    type: local

    app: demo

spec:

  storageClassName: manual

  persistentVolumeReclaimPolicy: Recycle

  capacity:

    storage: 10Gi

  accessModes:

    - ReadWriteOnce

  hostPath:

    path: "/mnt/data"

---

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: task-pv-claim

  labels:

    app: demo

spec:

  storageClassName: manual

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 3Gi

EOF

次のコマンドを実行すると、NGINX ポッド、PVC、および PV が正常に作成されたことを確認できます。

kubectl get pods,pvc,pv -l app=demo

次のスクリーンショットは、コマンドの出力を示しています。

上のスクリーンショットは、NGINX ポッド、PVC、および PV が正常に作成されたことを示しています。 PVC はバインド段階にあります。これは、PV がアクティブに使用されていることを意味します。 ここで、PV が LM Container によって監視されていることを確認してみましょう。 これを行うには、LogicMonitor ポータルに移動し、監視対象のリソースを確認します。 次のスクリーンショットに示すように、PV が LM Container によって監視されていることを確認できます。

次のコマンドを実行して NGINX ポッドと PVC を削除できるようになりました。これにより、PV は利用可能フェーズのままになります。

kubectl delete pod task-pv-pod

kubectl delete pvc task-pv-claim

次のスクリーンショットは、NGINX ポッドと PVC を削除した後の PV のステータスを示しています。

これで、PV が LM Container によって監視されていないことを確認できます。 これを行うには、LogicMonitor ポータルに移動し、監視対象のリソースを確認します。 次のスクリーンショットに示すように、PV がリソース リストに存在しなくなっていることがわかります。

これは、動的プロパティ フィルタリングが監視コストの最適化にどのように役立つかを示す一例にすぎません。 動的プロパティ フィルタリングを Kubernetes リソースに適用して、使用時のみ監視できるため、監視コストを節約できます。

まとめ

LM Container の動的なプロパティ フィルタリングは、財務上の大きなメリットをもたらし、顧客はモニタリング コストを最適化し、必要な分だけ支払うことができます。 この機能を Kubernetes 環境に実装すると、監視のコストを制御しながら監視の効率を高めることができます。 コンテナ化と Kubernetes オーケストレーションの世界が成長し続ける中、LogicMonitor はお客様が時代の先を行くための革新的なソリューションを提供することに引き続き取り組んでいます。