Prometheus+k 8 s-HyperLedger Fabricの監視運転実戦
4597 ワード
Fabric1.4バージョンはマイルストーン式のバージョンで、最初のLTSのバージョン(Long Term Supportのバージョン)です.1.4バージョンで発表されたノードデータ指標収集インタフェースは、fabricのメンテナンス性と監視性を大幅に向上させ、生産環境の安定した運行に有利であることを意味していると考えています.次に、fabric 1.4バージョンのデータ指標の収集、表示、アラートについて詳しく説明します.
まずfabric 1.4のOperation Servicesデータ指標に関するドキュメントの説明を参照してください.
Configuring Metrics
Fabric provides two ways to expose metrics: a pull model based on Prometheus and a pushmodel based on StatsD.
fabricはPrometheusというプルモデルとStatsDというプッシュモデルに基づく2つの方法で指標データを取得する.ここではPrometheusというプルモデルで紹介します.
一. Prometheus Operator
我々fabricはk 8 s環境に配備されており、coreosにはオープンソースプロジェクトPrometheus Operatorがあり、k 8 s上でprometheusを配備、管理することができます.その利点はk 8 sベースのCustomResourceDefinitionに現れ、このプロジェクトではprometheus/serviceMonitorなどのresource typeを定義し、k 8 sのmatchLabelラベルを通じて動的に特定のコンテナグループにprometheusノードを割り当てることができる.また、prometheusRule、alertmanagerなどのresource typeは、迅速なアラートサービスの構成を実現します.ユーザーは、k 8 sの対応するresourceを簡単に作成することで、prometheusノード、モニタリングサービス、およびアラートサービスを動的に管理できます.具体的にはthe prometheus operatorを参照してください.
readmeでは、prometheus-operatorプロジェクトは、prometheusがk 8 sのオリジナルプラットフォーム上で構成されることをサポートし、k 8 s上でprometheusとalertmanagerを管理できることがわかります.ここでkube-prometheusディレクトリの下にはprometheusモニタリングk 8 sとk 8 sで実行されるリソース定義が提供されています.つまり、prometheusでk 8 sクラスタをモニタリングする必要がある場合、またはprometheusモニタリングでk 8 sクラスタに配備されたアプリケーションをモニタリングする必要がある場合、kube-prometheusを直接使用することができます.kube-prometheusディレクトリの下でkubectl apply-f manifests/を直接実行できます.
注意:このコマンドは、すべてのリソースが作成されるまで複数回実行する必要があります. ミラーをdockerプライベートミラーウェアハウスに転送する必要がある場合は、yamlファイルのimageラベルに対応するミラーアドレスを手動で変更する必要があります.yamlファイルにはimagePullSecretsを追加できます.その他のサポートされているプロパティは、対応するリソースタイプのdefinitionファイルを表示できます.
grafanaとprometheusに直接アクセスできるWebページを実行しました. prometheusホームページ/targetsにアクセスし、各指標のモニタリング状態を表示し、異常がなければstateはUP状態であるべきである. grafanaのホームページにアクセスし、データソースをprometheusに正しく構成すると、事前に定義されたk 8 sモニタdashboardを表示できます.
二.fabricモニタリング指標収集&構成
0 prometheus-operator-0 prometheusCustomResourceDefinition.yamlでは、prometheusリソースの配置を定義し、prometheusノードを指定することで、serviceMonitorNamespaceSelectorでnamespace範囲を指定したり、serviceMonitorSelectorでserviceMonitorの範囲を指定したりすることができます.githubソースコードのprometheus-prometheus.yamlで定義された2つのプロパティは、anywhereです.したがって理論的には任意のserviceMonitorに作用することができる.
ServiceMonitorは特定のリソースがk 8 sにマッチするオリジナルのサービスリソースであり、サービスMonitorではモニタリングしたいmetricサービス範囲(labelMatch)やmetricsのendpointを引くinterval(時間間隔)、port(サービスで定義されたポート)などの属性を定義することができる.
監視が必要なfabric peerノードとordererノードをドキュメントの説明に従って事前に構成し、k 8 sで8443ポートに対応するサービスを定義する必要があります.次に、ordererを例に挙げてserviceMonitorを定義します.
実行後、prometheus UIにfabric-ordererがないことがわかりました.なぜならprometheusノードはmonitoring namespaceに配備されており、他のnamespaceにアクセスするには権限上許可されていないためです.k 8 sのrbacと組み合わせてprometheus serviceMonitorに対応するアクセスポリシーが必要です.
修正するyaml:
ClusterRoleリソースを再配置し、prometheusはfabric-ordererのmetricに成功しました.
三.fabricモニタリング指標リモートストレージ
prometheusのストレージにはデフォルトで有効期限があり、Promtheusがローカルディスクに基づいて実装した時系列データベースにデータを保存します.その後の継続的なメンテナンスモニタリングのために、企業は一般的にprometheusが収集した指標データを専門のタイミングデータベースに転送します.携程モニタリングシステムhickwallは、influxdbをタイミングデータベースとしてサポートし、prometheusが収集した指標を保存するために使用できます.
ここでは、prometheusプロジェクトのremote-storage-adapterをリモートストレージ中継として使用し、コードパッケージ生成ミラーをk 8 sに配備し、リモートストレージデータベースをinfluxdbとし、prometheus-prometheusを変更する.yamlの増加:
これでfabric指標データの収集・アーカイブが完了する.
四.fabricモニタリング指標モニタリング&アラーム
携程は携程自研のhickwallが指標の監視と警報を行い、実際にはkube-prometheusが提供するalertmanagersを警報サービスとして使用することができる.
kube-prometheusはk 8 sのモニタリングdashboardを提供し、fabricのモニタリングdashboardについて参考にした.https://github.com/xuchenhao001/hyperlookプロジェクトのdashboard.
まずfabric 1.4のOperation Servicesデータ指標に関するドキュメントの説明を参照してください.
Configuring Metrics
Fabric provides two ways to expose metrics: a pull model based on Prometheus and a pushmodel based on StatsD.
fabricはPrometheusというプルモデルとStatsDというプッシュモデルに基づく2つの方法で指標データを取得する.ここではPrometheusというプルモデルで紹介します.
一. Prometheus Operator
我々fabricはk 8 s環境に配備されており、coreosにはオープンソースプロジェクトPrometheus Operatorがあり、k 8 s上でprometheusを配備、管理することができます.その利点はk 8 sベースのCustomResourceDefinitionに現れ、このプロジェクトではprometheus/serviceMonitorなどのresource typeを定義し、k 8 sのmatchLabelラベルを通じて動的に特定のコンテナグループにprometheusノードを割り当てることができる.また、prometheusRule、alertmanagerなどのresource typeは、迅速なアラートサービスの構成を実現します.ユーザーは、k 8 sの対応するresourceを簡単に作成することで、prometheusノード、モニタリングサービス、およびアラートサービスを動的に管理できます.具体的にはthe prometheus operatorを参照してください.
readmeでは、prometheus-operatorプロジェクトは、prometheusがk 8 sのオリジナルプラットフォーム上で構成されることをサポートし、k 8 s上でprometheusとalertmanagerを管理できることがわかります.ここでkube-prometheusディレクトリの下にはprometheusモニタリングk 8 sとk 8 sで実行されるリソース定義が提供されています.つまり、prometheusでk 8 sクラスタをモニタリングする必要がある場合、またはprometheusモニタリングでk 8 sクラスタに配備されたアプリケーションをモニタリングする必要がある場合、kube-prometheusを直接使用することができます.kube-prometheusディレクトリの下でkubectl apply-f manifests/を直接実行できます.
注意:
grafanaとprometheusに直接アクセスできるWebページを実行しました.
二.fabricモニタリング指標収集&構成
0 prometheus-operator-0 prometheusCustomResourceDefinition.yamlでは、prometheusリソースの配置を定義し、prometheusノードを指定することで、serviceMonitorNamespaceSelectorでnamespace範囲を指定したり、serviceMonitorSelectorでserviceMonitorの範囲を指定したりすることができます.githubソースコードのprometheus-prometheus.yamlで定義された2つのプロパティは、anywhereです.したがって理論的には任意のserviceMonitorに作用することができる.
ServiceMonitorは特定のリソースがk 8 sにマッチするオリジナルのサービスリソースであり、サービスMonitorではモニタリングしたいmetricサービス範囲(labelMatch)やmetricsのendpointを引くinterval(時間間隔)、port(サービスで定義されたポート)などの属性を定義することができる.
監視が必要なfabric peerノードとordererノードをドキュメントの説明に従って事前に構成し、k 8 sで8443ポートに対応するサービスを定義する必要があります.次に、ordererを例に挙げてserviceMonitorを定義します.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
namespace: fabric
name: fabric-orderer
labels:
application: fabric-orderer
spec:
selector:
matchLabels:
application: fabric-orderer
endpoints:
- port: orderer-metrics # works for different port numbers as long as the name matches
interval: 10s # scrape the endpoint every 10 seconds
namespaceSelector:
any: true
実行後、prometheus UIにfabric-ordererがないことがわかりました.なぜならprometheusノードはmonitoring namespaceに配備されており、他のnamespaceにアクセスするには権限上許可されていないためです.k 8 sのrbacと組み合わせてprometheus serviceMonitorに対応するアクセスポリシーが必要です.
修正するyaml:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prometheus-k8s
rules:
- apiGroups: [""]
resources:
- nodes
- services
- endpoints
- pods
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources:
- configmaps
verbs: ["get"]
- apiGroups:
- ""
resources:
- nodes/metrics
verbs:
- get
- nonResourceURLs:
- /metrics
verbs:
- get
ClusterRoleリソースを再配置し、prometheusはfabric-ordererのmetricに成功しました.
三.fabricモニタリング指標リモートストレージ
prometheusのストレージにはデフォルトで有効期限があり、Promtheusがローカルディスクに基づいて実装した時系列データベースにデータを保存します.その後の継続的なメンテナンスモニタリングのために、企業は一般的にprometheusが収集した指標データを専門のタイミングデータベースに転送します.携程モニタリングシステムhickwallは、influxdbをタイミングデータベースとしてサポートし、prometheusが収集した指標を保存するために使用できます.
ここでは、prometheusプロジェクトのremote-storage-adapterをリモートストレージ中継として使用し、コードパッケージ生成ミラーをk 8 sに配備し、リモートストレージデータベースをinfluxdbとし、prometheus-prometheusを変更する.yamlの増加:
remoteWrite:
- url: "http://prom-remote-s.monitoring:9201/write"
これでfabric指標データの収集・アーカイブが完了する.
四.fabricモニタリング指標モニタリング&アラーム
携程は携程自研のhickwallが指標の監視と警報を行い、実際にはkube-prometheusが提供するalertmanagersを警報サービスとして使用することができる.
kube-prometheusはk 8 sのモニタリングdashboardを提供し、fabricのモニタリングdashboardについて参考にした.https://github.com/xuchenhao001/hyperlookプロジェクトのdashboard.