OpenShift Monitoring - 自律化したPrometheus運用 -

以下で利用した資料です。

OpenShift 実践ウェビナー
〜エンタープライズコンテナ運用９つのコツ〜
【第７回】Prometheusによるクラスタ/コンテナモニタリング
2020年 5月 14日 16:00 JST (UTC+ 9)

Transcript

1. 自律化した 運用
   

   View Slide

2. View Slide

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

   View Slide

4. コンテナのモニタリング
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

11. の
    ▶
    ▶
    ▶
    が示す に準拠
    

    View Slide

12. の仕組み
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

22. インスタンス管理
    の を動的に定義します。
    は常に、 に一致する が実行
    されていることを確認します。
    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
    

    View Slide

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

    View Slide

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

    View Slide

25. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

29. の設定
    内の
    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
    …
    初期設定の「 」にて
    が決まっている
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. 作成
    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: |
    :
    
    設定を に で記載
    例 のローカル永続ストレージ を要求
    

    View Slide

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

    View Slide

36. の設定
    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=-
    継続的に実行される アラートが同梱され
    ています。 は、 などの通
    知プロバイダーに、 アラートの通知を送信
    できます。
    例 に通知を送信
    

    View Slide

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

    View Slide

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

    View Slide

39. View Slide

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

    View Slide

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

    View Slide

42. 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
    の から
    個別サービスモニタリン
    グの有効化
    とメトリクス取得用
    が起動
    

    View Slide

43. 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
    サービスを行っている に を定義することで、アプリケーションモニタリング用のメト
    リクス設定が行える。
    

    View Slide

44. # 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
    にて参照権限を与えられたメンバーのみが、
    からメトリクス情報を参照できる。
    の情報
    

    View Slide

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

    View Slide

46. によるモニタリング
    は、 のシステムコールの実行を検出してルー
    ルに基づいて警告できます。
    たとえば、 は次のようなコンテナランタイムの操作を
    検出できます。
    ・コンテナ内でのシェルの実行
    ・サーバープロセスが予期しない子プロセスの生成
    ・機密ファイル など の読み取り
    ・非デバイスファイル など への書き込み
    ・特定バイナリによる、ネットワーク接続の確立
    など
    - 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]
    

    View Slide

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

    View Slide

48. まとめ
    

    View Slide

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

    View Slide

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

    View Slide

51. View Slide