Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetes環境のオブザーバビリティの次の一歩をOpenTelemetryで実現すると...

Kubernetes環境のオブザーバビリティの次の一歩をOpenTelemetryで実現すると何がどうなるの? - CloudNative Days Winter 2024

CloudNative Days Winter 2024でのセッション資料です。
動画アーカイブは👉 https://event.cloudnativedays.jp/cndw2024/talks/2458

Kazunori Otani

December 11, 2024
Tweet

More Decks by Kazunori Otani

Other Decks in Technology

Transcript

  1. Forward- looking statements © 2024 SPLUNK LLC This presentation may

    contain forward-looking statements that are subject to the safe harbors created under the Securities Act of 1933, as amended, and the Securities Exchange Act of 1934, as amended. All statements other than statements of historical facts are statements that could be deemed forward-looking statements. These statements are based on current expectations, estimates, forecasts, and projections about the industries in which we operate and the beliefs and assumptions of our management based on the information currently available to us. Words such as “expects,” “anticipates,” “targets,” “goals,” “projects,” “intends,” “plans,” “believes,” “momentum,” “seeks,” “estimates,” “continues,” “endeavors,” “strives,” “may,” variations of such words, and similar expressions are intended to identify such forward-looking statements. In addition, any statements that refer to (1) our goals, commitments, and programs; (2) our business plans, initiatives, and objectives; and (3) our assumptions and expectations, including our expectations regarding our financial performance, products, technology, strategy, customers, markets, acquisitions and investments are forward-looking statements. These forward-looking statements are not guarantees of future performance and involve significant risks, uncertainties and other factors that may cause our actual results, performance or achievements to be materially different from results, performance or achievements expressed or implied by the forward-looking statements contained in this presentation. Readers are cautioned that these forward-looking statements are only predictions and are subject to risks, uncertainties, and assumptions that are difficult to predict, including those identified in the “Risk Factors” section of Cisco’s most recent report on Form 10-Q filed on February 20, 2024 and its most recent report on Form 10-K filed on September 7, 2023, as well as the “Risk Factors” section of Splunk’s most recent report on Form 10-Q filed with the SEC on November 28, 2023. The forward-looking statements made in this presentation are made as of the time and date of this presentation. If reviewed after the initial presentation, even if made available by Cisco or Splunk, on Cisco or Splunk’s website or otherwise, it may not contain current or accurate information. Cisco and Splunk undertake no obligation to revise or update any forward-looking statements for any reason, except as required by law. In addition, any information about new products, features, functionality or our roadmap outlines our general product direction and is subject to change at any time without notice. It is for informational purposes only and shall not be incorporated into any contract or other commitment or be relied upon in making a purchasing decision. We undertake no commitment, promise or obligation either to develop the features or functionalities described, in beta or in preview (used interchangeably), or to include any such feature or functionality in a future release. The development, release, and timing of any features or functionality described for our products remains at our sole discretion. Splunk, Splunk> and Turn Data Into Doing are trademarks and registered trademarks of Splunk LLC in the United States and other countries. All other brand names, product names or trademarks belong to their respective owners. © 2024 Splunk LLC. All rights reserved.
  2. © 2024 SPLUNK LLC Kazunori Otani Senior Solutions Architect, Observability

    @katzchang オブザーバビリティ・エンジニアリング共訳 @open-telemetry/docs-ja-approvers OpenTelemetry Meetup
  3. © 2024 SPLUNK LLC Kubernetes環 境のオブザーバ ビリティの次の一 歩を OpenTelemetry で実現すると何が

    どうなるの? 本セッションでは、KubernetesやPrometheusに詳しいプラットフォームエンジ ニア向けに、オブザーバビリティの次のステージを実現するための OpenTelemetry活用法を解説します。Kubernetes環境における実践例を通じ て、メトリクスやトレースの統合による運用効率向上と、リアルタイムな可視化の 価値を探ります。また、Splunk Observability製品との連携 によって得られる 効果的なモニタリングと課題解決のアプローチもご紹介します。 もくじ: 1. なぜOpenTelemetryなのか? 2. OpenTelemetryを使い始めるには 3. 集まったデータをどう利用するか: Splunk Observabilityの例 お持ち帰りいただくもの : • 既存のモニタリング環境をより良くするためのアイデアを学ぶ • 運用しているKubernetes環境にOpenTelemetryの導入を進めるための方 法を学ぶ • Splunk Observabilityという選択肢を持っていただく 本日の内容
  4. © 2024 SPLUNK LLC ある日のこと・・・ 1. 同時に複数のアラート がなりました 2. 何が起こっているか、最初の対策を知りたいが、同時にア

    ラートがなっているので、何を戻せばいいか、何を再起動す ればいいのかわからない 3. ログを調べよう!エラーログは見えるが、そのエラーがどう いう処理を起点に発生したかわからない 、そもそもこのエ ラーは通常時はどうなんだっけ... 4. 調べてるうちになんと現象が収まった 5. 再現待ち...(1に戻る) あなたはオンコール担当としてアラートに備えています
  5. © 2024 SPLUNK LLC 今までのシステムとそのモニタリング • 3層アーキテクチャー: ◦ プレゼンテーション、ウェブサーバー、アプリサーバー、RDB •

    ある程度の数の、同じ構成のVM • 監視のポイント : 数箇所 ◦ 計算機リソース: CPU, Memory, Network, Disk ◦ アプリケーション: ポートの死活監視, REDメトリクス ◦ RDB: 接続状況, クエリ処理 ◦ 何かあればログを調査
  6. © 2024 SPLUNK LLC 現代的なシステムとそのモニタリング • 複数のマイクロサービス, 複数のDB, 外部サービスへの依存 •

    コンテナ環境(Kubernetesのノードとポッド、コンテナ) • 監視のポイント : マイクロサービス x ポッドで増える ◦ 計算機リソース: CPU, Memory, Network, Disk ◦ アプリケーション: ポートの死活監視, REDメトリクス ◦ データベース: 接続状況, クエリ処理 ▪ 違うアーキテクチャーのDBが複数稼働 ◦ ログも増える
  7. © 2024 SPLUNK LLC どこで何が起こっているのか、よくわからない • ポッドは頻繁に入れ替わる(そうじゃないとマイクロサービス化の恩恵を受けていない) • とにかく色々頻繁に変更される(基盤、アプリケーション) •

    マイクロサービスは管理不可能になるまで増殖 する(パーキンソンの法則的な) 👉 現在の状態を把握することは困難 結果として: • 対策が取れないのでトラブルを繰り返す • システムやチームに対する信頼性を失う
  8. © 2024 SPLUNK LLC どう解決しますか? • メトリクスの計測を増やす : URLパス単位, クエリ単位,

    … ◦ カーディナリティが爆発する ◦ メトリクスの生成、転送、取り込み、可視化の負荷が増える ◦ どんなメトリクスを見るべきかわからない、そもそもどんなメ トリクスがあるかわからない ◦ 機械的な相関分析を導入したくなる ▪ 管理コストが増える ▪ 関連はわかるが、因果関係はわからない • ログの分析を増やす ◦ ログ量が増えて生成、転送、取り込み、可視化の負荷が増 える ◦ 前後関係がわからないので因果関係がわからない ◦ そのためにログを標準化 して「トランザクションID」のような ものを導入したくなるが、仕様の策定や実装の手間がかか る
  9. © 2024 SPLUNK LLC 従来のツールスタックの課題 • メトリクス中心 の監視: ◦ 因果関係がわからない

    ◦ カーディナリティの制御が難しい • ログ中心の監視: ◦ エラー発生時にログを一つひとつ確認するのは非効率 ◦ 分散トランザクションの途中で発生した問題の特定が困難
  10. © 2024 SPLUNK LLC なぜOpenTelemetryが必要とされたのか? • 標準化されたトレースによる分散システム全体の可視化 ◦ リクエストがどのサービスを通過し、どこで失敗したのかを明確化 ◦

    トランザクションIDのような独自実装を不要にする ◦ トレースは「標準化・構造化されたログである」 「トレース、メトリクス、ログ、プロファイリング、あらゆるテレメトリーのあらゆる 形態を相関させる」 https://www.amazon.co.jp/dp/4814401027 https://learning.oreilly.com/library/view/learning-opentelemetry/9781098147174/
  11. © 2024 SPLUNK LLC OpenTelemetry https://opentelemetry.io/ja/ • OpenTelemetry は API、SDK、

    ツールのコレクション です。 テレメト リーデータ(メトリクス、ログ、トレース) の計装、生成、収集、エクスポート に 使用し、ソフトウェアのパフォーマン スや動作の分析 に役立てましょう。 • CNCF (Cloud Native Computing Foundation) incubating project ◦ 「2番目に活発」
  12. © 2024 SPLUNK LLC インフラ環境(オンプレ /クラウド) オブザーバビリティのためのアーキテクチャ サーバー サーバー サーバー/VM

    コンテナ環境 コンテナ環境 コンテナ マネージドサービ ス マネージドサービ ス マネージド サービス テレメトリー転 送 パイプライン テレメトリー分析 バックエンド ① テレメトリーの作成(計装)と転送 ② 分析 トレース/メトリクス/ログ/プロファイルなど
  13. © 2024 SPLUNK LLC インフラ環境(オンプレ /クラウド) オブザーバビリティのためのアーキテクチャ サーバー サーバー サーバー/VM

    コンテナ環境 コンテナ環境 コンテナ マネージドサービ ス マネージドサービ ス マネージド サービス テレメトリー転 送 パイプライン テレメトリー分析 バックエンド ① テレメトリーの作成(計装)と転送 ② 分析 トレース/メトリクス/ログ/プロファイルなど
  14. © 2024 SPLUNK LLC 導入のステップ( 1つの例) 1. OpenTelemetry Collectorをインストールする 2.

    トレース: アプリケーションにSDKをセットアップする 3. メトリクス: Prometheusメトリクスをスクレイプする 4. ログ: アプリケーションログにトレースコンテキストを埋め込む
  15. © 2024 SPLUNK LLC OpenTelemetry Collectorをインストールする helm repo add splunk-otel-collector-chart

    \ https://signalfx.github.io/splunk-otel-collector-chart helm install my-splunk-otel-collector \ --set="splunkObservability.realm=us0,splunkObservability.accessToken=xxxxxx,clusterName=my-cluster" \ splunk-otel-collector-chart/splunk-otel-collector helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector \ --set image.repository="otel/opentelemetry-collector-k8s" \ --set mode=<daemonset|deployment|statefulset> \ Upstream Splunk Distro
  16. © 2024 SPLUNK LLC トレース: アプリケーションに SDKをセットアップする # Install the

    Splunk Java Agent ADD https://github.com/signalfx/splunk-o tel-java/releases/latest/download/sp lunk-otel-javaagent.jar /splunk-otel-javaagent.jar # Set appropriate permissions RUN chmod -R go+r /splunk-otel-javaagent.jar containers: - name: myapp env: - name: SPLUNK_OTEL_AGENT valueFrom: fieldRef: fieldPath: status.hostIP - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://$(SPLUNK_OTEL_AGENT):4318" - name: OTEL_SERVICE_NAME value: "dreamcast" - name: OTEL_RESOURCE_ATTRIBUTES value: "deployment.environment=cndw2024,service.version=2024" command: - java - -javaagent:/splunk-otel-javaagent.jar - -Dsplunk.profiler.enabled=true - -Dsplunk.profiler.memory.enabled=true - -jar - myapp.jar 1. Dockerfileに記 述を追加して... 2. deploymentに 記述を追加する
  17. © 2024 SPLUNK LLC メトリクス : Prometheusメトリクスをスクレイプする • PrometheusのメトリクスをOTel Collectorでそのまま取り込める

    • 既存のPrometheusダッシュボードやアラート設定を維持しつつ、トレー スやログの追加が可能 • Receiver Creator: prometheus.io アノテーション があるポッドや サービスを見つけて、Prometheus Receiverを作る 実はもう出来ています
  18. © 2024 SPLUNK LLC Prometheus Receiver, Receiver Creatorは何をしているか? receiver_creator: watch_observers:

    [k8s_observer] receivers: prometheus_simple: # Enable prometheus scraping for pods with standard prometheus annotations rule: type == "pod" && annotations["prometheus.io/scrape"] == "true" config: metrics_path: '`"prometheus.io/path" in annotations ? annotations["prometheus.io/path"] : "/metrics"`' endpoint: '`endpoint`:`"prometheus.io/port" in annotations ? annotations["prometheus.io/port"] : 9090`' https://github.com/signalfx/splunk-otel-collector-chart/blob/main/helm-charts/splunk-otel-collector/templates/config/_otel-agent.tpl 条件に合致するときに、 Collectorのレシーバーの コンポーネントインスタンスを作る prometheus.io/scrapeアノテーションがある ポッドを対象する
  19. © 2024 SPLUNK LLC ログ: アプリケーションログにトレースコンテキストを埋め込む 実はもう出来ているかも <?xml version="1.0" encoding="UTF-8"?>

    <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss} - %logger{36} - %msg trace_id=%X{trace_id} span_id=%X{span_id} service=%X{service.name}, env=%X{deployment.environment} trace_flags=%X{trace_flags} %n</pattern> </encoder> </appender> <root level="info"> <appender-ref ref="STDOUT" /> </root> </configuration> LogBackの例
  20. © 2024 SPLUNK LLC OpenTelemetryによるテレメトリーデータの統合と最適化 • リソース属性の標準化: ◦ Kubernetesのポッド名、ノード名、クラスタ名を簡単に追跡 する

    • トレース・メトリクス・ログの関連付け: ◦ メトリクスで検知し、トレースで原因を特定 、ログでさらに調査 する • テレメトリーデータの利用を最適化することで、コストを制御 する ◦ さらに: サンプリングやフィルタリングを活用したデータ量をコントロール
  21. © 2024 SPLUNK LLC Splunk Observability APM アプリケーション監視 RUM 実ユーザのUX監視

    Splunk Cloud/Enterprise Log Observer Connect ログ監視・調査 Infrastructure Monitoring インフラ監視 Synthetic Monitoring 外形監視/合成監視 フロントエンドからバックエンドまで、 インシデントの検知から解消まで、 問題解決を End to End で支援
  22. © 2024 SPLUNK LLC Kubernetes環 境のオブザーバ ビリティの次の一 歩を OpenTelemetry で実現すると何が

    どうなるの? 本セッションでは、KubernetesやPrometheusに詳しいプラットフォームエンジ ニア向けに、オブザーバビリティの次のステージを実現するための OpenTelemetry活用法を解説します。Kubernetes環境における実践例を通じ て、メトリクスやトレースの統合による運用効率向上と、リアルタイムな可視化の 価値を探ります。また、Splunk Observability製品との連携 によって得られる 効果的なモニタリングと課題解決のアプローチもご紹介します。 もくじ: 1. なぜOpenTelemetryなのか? 2. OpenTelemetryを使い始めるには 3. 集まったデータをどう利用するか: Splunk Observabilityの例 お持ち帰りいただくもの : • 既存のモニタリング環境をより良くするためのアイデアを学ぶ • 運用しているKubernetes環境にOpenTelemetryの導入を進めるための方 法を学ぶ • Splunk Observabilityという選択肢を持っていただく 本日の内容
  23. © 2024 SPLUNK LLC まとめ 1. なぜOpenTelemetryなのか? 👉 トレースの必要性 👉

    テレメトリーデータ統合の必要性 2. OpenTelemetryを使い始めるには 👉 OpenTelemetry Collectorを便利につかう 👉 トレースを導入しつつ、既存のメトリクスやログの変更を最小限にしながら統合する 3. 集まったデータをどう利用するか : Splunk Observabilityの例 👉 テレメトリーデータを統合して分析できる 👉 リアルタイム性 👉 利用状況の把握と管理
  24. © 2024 SPLUNK LLC 次のステップ 1. チームへの浸透 : ツールはそこにあるだけでは使われない 👉

    勉強会 👉 訓練 👉 負荷試験などで使う 2. カスタム計装の追加 👉 カスタム属性、カスタムスパン、事業に応じたカスタムメトリクス 3. 領域の拡大 👉 フロントエンドモニタリング(RUM) 👉 レガシー環境との統合(ログ主体のモニタリング)