1クラウドネイティブモニタリングのデファクトスタンダードであるPromethues：
監視システムは長い歴史があり、かなり成熟した分野です。新世代のオープンソース監視システムとして、Prometheusは徐々にクラウドネイティブ監視の事実上の標準になり、その設計が業界で認められていることも証明しています。Prometheusは、Googleのボルグモン監視システムに触発されました。2012年にコミュニティオープンソースプロジェクトとしてGoogleの元従業員によって作成および開発され、2015年に正式にリリースされました。2016年、Prometheusは正式にCloud Native Computing Foundationに参加し、Kubernetesに次ぐ2番目に優れたプロジェクトになりました。
1.1アーキテクチャ
1.1.1コンポーネントの概要
Prometheusサーバーの
コアコンポーネントは、外部からメモリ時系列データベースにインジケータをアクティブに取得し、メモリ内のインジケータをディスクに定期的に同期する役割を果たします。
Alertmanager
は、Prometheusサーバーから送信されたアラート情報を外部のアラート受信者に転送します。
Pushgatewayで
監視されているオブジェクトは、インジケーターをPushgatewayにアクティブにプッシュでき、PushgatewayインジケーターはPrometheusサーバーによってキャプチャされます。
Promethues Web UI
Prometheusサーバーインターフェイス。関連するインジケーターデータをクエリする式を入力します。
1.1.2ワークフロー
Prometheusのワークフローの中核は、プルをアクティブにプルすることによって監視対象オブジェクトのメトリックデータ（監視インジケータデータ）を収集し、これらのメトリックデータをメモリTSDB（時系列データベース）に格納し、定期的にメモリにデータを格納することです。インジケータは同期されます。ローカルハードディスクに。このコアワークフローでは、残りのコンポーネントはこのワークフローに一致するだけです。監視対象オブジェクトはメトリックをPushgatewayコンポーネントにプッシュすることもでき、Prometheusは最終的にメトリックをPushgatewayコンポーネントからTSDBにプルします。Altermanagerコンポーネントは、Prometheusアラームを外部レシーバーに転送するルーターのようなものです。
1.2利点
Prometheusには、次の魅力的な利点があります
。1）強力な多次元データモデル
2）柔軟で強力なクエリステートメント（PromQL）：同じクエリステートメントで、複数のメトリックを乗算、追加、接続、スコアリングできます。
3）管理が簡単：Prometheusサーバーは、分散ストレージに依存せずにローカルで直接動作できる別個のバイナリファイルです。
4）高効率：平均して、各サンプリングポイントは3バイトしか占有せず、Prometheusサーバーは数百万のメトリックを処理できます。
5）プルモードを使用して時系列データを収集します。これは、ローカルテストに役立つだけでなく、問題のあるサーバーが不正なメトリックをプッシュすることも回避します。
6）時系列データは、プッシュゲートウェイを使用してPrometheusサーバーにプッシュできます。
7）監視ターゲットは、サービス検出または静的構成を通じて取得できます。
8）さまざまな視覚的なグラフィカルインターフェイスがあります。
9）多くのアプリケーションは、Prometheusが収集する独自のデータインジケーターを公開するために、Prometheusのメトリックインターフェイスを実装しています。適応されていない多くのアプリケーションには、Prometheusへの適応を支援するサードパーティのエクスポーターもあります。
1.3制限
1.3.1クラスター展開なし
Prometheus自体はスタンドアロン展開のみをサポートし、クラスター展開を独自にサポートしていません。クラスター化と水平展開については、公式もコミュニティも特効薬を持っていません。Federate、Cortex、Thanosなどを合理的に選択する必要があります。オープンソースソリューションまたは自己開発ソリューション。
1.3.2ストレージ容量
そのストレージスペースは、単一のマシンのディスク容量によっても制限されます。ディスク容量は、単一のPrometheusが保存できるデータの量を決定します。データの量は、収集されたサービスのインジケーターの数、サービスの数、収集率、およびデータの有効期限。大量のデータの場合、重要でないインジケーターの破棄、収集率の低下、データの有効期限の短縮など、多くのトレードオフが必要になる場合があります。
1.3.3不正確な監視システム
設計上のトレードオフ：データの精度の一部を放棄し、信頼性を高めるために少しの精度を放棄すると、監視システムの可用性は一般に一貫性よりも高くなり、コピーデータの一部の損失を許容し、成功を保証しますクエリリクエストの。Prometheusは、必ずしもデータの正確性を保証するものではありません。ここでの不正確さは、次の2つの側面から生じます
。1）rateやhistogram_quantileなどの数学関数。
2）クエリ範囲が長すぎる場合、ダウンサンプリングが必要になり、必然的にデータの精度が低下します。
1.4リソース消費
6つのノードを持つkuberntesクラスター（インジケーターは主にkubeletサービス、node-exporterサービス、kube-apiserver、kube-controllerなどのコアサービスから取得されます）では、単一のPrometheusインスタンスが0.1〜0.4cpuおよび2.5G〜を消費します。 3Gメモリ。
1.5Prometheus高可用性ソリューション
1.5.1業界のPrometheus高可用性ソリューションの概要：
1）基本的なHA：つまり、2セットのPrometheusがまったく同じデータを収集し、負荷分散が外部に接続されます。
2）HA +リモートストレージ：基本的なマルチコピーPrometheusに加えて、リモート書き込みを介してリモートストレージに書き込み、ストレージの永続性の問題を解決します。
3）フェデレーションクラスター：機能に応じて分割されたフェデレーション。異なるシャードが異なるデータを収集し、グローバルノードによって統一された方法で保存され、監視データの規模の問題を解決します。
ThanosまたはVictoriametricsを使用して、グローバルクエリとマルチコピーデータ結合の問題を解決します。
公式に推奨されている複数のコピーとフェデレーションを使用している場合でも、いくつかの問題が発生します。
公式の推奨事項は、データシャードを作成し、フェデレーションを使用して高可用性を実現することです
が、エッジノードとグローバルノードは依然として単一のポイントであり、各レイヤーを使用するかどうかを決定する必要があります。キープアライブにデュアルノードの繰り返し収集を使用するには。
本質的な理由は、Prometheusのローカルストレージにはデータを同期する機能がないためです。可用性を確保するという前提でデータの整合性を維持することは困難です。基本的なHAプロキシは、次の要件を満たすことができません。たとえば、クラスタにはAとBがあります。2つのインスタンスAとBの間にデータの同期はありません。Aが一定期間ダウンし、一部のインジケーターデータが失われます。ロードバランサーが正常にポーリングすると、リクエストがAにヒットしたときにデータが異常になります。
1.5.2高可用性Prometheusデータの一貫性を強化するためのアイデア
解決策は、ストレージとクエリの2つの観点からデータの一貫性を確保することです。
1.5.2.1保管角度
リモートストレージにリモート書き込みを使用する場合は、AとBの両方の後にアダプターを追加できます。アダプターはメインの選択ロジックとして機能します。TSDBにプッシュできるデータは1つだけです。これにより、1つの例外を正常にプッシュできます。もう1つは、データを失うことなく正常にプッシュできます。同時に、共有データであるリモートストレージのコピーは1つだけです。
1.5.2.2クエリ角度
ストレージソリューションの実装は複雑で、特定のリスクがあります。そのため、ThanosやVictoriametricsなど、現在のソリューションのほとんどはクエリレベルで大騒ぎしています。データはまだ2つありますが、クエリではデータの重複排除と結合が使用されます。 。ThanosがSidecarを介してオブジェクトストレージにデータを配置し、Victoriametricsが独自のサーバーインスタンスにデータをリモートで書き込むだけですが、クエリレイヤーThanos-QueryとVictor'sPromxyのロジックは基本的に同じです。
2プロメテウスのソリューションを拡張する
2.1コルテキスト
2.1.1概要
Cortex（https://cortexmetrics.io）は、Prometheusに水平方向にスケーラブルで、可用性が高く、マルチテナントの長期ストレージを提供します。現在、cncfサンドボックスでハッチングされています。
Cortexは、Prometheusに、水平方向にスケーラブルで可用性の高いマルチテナントの長期ストレージを提供します。Cortexは、WeaveCloudやGrafanaCloudなどの複数の本番システムで使用されるCNCFサンドボックスプロジェクトです。Corteは、主にPrometheusのリモート書き込み用のストレージとして使用され、Prometheusと互換性のあるクエリAPIを提供します。
2.1.2業界慣行
2.1.3機能
1）水平方向のスケーラビリティ：Cortexは、クラスター内の複数のマシンで実行でき、単一のマシンのスループットとストレージ容量を超えます。これにより、複数のPrometheusサーバーから単一のCortexクラスターにメトリックを送信し、単一の場所にあるすべてのデータに対して「グローバル集約」クエリを実行できます。
1）高可用性：Cortexは、クラスターで実行されている場合、マシン間でデータを複製できます。このようにして、チャートに空白を残すことなく、マシンの障害に耐えることができます。
マルチテナンシー：Cortexは、単一のクラスター内の複数の異なる独立したPrometheusソースからデータとクエリを分離できるため、信頼できないパーティが同じクラスターを共有できます。
1）長期ストレージ：Cortexは、メトリックデータの長期ストレージ用にAmazon DynamoDB、Google Bigtable、Cassandra、S3、およびGCSをサポートしています。このようにして、どのコンピューターのライフサイクルよりも長くデータを永続的に保存し、このデータを長期的な容量計画に使用できます。
2.1.4アーキテクチャ
2.1.5コミュニティ活動
1）コミット配布：
2）136人のコード寄稿者がいます。
3）発行件数は211件です。
4）githubスターの数は3Kです。
2.2 VictoriaMetrics
2.2.1概要
VictoriaMetricsは、高速で費用効果が高く、スケーラブルな時系列データベースです。
バイナリディストリビューション、Dockerイメージ、ソースコードで利用できます。
VictoriaMetricsは、有料のエンタープライズサポートも提供しています。
業界慣行：アディダス、コロプラ、Wix.com、Wedos.comおよびその他の企業。
例：日本のゲーム会社COLOPL、3つのクラスターがVictoriaMetricsに接続されています。
2.2.2アーキテクチャ
2.2.3コミュニティ活動
1）コミット配布：
2）39人のコード貢献者がいます。
3）発行件数は141件です。
4）githubスターの数は2.8Kです。
2.3サノス
2.3.1概要
2018年9月に誕生したThanosは、Prometheusをベースにした一連のコンポーネントであり、無制限のストレージ容量を備えた高可用性インジケーターシステムを形成できます。ThanosはCNCFサンドボックスプロジェクトです。Thanosは、Prometheus 2.0ストレージ形式を利用して、クエリの待ち時間を短縮しながら、履歴インジケーターデータを任意のオブジェクトストレージにコスト効率よく保存します。さらに、すべてのPrometheusインストールのグローバルクエリビューを提供し、PrometheusHAペアのデータを即座にマージできます。
2.3.2会社の慣行
2.3.3アーキテクチャ
2.3.4機能
1）グローバルクエリビューを提供します。
2）信頼性の高い履歴データストレージを提供するために、主流のオブジェクトストレージをサポートします。
3）より広い時間範囲のインジケーターを提供するために、縮小された標準サンプリングをサポートします。
2.3.5コアコンポーネント
2.3.5.1サノスサイドカー
Sidecarは、サーバー上で別個のプロセスおよび既存のPrometheusインスタンスとして実行され、相互に影響を与えることはありません。Sidecarはプロキシコンポーネントと見なすことができ、PrometheusへのすべてのアクセスはSidecarのプロキシを介して実行されます。Sidecarを介して、収集されたデータをクラウドオブジェクトストレージサーバーに直接バックアップすることもできます。
2.3.5.2Thanosストアゲートウェイ
ストアゲートウェイは、Sidecarとまったく同じAPIのセットを実装し、SidecarによってクラウドオブジェクトストレージにバックアップされたデータをクエリするためのQuerierを提供します。Sidecarがデータのバックアップを完了した後、Prometheusはローカルデータをクリーンアップして、ローカルスペースが使用可能であることを確認するためです。したがって、監視担当者が履歴データを取得する必要がある場合、監視担当者はオブジェクトストレージスペースからのみ取得でき、ストアはそのようなインターフェイスを提供します。Store Gatewayは、データ取得を高速化するための最適化ロジックも作成しました。1つはTSDBインデックスをキャッシュすることで、もう1つはオブジェクトストレージのリモート呼び出し要求を最適化することです（必要なすべてのデータをできるだけ少ない要求で取得します）。
2.3.5.3Thanosクエリ
QuerierはSidecarとStoreゲートウェイからインジケーターデータを取得します。同時に、QuerierはPrometheusの公式HTTP APIのセットを実装して、Prometheusと整合性のあるデータソースインターフェイスを提供します。Grafanaは同じクエリインターフェイスを介して異なるクラスターからデータをリクエストできます。 Querierは、対応するクラスターを見つけてSidecarを介してデータを取得する責任があり、ストアゲートウェイからインジケーターデータを取得することもできます。Querier自体もステートレスで水平方向にスケーラブルであるため、高度に展開できます。Querierは、高度に展開可能なPrometheusのデータをマージして、複数のクエリ結果の一貫性を確保し、それによってPrometheusのグローバルビューと高可用性を解決できます。
Thanos Queryは、ダウンストリームにあるThanos Sidecarのインデックスデータをクエリし、Thanos Sidecarのインデックスデータは、それにバインドされたPrometheusインスタンスから取得されます。
2.3.5.4サノス定規
監視データを評価および警告したり、新しい監視データを計算したり、これらの新しいインジケータデータをクエリ用にThanos Queryに提供したり、インジケータデータをオブジェクトストレージにアップロードして長期保存したりできます。
2.3.5.5Thanosコンパクター
一般に、より広い時間範囲で監視データを表示する場合、そのような詳細なデータを取得する必要がない場合が多く、データの傾向を取得する場合が多くなります。コンパクターは、オブジェクトに格納されているデータを読み取り、圧縮してダウンサンプリングし、オブジェクトストレージにアップロードします。広い時間範囲のデータをクエリする場合は、圧縮されてダウンサンプリングされたデータのみが読み取られるため、データ量が大幅に削減されます。クエリを実行します。これにより、クエリが高速化されます。
注：Compactコンポーネントは、オブジェクトストレージに使用されるスペースを削減しませんが、サンプリング間隔が長くなるとインジケーターデータが増加するため、スペースが増加します。このように、広い時間範囲のデータをクエリする場合、より長い時間間隔でサンプリングされたデータが自動的にプルされ、クエリデータの総量が削減されるため、クエリが高速化されます（長い時間範囲のデータはそれほど正確である必要はありません）。インジケーター、および必要なものそれはトレンドです）、詳細を表示するためにズームインするとき（短い期間を選択）、短い時間範囲で詳細を監視できるように、より短いサンプリング間隔でデータをプルすることを自動的に選択しますまた、表示されます。
2.3.6。コミュニティ活動
253人のコード寄稿者がいます。
発行件数は120件です。
星の数は6.2Kです（すべての拡張されたプロメテウスソリューションの中で最も多い）。
3つの個人的なサノスの練習とテスト
Qhanos Sidecar、Thanos Query、Thanos Store Gateway、およびThanos Rulerコンポーネントがテストされ、Kubernetesクラスターにデプロイされました。バージョンは2020年1月にリリースされたv0.11です。
3.1。サノスサイドカー
Thanos Sidecarは、サイドカーの形でPrometheusと同じポッドにあります。Prometheusは複数のクラスターに分散しているため、ThanosSidecarは複数のクラスターに配置されています。Prometheusとthanosのサイドカーは、prometheus-operatorを介して展開されます。thanosサイドカーもnodePortを介して公開されます（クラスター内に2つのthanosサイドカーがあるため、nodePortは10901と10902に設定されます）。thanosサイドカーが公開される理由は、他のクラスターにあるthanosクエリコンポーネントのバックエンドストレージとしてです。
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
labels:
prometheus: k8s
name: k8s
namespace: monitoring
spec:
alerting:
alertmanagers:
- name: alertmanager-main
namespace: monitoring
port: web
image: quay.mirrors.ustc.edu.cn/prometheus/prometheus:v2.15.2
nodeSelector:
kubernetes.io/os: linux
podMonitorNamespaceSelector: {}
podMonitorSelector: {}
replicas: 2
resources:
requests:
memory: 400Mi
ruleSelector:
matchLabels:
prometheus: k8s
role: alert-rules
securityContext:
fsGroup: 2000
runAsNonRoot: true
runAsUser: 1000
serviceAccountName: prometheus-k8s
serviceMonitorNamespaceSelector: {}
serviceMonitorSelector: {}
version: v2.15.2
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
thanos:
baseImage: quay.mirrors.ustc.edu.cn/thanos/thanos
version: v0.11.0
objectStorageConfig:
key: objectstorage.yaml
name: thanos-objectstorage
externalLabels:
cluster: test
apiVersion: v1
kind: Service
metadata:
labels:
app: thanos-sidecar
statefulset.kubernetes.io/pod-name: prometheus-k8s-0
name: thanos-sidecar-0-external
namespace: monitoring
spec:
externalTrafficPolicy: Cluster
ports:
- name: grpc
nodePort: 10901
port: 10901
protocol: TCP
targetPort: grpc
selector:
prometheus: k8s
statefulset.kubernetes.io/pod-name: prometheus-k8s-0
sessionAffinity: None
type: NodePort
----
apiVersion: v1
kind: Service
metadata:
labels:
app: thanos-sidecar
statefulset.kubernetes.io/pod-name: prometheus-k8s-1
name: thanos-sidecar-1-external
namespace: monitoring
spec:
externalTrafficPolicy: Cluster
ports:
- name: grpc
nodePort: 10902
port: 10901
protocol: TCP
targetPort: grpc
selector:
prometheus: k8s
statefulset.kubernetes.io/pod-name: prometheus-k8s-1
sessionAffinity: None
type: NodePort
3.2Thanosクエリ
Thanos Queryは、デュアルコピーを使用したDeploymentの形式で別のクラスターにデプロイされるステートレスサービスです。構成ファイルを使用して、他のクラスターにあるthanosサイドカーを指定します。
説明：
1）いくつかの応答機能をオンにします。この時点で、バックエンドストアAPIの一部がエラーまたはタイムアウトを返した場合でも、正しい監視データを照会できます（バックエンドストアAPIの可用性が高い場合は、コピーを切ります。およびクエリアクセスハングしたコピーはタイムアウトしますが、他に使用可能なコピーがあるため、クライアントは正しいクエリ結果を取得できます。ハングしたバックエンドにクライアント自体が必要とするデータがない場合、クラッシュはクエリに影響しません。結果の正しさ）。
2）クエリの効率を向上させるために、クエリ中に自動ダウンサンプリングの機能をオンにします。
3.3Thanosストアゲートウェイ
ストアゲートウェイは、デュアルコピーを備えたStatefulSetの形式で独立したクラスターにデプロイされます。Thanosクエリコンポーネントを使用してStoreGatewayでサービス検出を実行するためのKubernetesヘッドレスサービスを作成します。
3.4サノス定規
Thanosルーラーは、StatefulSetおよびデュアルコピーの形式で独立したクラスター（thanosクエリと同じクラスター）にデプロイされます。そのためのKubernetesヘッドレスサービスを作成します。これは、Thanosクエリコンポーネントがクラスター内のThanosRulerでサービス検出を実行するために使用されます。さらに、ルールファイルが変更されたときに構成ファイルを再読み込みするために、ルーラーコンポーネント用の小さなイメージを作成しました。
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/name: thanos-rule
name: thanos-rule
namespace: monitoring
spec:
clusterIP: None
ports:
- name: grpc
port: 10901
targetPort: grpc
- name: http
port: 10902
targetPort: http
selector:
app.kubernetes.io/name: thanos-rule
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: thanos-rule
name: thanos-rule
namespace: monitoring
spec:
replicas: 2
selector:
matchLabels:
app.kubernetes.io/name: thanos-rule
serviceName: thanos-rules
podManagementPolicy: Parallel
template:
metadata:
labels:
app.kubernetes.io/name: thanos-rule
spec:
serviceAccount: thanos-rules
containers:
- name: reloader
image: registry.cn-shenzhen.aliyuncs.com/gzlj/thanos-reloader:v0.1
imagePullPolicy: Always
resources:
limits:
cpu: 100m
memory: 100Mi
- args:
- rule
- --grpc-address=0.0.0.0:10901
- --http-address=0.0.0.0:10902
- --rule-file=/etc/thanos/rules/*rules.yaml
- --objstore.config-file=/etc/thanos/objectstorage.yaml
- --data-dir=/var/thanos/rule
- --label=rule_replica="$(NAME)"
- --alert.label-drop="rule_replica"
- --query=dnssrv+_http._tcp.thanos-query.monitoring.svc.cluster.local
- --alertmanagers.url=http://alertmanager-main.monitoring.svc.cluster.local:9093
env:
- name: NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
image: quay.mirrors.ustc.edu.cn/thanos/thanos:v0.11.0
livenessProbe:
failureThreshold: 24
httpGet:
path: /-/healthy
port: 10902
scheme: HTTP
periodSeconds: 5
name: thanos-rule
ports:
- containerPort: 10901
name: grpc
- containerPort: 10902
name: http
readinessProbe:
failureThreshold: 18
httpGet:
path: /-/ready
port: 10902
scheme: HTTP
initialDelaySeconds: 10
periodSeconds: 5
terminationMessagePolicy: FallbackToLogsOnError
volumeMounts:
- mountPath: /var/thanos/rule
name: data
readOnly: false
- name: thanos-objectstorage
subPath: objectstorage.yaml
mountPath: /etc/thanos/objectstorage.yaml
- name: thanos-rules
mountPath: /etc/thanos/rules
volumes:
- name: thanos-objectstorage
secret:
secretName: thanos-objectstorage
- name: thanos-rules
configMap:
name: thanos-rules
- name: data
emptyDir: {}
3.5実験試験結果
3.5.1Prometheusメトリックの保持時間範囲を超えるクエリメトリック
3.5.2統合クエリパネル
clusterという名前の外部ラベルがPrometheus構成ファイルで指定された後、すべてのPrometheusインスタンスとオブジェクトストレージのメトリックをThanos Query UIで一度に照会でき、ユーザーがどのKubernetesを区別できるように、外部ラベルがメトリックに表示されます。メトリックが由来するクラスター。結果は次のとおりです。図に示すように、次のようになります。
3.5.3新しい指標を記録する
ThanosルールルールファイルはPrometheusルールファイルと互換性があります。Thanosルールルールファイルを作成し、configmapの形式でKubernetesクラスターに保存します。構成マップのコンテンツが更新されると、ルールインスタンスの構成ファイルの再読み込み専用のコンテナーがhttp要求をルールコンテナーに送信して、構成を再読み込みするようにルールコンポーネントに通知します。
ThanosクエリUIで新しいメトリックを照会できます。
3.5.4オブジェクトストレージ使用量の消費傾向
6ノードのkuberntesクラスター（インジケーターは主にkubeletサービス、node-exporterサービス、kube-apiserverなどのコアサービスから取得されます）の場合、1日のインジケーターを収集するPrometheusインスタンスの容量は1.5G-2Gです。 。
オブジェクトバケットに、3ノードのKubernetesクラスターと6ノードのKubernetesクラスターからのインジケーターを格納させます（2つのクラスターのインジケーターは、主にkubeletサービス、node-exporterサービス、kube-apiserverなどのコアサービスから取得されます）。毎日2Gの使用量と使用容量の増加傾向を下図に示します。
