自律化した 運用

No content

本日のアジェンダ コンテナのモニタリング の仕組み

コンテナのモニタリング

可観測性 は複雑であるため、クラスタ内の問題の 原因を特定することは困難です。 特定のノードに何か問題があるだけでなく、コンテナイ メージの不具合、 動作の異常、 の接続性 など、その原因は多岐にわたります。 サーバーやアプリに入って調査せずとも、システムの状態を把握すること

クラウドネイティブな監視 従来の監視 クラウドネイティブな監視 動的に監視を 運用できることがメリット

データを累積すること。一貫 性を有し、それぞれが一つの 論理的計量ユニット、あるい は一定時間内のヒストグラム に表す。 シングルリクエストの範囲内 にて情報処理を行うこと。 いかなるデータも、全てシス テムの単一トランザクションに バンディングされる。 いくつかの離散した(非連続 の)ことがらを、データとして記 述すること。 データ量

▶ イベントの集計した結果が時間ととも にどのように変化しているかを示す ▶ よく使われるメトリクスは、 リクエ スト数やリクエストの処理にかかったレ スポンスタイム、リソース使用量など ▶ コンテキストをフィルタリングすることで、 データ量や処理範囲を調整する

▶ つのリクエストの範囲で関数呼び出し などの複数のイベントを記録し、ボトル ネックがどこにあるのかを示す スタックトレース ▶プロセスをまたぐものは、分散トレーシ ングと呼ばれる ▶ サンプリングによってデータ量を保ちつ つ、パフォーマンスに及ぼす影響を適正 化する

▶ イベントのコンテキストの一部を記録 アクセスログ ▶ 特定のイベントにどのような問題があるのか を正確に特定できる ▶ 収集結果を保存するために大量のストレー ジと帯域が必要になる

の ▶ ▶ ▶ が示す に準拠

の仕組み

とは 型のメトリクス監視 側から各メトリクスを定期的に取得する 監視サーバは監視対象をすべて把握しているため、監視対象から データが取得できなかった場合には異常があると気づくことが容易 多くの を提供 による時系列データ検索 クラウド よりサービスの情報を取得できる 保管済みデータに対して集計クエリを発行できる 社によって開発され、 化されたプロダクト。現在は によってメンテナンスされている。

型のメトリクス監視 が監視対象の データを取得 監視対象から監視用データを 送信したい場合は に送信 scrape_configs: - job_name: 'node_exporter' static_configs: - targets: [‘targethost:9100'] を通して データを直接取得

$ curl https://[‘target exporter’]/metrics

• ごとに つの値を返す • 時間幅に渡るデータをそれぞれ含んで いる時系列の集合 • 単純な浮動小数点数の数値 • 単純な文字列の値 のデータは以下の 種類が規定されている。 ## Match Label {} node_load5{instance=‘XXX.XXX.XXX.XXX‘} 0.25 便利な統計関数がある • • • 期間中の平均値に対する現在値の割合を返す。 • 与えられた の中で、値の変化が何回起 こったかをカウント。 • 与えられた の絶対値を返す。 • 結果を昇順でソートする。 ## 直近1時間のデータを表示する node_load5[1h] ## 直近1時間のデータを表示する node_load5[1h]

route: receiver: 'containers_notification' receivers: - name: 'containers_notification' slack_configs: - api_url: '[[YOUR SLACK WEBHOOK]]' channel: '#general' text: "{{ .CommonAnnotations.summary }}" send_resolved: true は、以下を含む受信アラートを管理するコンポーネントです。 •アラートの非通知 •アラートの抑制 •アラートの集約 •アラートの重複排除 グループ化 • 、 、 、 などにアラートを通知

の全体像 が監視対象の データを取得 定期的に全ての からリソース情報 を収集。監視したデータは 内 の に保持される。 のメトリクスを可視化するツール 監視対象から監視用データを 送信したい場合は に送信 からのアラートに関する 情報を受け取って通知する

いままで人が対応してきた運用を が自律的に行う

と によって、 の監視設定、運用を自律化する。

展開を定義 します。 は常に と一致するデプロイメン トが実行されていることを確 認します。 を監視す る方法を宣言的に指定しま す。 は、定義に基づい て の 設定を自動的に生成します。 を監視する方 法を宣言的に指定します。 は、定義に基づい て の 設定を自動的に生成します。 展開を定 義します。オペレーターは常 に、 と一致するデプロイ メントが実行されていることを 確認します。 オブジェクトは宣言的に デプロイメントの望ましい状態を記述し、 は によって監視されるターゲットのセットを記述します。 必要な ルー ルファイルを定義します。これ は、 アラートお よび記録ルールを含む インスタンスに よってロードできます。 インスタンス管理 メトリクス取得対象設定 通知ルール設定 インスタンス管理

インスタンス管理 の を動的に定義します。 は常に、 に一致する が実行 されていることを確認します。 apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: generation: 2 labels: prometheus: k8s name: k8s namespace: openshift-monitoring spec: nodeSelector: kubernetes.io/os: linux serviceAccountName: prometheus-k8s replicas: 2 listenLocal: true serviceMonitorSelector: {} resources: requests: cpu: 200m memory: 1Gi

メトリクス取得対象設定 apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app labels: team: frontend spec: selector: matchLabels: app: example-app endpoints: - port: web を監視する方法を宣言的に指定します。 は、定義に基づいて の 設定を自動的に生成します。

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

No content

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

コンポーネント 説明 スタックの中心的なコンポーネントです。これは、デプロイされたモニタリングコンポーネントおよびリソースを 制御し、それらを最新の状態に保ちます。 および インスタンスを作成し、設定、管理します。また、 ラベルのク エリーに基づいてモニタリングターゲットの設定を自動生成します。 は、システムおよびサービスのモニタリングシステムであり、モニタリングスタックのベースとな ります。 アダプターは、 のクラスターリソースメトリクス を公開し ます。リソースメトリクスは およびメモリーの使用率です。 サービスは、 によって送信されるアラートを処理します。 は、 オブジェクトを が使用できるメトリクスに 変換します。 は、メトリクスを収集するためにすべてのノードにデプロイされるエージェントです。 は、メトリクスの分析および可視化のためのダッシュボードを提供します。モニタリングスタックおよ びダッシュボードと共に提供される インスタンスは読み取り専用です。

オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ によって管理された が「 」「 」に接続を行い、 オブジェク ト、ノードのメトリクスを収集する。

の設定 内の global: evaluation_interval: 30s scrape_interval: 30s external_labels: prometheus: openshift-monitoring/k8s prometheus_replica: prometheus-k8s-0 rule_files: - /etc/prometheus/rules/prometheus-k8s-rulefiles- 0/*.yaml scrape_configs: - job_name: openshift-apiserver-operator/openshift- apiserver-operator/0 - job_name: openshift-apiserver/openshift-apiserver/0 - job_name: openshift-authentication- operator/authentication-operator/0 - job_name: openshift-authentication/oauth- openshift/0 - job_name: openshift-cloud-credential- operator/cloud-credential-operator/0 … 初期設定の「 」にて が決まっている

から取得した オブジェクトのステート情 報は、 の に表示される。

「 」は、 固有のオブ ジェクトのメトリクスを取得します。 • • • • • • 例

から取得したノードの ステート情報は、 の に表示される。

による可視化 で提供される インスタンスは、そのダッシュボードとともに読み取り専用です。 カスタマイズしたい場合は、 が提供するコミュニティ版の を導入してください。 対象外です。

作成 apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | prometheusK8s: volumeClaimTemplate: metadata: name: localpvc spec: storageClassName: local-storage resources: requests: storage: 40Gi $ oc -n openshift-monitoring create configmap cluster-monitoring-config $ oc -n openshift-monitoring edit configmap cluster-monitoring-config の設定は、 を設定する。 data: config.yaml: | : 設定を に で記載 例 のローカル永続ストレージ を要求

の 一覧 の によって、 項目ほどのアラート ルールが設定されています。

の設定 global: resolve_timeout: 5m route: group_wait: 30s routes: - receiver: watchdog repeat_interval: 5m match: alertname: Watchdog - receiver: team-frontend-page match: severity: critical receivers: - name: default - name: watchdog - name: team-frontend-page pagerduty_configs: - service_key: "your-key" ## Export Secret $ oc -n openshift-monitoring get secret alertmanager- main --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml ## Edit Secret $ vi alertmanager.yaml ## Replace Secret $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry- run -o=yaml | oc -n openshift-monitoring replace secret --filename=- 継続的に実行される アラートが同梱され ています。 は、 などの通 知プロバイダーに、 アラートの通知を送信 できます。 例 に通知を送信

の変更可能な設定例 ・ の指定ノードへの移動 ・ への容認 の割り当て ・永続ストレージの設定 の設定、メトリクスデータの保持期間変更など ・ の設定 の追加など 参照：

対象外の操作 ・追加の オブジェクトを に作成する。 ・予期しない オブジェクト、または オブジェクトの作成。 ・ による の を停止する。 ・ を他のリソースで使用。 ・新規 の追加。 ・ のリソース、 インスタンスの変更。 に設定されているルールのカスタマイズは 対象外 クラスタの監視対象は、 に委ねられている

No content

の監視とは アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 オブジェクトのメトリクス収集 数、 のリソース利用量、 のラベル ノードのメトリクス収集 の 、 、 ▶ ▶ ▶ アプリケーションもノードも な設計 全て動的に監視が行われなければいけない。

とは異なる を配置し、それに を設定することで、アプリケーションのメ トリクスを収集する。 ただし、アプリケーション用の 用メトリク ス は事前に設定が必要。 アプリケーション固有のメトリクス収集 セッション数、リクエストレスポンスタイム、データ容量 ▶

apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: | techPreviewUserWorkload: enabled: true $ oc -n openshift-monitoring edit configmap cluster-monitoring-config $ oc -n openshift-user-workload-monitoring get pod NAME READY STATUS RESTARTS AGE prometheus-operator-85bbb7b64d-7jwjd 1/1 Running 0 3m24s prometheus-user-workload-0 5/5 Running 1 3m13s prometheus-user-workload-1 5/5 Running 1 3m13s の から 個別サービスモニタリン グの有効化 とメトリクス取得用 が起動

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: k8s-app: prometheus-example-monitor name: prometheus-example-monitor namespace: ns1 spec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-example-app サービスを行っている に を定義することで、アプリケーションモニタリング用のメト リクス設定が行える。

# HELP http_requests_total Count of all HTTP requests # TYPE http_requests_total counter http_requests_total{code="200",method="get"} 2 # HELP version Version information about this binary # TYPE version gauge version{version="v0.1.0"} 1 にて参照権限を与えられたメンバーのみが、 からメトリクス情報を参照できる。 の情報

の挙動をモニタリング は、 を活用して、システムコールをキャプチャし、アプリケーションの 異常な振る舞いを検出できる仕組み。 ▶ の のプロジェクト ▶ で使用可能な が提供 ▶ オープンソースとして提供 ▶ 社によって商用プロダクトとしても利用可能

によるモニタリング は、 のシステムコールの実行を検出してルー ルに基づいて警告できます。 たとえば、 は次のようなコンテナランタイムの操作を 検出できます。 ・コンテナ内でのシェルの実行 ・サーバープロセスが予期しない子プロセスの生成 ・機密ファイル など の読み取り ・非デバイスファイル など への書き込み ・特定バイナリによる、ネットワーク接続の確立 など - rule: Disallowed SSH Connection desc: Detect any new ssh connection to a host other than those in an allowed group of hosts condition: (inbound_outbound) and ssh_port and not allowed_ssh_hosts output: Disallowed SSH Connection (command=%proc.cmdline connection=%fd.name user=%user.name container_id=%container.id image=%container.image.repository) priority: NOTICE tags: [network, mitre_remote_service]

をベースに視覚 的に を作成できます。 ランタイムルールは、特定の 、 、 などにフィル ターを適用でき、複数のクラスタ 環境を統合的に管理できます。

まとめ

いままで人が対応してきた運用を が自律的に行う

徹底解説 無料プレゼント 「徹底解説 」 抜粋版 無料プレゼント 以下 より ダウンロードください。

No content