Kubernetes monitoring with Prometheus

Prometheus operator tutorial（第三章）

前回第二章の続き、私たちは完全な「Prometheusを伴ったKubernetesモニタリング」のインストール方法を説明しています。しかし、Prometheus Operatorのフレームワークを使うということ、そしてそのCustom Resource Definitionsは手動で追加されたメトリックターゲットとサービスプロバイダにおいてすごく重要なのです。それは、大きいデプロイメントのために扱いにくくなり、完全にKubernetesのorchestratorのケーパビリティをユーティライズしません。

私たちは同じようなスタックをデプロイしますが、今回はもっと自動的で、フレキシブルな方法を用います。

前回私たちは以下の点をお話しました。

1. Prometheusを伴うKubernetesモニタリング, 基本的なコンセプトと最初のデプロイメント

2. Krometheusを伴うKubernetesモニタリング、 Alertmanager, Grafana, PushGateway

3. Prometheus Operator チュートリアル: Prometheus、 AlertmanagerとGrafanaのための完全に自動化されKubernetesデプロイメント（この記事）

• Kubernetes Operatorとは何ですか
• Prometheus Operator
• Prometheus Operator — 簡単なインストール
• 自動コンフィグレーション メトリックのエンドポイント
• Alert ルールと Alertmanager コンポーネント
• Grafanaを伴う可視化とDash boards

4. Prometheusパフォーマンスに関する考察,高可用性,外部ストレージ、次元数の制限（ディメンショナリーリミット）

What is a Kubernetes Operator?

オペレーターはKubernetes専用のアプリケーション（ポッド）で、他のKubernetesデプロイメントを自動的にコンフィギュアしたり、管理したり、最適化してくれるアプリケーションです。カスタム・コントローラーとして実行されます。

Kubernetes operatorはアプリケーションをどのようにデプロイし、スケーリングするかを知っていて、直接APIとコミュニケーションを取りながら、アルゴリズム決定を行います。

Kubernetes Operatorは以下のことができます。

• 適切な最初のコンフィグレーションをインストールします。自分のKubernetesクラスターのスペックに従って、自分のデプロイメントのためにサイジングします。
• どのユーザーのリクエストしたパラメーターモディフィケーション（ホット・コンフィグ・リローディング）にも適応するようにポッドとデプロイメントのライブリロードをする
• パフォーマンスメトリックに従い、自動的にスケールアップ、もしくはスケールダウンする。
• バックアップ、整合性チェック、もしくはメンテナンスタスクを実行する。

基本的には、human adminによるコードとして表わされるものは、Kubernetes Operatorの中で自動化が可能です。

Kubernetes Operatorは他のKubernetes APIリソースのようにアクセスされる状況に応じたエンティティとオブジェクトを生成するためにCustom Resource Definitions (略してCRD)をとても頻繁に使うようになります。例えば、次でお話するようにPrometheusのサーバーデプロイメントの最初のコンフィグレーションとスケーリングを設定する‘Prometheus’ Kubernetes APIオブジェクトを操作できるようになります。

Prometheus Operator

KubernetesのためのPrometheus Operator のおかげで簡単にKubernetesサービスやデプロイメント、そしてPrometheusインスタンスの運用のためのモニタリングを設定できるようになります。

私たちは以下の目的で、Prometheus Operatorを使用します。

• 初めてのインストールを実行し、完全なKubernetes-Prometheusスタックをコンフィグレーションする。
• Prometheus サーバー
• Alertmanager
• Grafana
• Host node_exporter
• kube-state-metrics
• ServiceMonitor エンティティを使ってメトリックのエンドポイントオートコンフィギュレーションを設定する。
• Operator CRD とConfigMaps を使ってサービスをカスタマイズし、スケーリングする。 ConfigMapsがあれば、自分たちのコンフィグレーションを完全にポータブルに、デクレラティブにすることができる。

Operatorは以下のcustom resource definitions (CRDs)上で働く

• Prometheus, 希望したPrometheus デプロイメントを設定する。Operator は常にリソースの設定にマッチしているデプロイメントが走っているということを確認する。
• ServiceMonitorはどのようにサービスのグループがモニターされるかをデクレラティブに明示するOperatorはその設定をベースにしたPrometheusスクレープ コンフィギュレーションを自動で生成する
• PrometheusRuleは希望するPrometheus ルールファイルを設定し、Prometheus alerting やレコーディングルールを含むPrometheus インスタンスによってロードされる。
• Alertmanagerは希望したAlertmanager のデプロイメントを設定し、そのOperator は常にリソースの設定にマッチしているデプロイメントが走っているということを確認する。

そのOperatorレポジトリの中の kube-prometheus ディレクトリは、デフォルトのサービスとコンフィギュレーションが含まれています。そのため、Prometheus Operatorそれ自身だけではなく、get-goを使って、カスタマイズして使用しはじめることができる完全なセットアップが手に入ります。

The Prometheus Operator — Components architecture diagram

以下のものは私たちが構成しようとしているKubernetesモニタリングシステムのコンポーネントダイアグラムです。

第二章の手動でPrometheusコンポーネントをインストールするときに似ているダイアグラムだと分かりますよね。しかし、2つの重要な違いがあります。

1. 異なるPrometheusデプロイメントは異なるリソースをモニタリングする：

• Prometheusサーバーのうちの一つのグループ (1 to N, 自分のスケールによる)はKubernetesの内部コンポーネントと状態をモニタリングする。
• Prometheus の他のグループは他の自分のクラスターの中にデプロイされたアプリをモニターする。

2. 直接デプロイとサービスを生成する代わりに、私たちはメトリックソースを伴うOperator にデータを流すためにCRDを使います。上のような例において、私たちは2つのデータソースを持つ１つのGrafanaサービスを持っています。しかし、私たちはPrometheus Operatorのおかげで、デクレラティブな方法でコンポーネントのダイアグラムを再度アレンジする方法をお見せすることができます。

Prometheus Operator — Quick install

そのprometheusのモニタリング ガイド レポジトリーはベースのyamlファイルをいくつか、そして私たちが使う予定のカスタマイズの例を含みます。まだレポジトリーが完了していないのであれば、まず最初にレポジトリーを完了しましょう。

git clone https://github.com/coreos/prometheus-operator.git
git clone https://github.com/mateobur/prometheus-monitoring-guide.git

自分のローカルのkubectlがkubernetesダスターを走らせるように指示出しているか確認してください。簡単に捨てられて、もう一度生成できるテストされたクラスターを使いたいと思うはずです。だから異なるコンフィギュレーションを使ってみましょう。

デフォルトで kube-prometheusをインストールするためには、以下が必要です。

kubectl create -f prometheus-operator/contrib/kube-prometheus/manifests/

デフォルトのスタックは、すぐに使えるたくさんのコンポーネントをデプロイします。

kubectl get pods -n monitoring
NAME READY STATUS RESTARTS AGE
alertmanager-main-0 2/2 Running 0 7m
alertmanager-main-1 2/2 Running 0 7m
alertmanager-main-2 2/2 Running 0 6m
grafana-5568b65944-nwbct 1/1 Running 0 8m
kube-state-metrics-76bdcb8ff9–77t52 4/4 Running 0 6m
node-exporter-224sh 2/2 Running 0 7m
node-exporter-2s89j 2/2 Running 0 7m
node-exporter-x8w8b 2/2 Running 0 7m
prometheus-k8s-0 3/3 Running 1 7m
prometheus-k8s-1 3/3 Running 1 6m
prometheus-operator-cdccdb8db-vcvhx 1/1 Running 0 8m

以下を見てください。

・Prometheus サーバーやAlertmanagerサーバーのように他のデプロイメントを管理する責任を担っているprometheus-operatorポッド、スタックのコア

• 物理ホストごとのnode-exporterポッド（この例においては３）
• A kube-state-metrics エクスポーター
• デフォルトのPrometheus サーバー デプロイメント prometheus-k8s (レプリカ: 2)
• デフォルトのAlertmanager デプロイメント alertmanager-main (レプリカ: 3)
• Grafana デプロイメントgrafana (レプリカ: 1)

Accessing the interfaces of the Prometheus Operator

ちょうど今デプロイしたインターフェイスを素早く簡単に確認するために、kubectlのポートフォワード機能を使ってください。

kubectl port-forward grafana-5568b65944-nwbct -n monitoring 3000:3000

それでは、自分のウェブブラウザでhttp://localhost:3000 を開き、Grafanaのインターフェイスにアクセスします。すでに色々な役に立つダッシュボードがたくさん入っています。

しかし、プロダクションKubernetesモニタリングをデプロイしたいと思うのであれば、それらのインターフェイスをingressコントローラーと適切なセキュリティを使って適切にエクスポーズする必要があります：HTTPS証明書と認証

Interacting with the Prometheus Operator via CRD objects

Kubernetesの中で自分が予測したようにそれぞれのDeploymentもしくはStatefulSetのコンポーネントをモディファイする代わりに、このPrometheusスタック デプロイメントをモディファイするために、直接アブストラクト設定をカスタマイズし、operatorに自分に代わってorchestrationをコントロールさせます。

それでは、シンプルな例からスタートしましょう。まず３つのAlertmanagerポッドはこのシナリオにおいては多すぎます。１つで十分です。

最初に、alertmanager CRDを調べましょう。

kubectl get alertmanager main -n monitoring -o yaml
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
clusterName: “”
creationTimestamp: 2018–08–28T09:15:25Z
labels:
alertmanager: main
name: main
namespace: monitoring
resourceVersion: “1401”
selfLink: /apis/monitoring.coreos.com/v1/namespaces/monitoring/alertmanagers/main
uid: e5d335aa-aaa2–11e8–8cf2–42010a800113
spec:
baseImage: quay.io/prometheus/alertmanager
nodeSelector:
beta.kubernetes.io/os: linux
replicas: 3
serviceAccountName: alertmanager-main
version: v0.15.2

ここからポッドラベル、serviceAccount、nodeSelector、そして私たちが探していたレプリカの数をモディファイすることが可能です。

レプリカのパラメントを1に変更してください。APIオブジェクトをパッチします。（prometheus-monitoring-guideレポジトリの中でパッチされたバージョンを見つけることができます）

kubectl create -f prometheus-monitoring-guide/operator/alertmanager.yaml — dry-run -o yaml | kubectl apply -f -

もし、モニタリングのネームスペースの中でポッドを再度リストアップするのであれば、Prometheus Operatorそれ自身のログの中で、たった1つのAlertmanagerポッドと例サイズイベントを確認できるでしょう。

kubectl logs prometheus-operator-cdccdb8db-vcvhx -n monitoring | tail -n 1
level=info ts=2018–08–28T09:47:20.523662127Z caller=operator.go:402 component=alertmanageroperator msg=”sync alertmanager” key=monitoring/main

Prometheus Operator endpoint to scrape autoconfiguration

次のステップでは、自分のクラスターの中の他のデプロイされたサービスをモニタリングを開始するためにこのコンフィグレーションの上に構築します。

この過程に関連する２つのカスタムリソースが存在します。

• The Prometheus CRD
• Prometheus サーバーポッドメタデータを設定する
• Prometheusサーバーレプリカの#を設定する
• 始動したアラートルールを送るためにAlertmanagerのエンドポイントを設定する
• このPrometheus サーバーデプロイメントによって表示されるServiceMonitor CRDのためのレベルとネームスペース フィルターを設定する
• ServiceMonitorオブジェクトはダイナミックなターゲットエンドポイント コンフィギュレーションを表示する
• The ServiceMonitor CRD
• ネームスペースやラベルなどによってエンドポイントをフィルターに通す
• 異なるスクレープポートを設定する
• スクレープインターバル、プロトコル、TLS証明書、再ラベリング・ポリシーなどのような全ての追加されたスクレープパラメントを設定する

PrometheusオブジェクトはN ServiceMonitorオブジェクトをフィルターに通し、選択します。そして交代でN Prometheusメトリックエンドポイントをフィルターに通し、選択します。

もしServiceMonitorの基準にマッチする新しいメトリックエンドポイントがあれば、このターゲットは自動的にそのServiceMonitorを選ぶ全てのPrometheusサーバーに追加されます。

上のダイアグラムを見て分かるように、そのServiceMonitorはKubernetesサービスをターゲットにしていて、ポッドにより直接エクスポーズされるエンドポイントをターゲットにはしていません。

私たちは既に、全てのKubernetesの内部メトリック（kube-state-metrics, node-exporter, Kubernetes APIなど）をモニタリングするPrometheusデプロイメントを持っています。しかし、今私たちは、別々になっているデプロイメントが必要なのです。それは、クラスターの一番上で走っている他のアプリケーションの様子を見るためです。

この新しいデプロイメントを実行するために、それをクラスターに入れる前にまず最初にこのPrometheus CRDを見てみましょう。（下のレポジトリーの中でこのファイルを見つけることができます）

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
labels:
app: prometheus
prometheus: service-prometheus
name: service-prometheus
namespace: monitoring
spec:
alerting:
alertmanagers:
- name: alertmanager-main
namespace: monitoring
port: web
baseImage: quay.io/prometheus/prometheus
logLevel: info
paused: false
replicas: 2
retention: 2d
routePrefix: /
ruleSelector:
matchLabels:
prometheus: service-prometheus
role: alert-rules
serviceAccountName: prometheus-k8s
serviceMonitorSelector:
matchExpressions:
- key: serviceapp
operator: Exists

簡潔にするために、私たちは他のデプロイメントの中で見つけたalertmanager とserviceAccountコンフィギュレーションを再利用します。

このPrometheusサーバーコンフィギュレーション・ファイルの中では以下のものを見つけることができます。

• このコンフィグを使った Prometheusレプリカの数
• ダイナミックにアラートルールをコンフィグするruleSelector
• 発動したアラートを受け取るAlertmanager デプロイメント (余剰分のための１つ以上のポッドになる可能性がある)
• ServiceMonitorSelector,つまり、与えられたserviceMonitorがこのPrometheusサーバーをコンフィグレーションするために使われたかどうかを決めるフィルターのこと。
• この例においては、もしserviceMonitorが自身のメタデータの中でラベルサービスアプリを含んでいるのであれば、serviceMonitorがこのPrometheusデプロイメントと関連付けされるように決めていた。

一旦自分たちのニーズに合わせて調節すれば、新しいコンフィギュレーションを直接レポジトリーから実行することができます。

kubectl create -f prometheus-monitoring-guide/operator/service-prometheus.yaml

Prometheus Operatorが新しいAPIオブジェクトに気づいて、所定のデプロイメントをあなたに代わって生成してくれるでしょう。

prometheus-service-prometheus-0 3/3 Running 1 12m
prometheus-service-prometheus-1 3/3 Running 1 12m

それらのどのポッドのインターフェイスにコネクトしても、私たちはどんなメトリックターゲットも持っていないということに気づくでしょう。私たちは、スクレープするサービスが必要です。もしあなたが何かを既にインストールして、それを使いたいとおもっているのであれば素晴らしいです！一方、私たちは素早く簡単にHelmを使ってアプリを走らせることができます。

CoreDNS は早くてフレキシブルなDNSサーバーです。Cloud Native Computing Foundationのまだ始まったばかりのプロジェクトです。そのためもしあなたが自分のクラスターに伴ったhelmセットアップを持っているのであれば、走らせましょう。

kubectl create ns coredns
helm install — name coredns — namespace=coredns stable/coredns

CoreDNSはPrometheusメトリックをエクスポーズします（ポート9153を使用）：

kubectl get svc -n coredns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
coredns-coredns ClusterIP 10.11.253.94 <none> 53/UDP,53/TCP,9153/TCP 3m

さてそれでは、自分のServices Prometheusデプロイメントとこの新しいサービスをServiceMonitorを使って接続してみます。（下のレポジトリーからこのファイルを見つけることができます）

<code>

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
serviceapp: coredns-servicemonitor
name: coredns-servicemonitor
namespace: monitoring
spec:
endpoints:
- bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
interval: 15s
port: metrics
namespaceSelector:
matchNames:
- coredns
selector:
matchLabels:
release: coredns

それを自分のクラスターに入れます。

kubectl create -f prometheus-monitoring-guide/operator/servicemonitor-coredns.yaml

２，３秒後、もしPrometheusインターフェイスの中のスクレープ・ターゲットを見るのであれば、どのようにコンフィグレーションが自動的にアップデートされたかを見ることができますし、このターゲットからメトリックを受け取ります。

そして、このCoreDNSデプロイメントのために、もしサービングポッド（そしてこのようにメトリックエンドポイントの数も）の数を増やすのであれば：

helm upgrade coredns stable/coredns — set replicaCount=3

全てのターゲットは自動的にServiceMonitorによって検出され、自分のPrometheusコンフィグレーションの中に登録されます。

Prometheus Operator — How to configure Alert Rules

私たちは自分のPrometheusデプロイメントの中でKubernetesモニタリング・アラートをコンフィギュアすることができます。ServiceMonitorのコンセプトににとても似ているPrometheusRule CRDというコンセプトを用いています。

私たちが、自分たちのPrometheusデプロイメントを設定した時、フィルターに通すため、そしてそれらのオブジェクトにマッチさせるためのコンフィグレーションブロックがありました。

ruleSelector:
matchLabels:
prometheus: service-prometheus
role: alert-rules

自分で希望して、その希望したメタデータに合うPromQLルールを含むオブジェクトを設定するときには、それらは自動的にPrometheusサーバーコンフィギュレーションに追加されます。（下のレポジトリーからこのファイルを見つけることができます）

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
prometheus: service-prometheus
role: alert-rules
name: prometheus-service-rules
namespace: monitoring
spec:
groups:
- name: general.rules
rules:
- alert: TargetDown-serviceprom
annotations:
description: ‘{{ $value }}% of {{ $labels.job }} targets are down.’
summary: Targets are down
expr: 100 * (count(up == 0) BY (job) / count(up) BY (job)) > 10
for: 10m
labels:
severity: warning
- alert: DeadMansSwitch-serviceprom
annotations:
description: This is a DeadMansSwitch meant to ensure that the entire Alerting
pipeline is functional.
summary: Alerting DeadMansSwitch
expr: vector(1)
labels:
severity: none

そのレポジトリーから取り入れます：

kubectl create -f prometheus-monitoring-guide/operator/prometheusrules.yaml

それらのアラートをすぐにそのservice-prometheusインターフェイスから調べることができます。もし外部のingressをコンフィギュアしたくないのであれば、ローカルのport-forwardを使ってください。

kubectl port-forward prometheus-service-prometheus-0 -n monitoring 9090:9090

Prometheusサーバーインターフェイスの中のAlertsタブにアクセスしてください。

DeadManSwitchはいつも発動するアラートのための共通の名前です。（いつもtrueになる評価をするファイアリングコンディションを持ちます）そして、それは自分のアラートパイプラインが予測していたように動いているかどうかチェックするためにそこにあります。数秒後、この状態はロードされ、明るい赤い背景のアラートネームが見えます（発動しています）。上の写真のようになります。

もしあなたが今Alertmanagerインターフェイスを開けると（ポート9093）、そのアラートがこのPrometheusデプロイメントから来ているのが見えます。もし外部のingressをコンフィギュアしたくないのであれば、ローカルのport-forwardを使ってください。

kubectl port-forward alertmanager-main-0 -n monitoring 9093:9093

Prometheus Operator — Defining Grafana Dashboards

今日のように、Prometheus Operatorの中にはGrafanaコンポーネントのためのカスタムリソース設定はありません。Grafanaコンフィギュレーションを管理するためには、新しいデータソースと新しいダッシュボードを含むKubernetes secretとConfigMapを使います。

Prometheus Operatorを使ってデプロイされたGrafanaを使う時には、データソースはGrafanaがKubernetes secretから読むbase64を使ってエンコードされたデータ構造として設定されます。

もし、自分の現在のsecretデータをエンコードする場合は、これと似たようなものを見る必要があります.

kubectl get secret grafana-datasources -n monitoring -o jsonpath — template ‘{.data.prometheus.yaml}’ | base64 -d
{
“apiVersion”: 1,
“datasources”: [{
“access”: “proxy”,
“editable”: false,
“name”: “prometheus”,
“orgId”: 1,
“type”: “prometheus”,
“url”: “http://prometheus-k8s.monitoring.svc:9090",
“version”: 1
}]
}

私たちは、ただ同じJSONフォーマットを使って新しいデータソースを追加し、base64としてsecret dataを再エンコードしてsecretをアップデートする必要があります。

この新しいファイルを作成しましょう。

{
“apiVersion”: 1,
“datasources”: [
{
“access”: “proxy”,
“editable”: false,
“name”: “prometheus”,
“orgId”: 1,
“type”: “prometheus”,
“url”: “http://prometheus-k8s.monitoring.svc:9090",
“version”: 1
},
{
“access”: “proxy”,
“editable”: false,
“name”: “service-prometheus”,
“orgId”: 1,
“type”: “prometheus”,
“url”: “http://service-prometheus.monitoring.svc:9090",
“version”: 1
}
]
}

シークレットオブジェクトの中でそれをカプセル化します（自分自身のファイル、もしくは下に示したようなレポジトリーなどを使ってください）

kubectl create secret generic grafana-datasources -n monitoring — from-file=./prometheus-monitoring-guide/operator/grafana/prometheus.yaml — dry-run -o yaml > grafana-datasources.yaml

そしてAPIの中のGrafanaシークレットをパッチします：

kubectl patch secret grafana-datasources -n monitoring — patch “$(cat grafana-datasources.yaml)”

そのデータソースは、サービスを指しているということを覚えておいてください（Prometheusポッドではなく）、あなたはこのファイルを使ってservice-prometheus.monitoring.svcサービスを生成する必要があります。

kubectl create -f prometheus-monitoring-guide/operator/prometheus-svc.yaml

最後にGrafanaをリスタート（再スタート）します：

kubectl delete pod grafana-5568b65944-szhx4 -n monitoring

そして、UI (もし必要なら再度port-forwardを使ってください, port 3000)の中のdatasources タブに行って、両方のデータソースとしてのPrometheusデプロイメントを見る必要があります。

Prometheus Operatorを使うことで、GrafanaダッシュボードはKubernetes ConfigMapの中でただDashboard JSONデータのエンコードだけを外部からロードされることになります。

kubectl get cm -n monitoring
NAME DATA AGE
grafana-dashboard-k8s-cluster-rsrc-use 1 20d
grafana-dashboard-k8s-node-rsrc-use 1 20d
grafana-dashboard-k8s-resources-cluster 1 20d
grafana-dashboard-k8s-resources-namespace 1 20d
grafana-dashboard-k8s-resources-pod 1 20d

それらのConfigMapは明確にGrafanaのデプロイメント設定で入れ込まれています。

kubectl get deployments grafana -n monitoring -o yaml
…
- mountPath: /grafana-dashboard-definitions/0/pods
name: grafana-dashboard-pods
…
- configMap:
defaultMode: 420
name: grafana-dashboard-pods
name: grafana-dashboard-pods

ダッシュボードごとに新しいConfigMapを作成してもいいし、Grafanaポッドを管理するデプロイメントの設定の中で対応したエンティティを追加することも可能です。

他には、よりフレキシブルな選択肢として、Grafana Helmチャートを使うと、この章の2番目のテーマで話したようなDashboardコンフィギュレーションの自動的なアップデート もできます。

Conclusions

Prometheus Operatorを使用することで、私たちはより簡単にそしてよりデクレラティブにより再生力の高い方法でKubernetesモニタリングスタックを構築することができました。スケールすることも、モディファイしたり、異なるホストのセットに移動させるのも簡単にできます。

今のところ、私たちはPrometheusテクノロジースタックを使ったKubernetes clusterのモニタリングの素晴らしい可能性や大まかな要点、メリットについて話してきました。大きなデプロイメントに行く前に、例えば以下のような注意点を覚えておいてください。

• Long term storage（長期的保存）: 以前お話したように、Prometheus は長期的な保存については考慮していません。(そしてバックアップやデータの冗長性、トレンド分析、データマイニングなどにすごく近い考え方です) この章の2番目のテーマでは、完全な保存のための解決策の基本的な構成要素を提供してくれる最小のRook デベロップメントについて説明しています。
• Authorization and Authentication（認証と認可）: プロジェクト関連の文書で指摘されているおうにPrometheusとそのコンポーネントはどんなサーバー側の認証、認可、また暗号化にも対応していません。アクセスの異なるレベルのユーザーグループも他のRBAC フレームワークも存在しません。
• Vertical and Horizontal scalability（垂直方向と水平方向のスケーラビリティ）: そこまでたくさんの欠点はありませんが、自分のターゲットのキャパシティーについて事前にきちんと多くの情報を得た上で計画を立てる必要があります。私たちはこの説明の一番最後の部分でPrometheusのパフォーマンスに関してや、高可用性とフェデレーションについて述べています。

より分かりやすいPrometheusとSysdigのような商業的なモニタリングプラットフォームの比較についてはこちらをお読みください。PrometheusモニタリングとSysdigモニター:技術的な比較

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。