はじめに
IBM Cloud MonitoringはIBM Cloud上のリソース監視に利用できるクラウドネイティブなソリューションです。
監視対象のリソースにエージェントを導入することでMonitoringダッシュボード上でリソース監視を行うことが可能です。
基本的にMonitoringを使用する際に発生する課金は対象となるリソース数、使用時間によって決まりますが、別の要素としてTime Seriesというメトリクス量によって決まる課金も存在します。
このTime Seriesはメトリクスに制限をかけない場合は金額が大きくなってしまうことがあるのでご注意ください。
本稿ではTime Seriesで発生する課金を抑えるための方法としてFiltering機能の実装方法を紹介します。
手順はこちらのdocsを参考にしています。
Monitoringのカスタムメトリクスについて
Monitoringで発生するメトリクスには以下の2つが存在します。
1. デフォルトメトリクス
- インフラストラクチャメトリクス(ホスト、コンテナ、プログラムKubernetesの状態など)、CPU、メモリ、ディスク、ネットワーク
- 基本料金に含まれているため、無償で利用可能
2. カスタムメトリクス
- プラットフォーム・メトリクス、Prometheusリモート書き込み、メトリクス・ストリーミング、エージェント(Prometheus、JMX、StatsD）
- 基本料金に含まれていないため課金対象
メトリクスがどちらに属しているかを確認するには公式のメトリクスライブラリーから確認するかMonitoringのダッシュボードから確認してください。
確認方法
- Monitoringダッシュボードから
Explore→Metrics Usageを選択 -
Show only custom metricsのオンオフを切り替えることでカスタムメトリクスもしくは全てのメトリクスを表示可能
参考：Time Seriesの課金額について
参考としてKubernetesにMonitoringエージェントを導入した際の課金額を計算します。
先ほど確認したCardinality(過去20分のメトリクス)では1.54kと記載がありました。
単純計算一月で1540 x 3 x 24 x 31 = 3437280、Time Seriesは単価が$0.0001196のため、
2vCPUx8GBのKubernetesを利用した場合、デフォルトでも月額として約 $400の課金が発生します。
実装手順
本稿ではKubernetesからMonitoringへログを取る際に取得するメトリクスを制限する方法を記載します。
実装手順は以下のとおりです。
- 使用しているメトリクスの確認
- configmapからフィルタリングの設定
- フィルタリングしたメトリクスの確認
事前準備
本稿の実装前に以下の環境は既に用意されているものとします。
- IBM Cloud Monitoringインスタンス : monitoring-instance
- Kubernetes環境 : cluster-jp-tok(2x8, 1node)
KubernetesにはMonitoringのagentを入れておきます。agentの入れ方はこちらのdocsを参照ください。
1. 使用しているメトリクスの確認
IBM CloudポータルのMonitoringダッシュボードを開き、現時点でのメトリクス量(Time Series)を確認します。
MonitoringダッシュボードからExplore→Metrics Usageを選択するとリソース全体でのTime Seriesや発生しているメトリクスを確認可能です。
左側のリソース名を選択するとそのリソースに限定したメトリクスを表示することができ、右上のCardinalityでは過去20分間で発生したTime Seriesが確認できます。
また、画面下のMetrix Usageでは実際に過去20分間で発生しているメトリクスの量を確認できます。(Export all resultsを選択するとJSONもしくはCSVファイルとして出力できます)
これらを確認すると20分で1540(266種類)と多くのカスタムメトリクスが発生していることが確認できます。
今回はこの中から試しに2番目のcontainer_spec_cpu_period以外のメトリクスをフィルタリングしてモニタリングインスタンスに出力されないようします。
2. configmapからフィルタリングの設定
フィルタリング設定のため、TerminalからKubernetesのコンフィグマップを編集します。
ibmcloudへログイン後、Kubernetesクラスターへアクセスします。
$ ibmcloud login
$ ibmcloud ks cluster config -c cluster-jp-tok
続いて、Kubernetesのコンフィグマップを編集します。
$ kubectl edit configmap sysdig-agent -n ibm-observe
コンフィグマップにはデフォルトだとメトリクスのフィルターの項目は含まれていないため、新しくコンフィグマップの後ろにmetrics_filterの項目を追加します。
apiVersion: v1
data:
dragent.yaml: |
new_k8s: true
k8s_cluster_name: Cluster-jp-tok
collector: ingest.jp-tok.monitoring.cloud.ibm.com
sysdig_api_endpoint: secure.sysdig.com
security:
enabled: true
k8s_audit_server_enabled: true
k8s_audit_server_port: 7765
k8s_audit_server_url: 0.0.0.0
# 以下filtering設定追加箇所
metrics_filter:
- include: metricA.*
- exclude: metricA.*
- exclude: metricB.*
上記のルール設定ではmetrics_filterの後に含めるメトリクスをincludeで、除外するメトリクスをexcludeで指定します。
フィルタリングルールは上から順に適応されるため、はじめにincludeしたmetricAから始まるメトリクスは2番目でexcludeされていますが、最初のincludeが優先されるためメトリクスは収集されます。
今回はcontainer_spec_cpu_periodのメトリクスのみを取得したいため、以下のように記載します。
metrics_filter:
- include: container_spec_cpu_period
- exclude: `*`
コンフィグファイルの設定が完了するとconfigmap/sysdig-agent editedとメッセージが表示され、自動的に更新したコンフィグファイルが適用されます。
3. フィルタリングしたメトリクスの確認
最後にMonitoringのダッシュボードからメトリクスが正しく制限されているか確認します。
1. 使用しているメトリクスの確認で確認した手順と同様にダッシュボードからMetrics Usageを開きます。
こちら確認するとCardinality(過去20分のメトリクス)が大幅に減っており、Metrics Usageでもcontainer_spec_cpu_period以外の大きなメトリクスがなくなっています。
(なぜか一部のメトリクスは残っていますが、メトリクスは31種類まで制限されていることは確認できます)
まとめ
本稿ではIBM Cloud Monitoringでの課金項目であるTime Seriesの減らし方(メトリクスの制限方法)について記載しました。
特別変わった設定をしていない場合でもOpenShiftやKubernetesを使用するとTime Seriesの金額が高くなってしまうことがあるので、Billingを確認してみてモニタリングの金額を減らしてみることをお勧めします。