Logs are better with elastic apm 20210623

257 Views

June 23, 21

スライド概要

Elastic APM のログ活用法https://www.elastic.co/jp/webinars/learn-more-from-your-logs-with-elastic-apm

profile-image

FPT ジャパン FPT データ& AI インテグレーション エグゼクティブエバンジェリスト 独立行政法人 国立印刷局 デジタル統括アドバイザー兼最高情報セキュリティアドバイザー AI 駆動開発勉強会主催。Microsoft エバンジェリスト時代から、Dell、Accenture、Elastic、VMware を経て現職まで一貫して開発者向けに最新技術を啓発。GPU クラウド技術訴求、AI 駆動開発推進。  政府の仕事は、内閣官房 政府 CIO 補佐官、 デジタル庁 PM を経て、現職を兼務。 Locofy.ai Regional Developer Advocate Google Cloud Partner All Certifications Engineer 2025

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

(ダウンロード不可)

関連スライド

各ページのテキスト
1.

Elastic APM のログ活⽤法 鈴⽊ 章太郎 Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト 内閣官房 IT 総合戦略室 政府 CIO 補佐官

2.

⾃⼰紹介 鈴⽊ 章太郎 Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト 内閣官房 IT 総合戦略室 政府 CIO 補佐官 2003年マイクロソフト⼊社。公共営業部⾨の担当アーキテクトとして .NET の技術啓発活動に従事。 2006年開発者向けマーケティング部⾨に異動、テクニカルエバンジェリスト として Windows/iOS/Android や Microsoft Azure の開発者向け 技術啓発活動を10年にわたり担当。 ⽇本マイクロソフト退社後は、Dell、Accenture 等を経て、2020年6⽉ からは Elastic で開発者向け技術啓発活動に携わる。 2019年4⽉〜 内閣官房 IT 総合戦略室 政府 CIO 補佐官。

3.

3 Solutions, 1 Stack, Deploy Anywhere 3 つのソリューション Elastic エンタープライズサーチ Elastic オブザーバビリティ Elastic セキュリティ 可視化 & 管理 Kibana Elastic スタックで実現 Beats 豊富なデプロイ選択肢 蓄積、検索、分析 Elasticsearch Logstash Elastic Cloud Elastic Cloud Enterprise SaaS (AWS/Azure/GCP) IaaS (クラウド & オンプレ) Elastic Cloud on Kubernetes Kubernetes (クラウド & オンプレ) 収集

4.

メトリックとログ ログはイベントの時系列レコード 64.242.88.10 - - [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 64.242.88.10 - - [07/Jan/2019:16:11:58 -0800] "POST /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 404 7352 64.242.88.10 - - [07/Jan/2019:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 イベントごとに、何が起こったかを表⽰

5.

メトリックとログ ログはイベントの時系列レコード 64.242.88.10 - - [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291 64.242.88.10 - - [07/Jan/2019:16:11:58 -0800] "POST /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 404 7352 64.242.88.10 - - [07/Jan/2019:16:20:55 -0800] "GET /twiki/bin/view/Main/DCCAndPostFix HTTP/1.1" 200 5253 イベントごとに、何が起こったかを表⽰ メトリックは数値 KPI の定期的な測定 07/Jan/2019 16:10:00 07/Jan/2019 16:20:00 07/Jan/2019 16:30:00 all all all 2.58 2.56 2.64 0.00 0.00 0.00 0.70 0.69 0.65 1.12 1.05 1.15 x 分ごとに CPU 負荷を測定し、それを印刷し、メタデータでアノテート 0.05 0.04 0.05 95.55 95.66 95.50 server1 server2 server2 containerX containerY containerZ regionA regionB regionC

6.

なぜ APM? 例: 応答の遅い時間またはロード時間 03:43:45 Request "GET cyclops.ESProductDetailView" 03:43:57 Response "cyclops.ESProductDetailView 200 OK" 12 seconds - zZzzZZz

7.

なぜ APM? 例: エラーと例外 03:43:59 Request "POST /api/checkout" 03:43:59 Response "/api/checkout 500 ERROR"

11.

Application Performance Monitoring (APM) • • • • • ログ、APM、インフラメトリックは監視の3⼤要素 3つの領域には重なり合う部分もあり、相互に関連付 ける際に役⽴つ ログは、エラーが⽣じた痕跡を⽰すが、エラーの理由ま では⽰さない メトリックはサーバー上で CPU 使⽤量にスパイクが あったことを⽰すかもしれないが、何が原因だったかは ⽰さない ただし、うまく組み合わせて活⽤すれば、はるかに広い 範囲の問題を解決できる可能性がある

12.

ログ • ログとメトリックには、わずかな違い • 通常、ログは何かが⽣じたときに発信されるイベント • あるリクエストが受信された、反応があった、ファイルを開いた、コードで printf が発⽣... etc. • ログの情報は、アプリケーションの全体を把握するというより、コンポーネン トレベルにとどまる • しかし⼈間が読む上では便利 • ログは通常、対応するアプリケーションやサービスが実⾏されているホスト /マシン/コンテナーインスタンス上で使⽤でき、この例のように⼈間が読め る情報であるため"便利" • ⼀⽅でログには「コードを書いておかなければ、プリントされない」という 本質的なデメリットも • Ruby で puts、Java で system.out.println、あるいは類似の作 業が必須 • またプリントする場合も、フォーマットが重要 たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるロ グ形式はこんな感じ(フェイクデータ、短縮のため⼀部省略)。 264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "GET /ESProductDetailView HTTP/1.1" 200 6291 264.242.88.10 - - [22/Jan/2018:07:08:53 -0800] "POST /intro.m4v HTTP/1.1" 404 7352 264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253 この例では、IPアドレスと、明らかに設定のないフィールド、⽇付、 ユーザーがアクセスしていたページ(とその⽅法)、いくつかの数字 を確認できる 経験から、⼀連の数字がレスポンスコード(200はよい、404は 良くないが、500よりはマシ)等や、データが返された量であること がわかる

13.

インフラメトリック • メトリックは周期的なサマリーやカウントの情報が主 • たとえば右はローカルマシン mac の iostat の例 • この10秒間に、平均 CPU は12% • アプリケーションが使⽤したメモリ量は 27 MB • プライマリディスクの容量は 71% • といったこと(多くのメトリックの存在)がわかる • 傾向や履歴を⽰したいときに便利 • シンプルで予測可能、また信頼できるルールを作成してインシデントや 異常を捉える場合に特に役⽴つ • ⼀⽅、メトリックのデメリットとして • インフラレイヤーの監視、コンポーネントインスタンスレベル(ホスト、コ ンテナー、ネットワークなど)のデータ捕捉が中⼼ • カスタムアプリケーションレベルのデータをあまり扱わない • メトリックは⼀定の経過時間に対してサンプルされるため、わずかな外れ 値が"平均化"されるリスクを伴うため

14.

APM (アプリケーションパフォーマンス監視) • メトリックとログのギャップに橋を架ける存在 • ログやメトリックは、インフラや複数のコンポーネントを扱う横断的なデータ • • APM は特にアプリケーションに注⽬し、エンドユーザーエクスペリエンスを含むスタック中の アプリ層を、IT 部⾨や開発者が監視できるようサポート 監視に APM を追加するメリットとして、次のような点 • サービス提供にかかる時間と、クラッシュの原因を把握できる • サービスと他の要素の通信状況や、ボトルネックを可視化できる • パフォーマンスのボトルネックやエラーの予防的な発⾒・修正に役⽴つ • 最良のシナリオは、多数のエンドユーザーが影響を受ける前の発⾒・修正 • 開発チームの⽣産性向上をサポート • ブラウザー上でエンドユーザーエクスペリエンスを追跡可能

15.

ログと APM とで得られる情報を⽐較 264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253 APMが捉えた内容︓最終発⽣⽇時、 発⽣頻度、アプリケーションで処理 されたか否か、という情報が表⽰ たとえば NumberParseException を 使って例外処理の詳細を⾒ると、エ ラーが発⽣した回数の分布がウイン ドウで視覚的に表⽰される ⼀定の時間に数回起きているということ、 ⼀⽇中発⽣していることがわかる ログで⾒ても、ログファイルの1つに対応す るスタックの痕跡が⾒つかるはず しかし APM のようにそのコンテクストや メタデータまで⾒つかる可能性は⾼くない ⾚い部分はこの例外処理を実施した コード⾏ APMが提供するメタデータが問題の正 確な内容 プログラマーでない⼈間が⾒ても問題 が正確に理解でき、チケットをオープ ンのために必要⼗分な情報がある

16.

Elastic APM APM は Elastic Stack に エンドユーザー体験と アプリケーションレベルの監視を追加 • APM データの上での検索体験を重視 • Elastic Stack の「もう⼀つのインデックス」 対応言語 ● Python ● Java ● Node.js ● Go ● Ruby ● .NET ● RUM ● PHP

17.

Elastic APM の概要

18.

Application Performance Monitoring (APM) • • ブラウザーでのエンド ユーザー エクスペリエンス • JavaScript エージェントを使⽤してエンド・ユーザーの • パフォーマンスをモニターする エラーログ • • ログとメトリックとの相関 • • コードによってスローされたエラーとスタック トレースをキャプチャする ログデータとメトリックデータ間でデータを⾃動的に関連付ける 根本原因分析 • ドリルダウンしながら探る

19.

Elastic Application Performance Monitoring • マルチページアプリ、シングルページアプリの双⽅で有効 • Node.js、Python、Ruby、.NET、 Java、Go Real User Monitoring(JavaScript)をサポート • 対応⾔語のさらなる追加も予定 • • • • Elasticがサポートする⾔語はこちら Jaeger や OpenTelemetry 等各種のオープンスタンダードもサポート インストルメンテーション済みのアプリから Elastic APM へ驚くほど簡単にデータを 送れる 必要なモジュールが⾒つからなくても、独⾃に開発することも、オープンソース コミュニティの成果物を活⽤することも可能

20.

⼀カ所での全般的 Observability(可観測性) エンドユーザーの体験とアプリケーション レベルの監視をスタックに追加 RUM

21.

例︓Elastic APM for Python コードの変更は不要 - - Python 2.7, 3.5, 3.6, 3.7, 3.8, 3.9 Frameworks Django, Flask, Aiohttp server, Tornado, Starlette/FastAPI Modules Elasticsearch, SQLite, MySQL db, mysql-connector, Cassandra, etc … より多くのモジュール登場予定!

22.

Logs Metrics APM

23.

サイロ化されたツールのコレクションの状態 開発 チーム Ops: モニタリング チーム Ops: モニタリング チーム Ops: ログ チーム APM ツール 稼働時間ツール メトリックツール ログツール リアルユーザーモニタリング Txn の監視 分散トレース アップタイム 応答時間 コンテナのメトリック ホストメトリック データベースメトリック ネットワークメトリック ストレージメトリック Web ログ アプリログ データベースログ コンテナログ

24.

ソフトウェアの開発⽅法とデリバリは常に進化 CI / CD サーバレス コンテナ オーケストレーション マイクロサービス クラウド

25.

65 10 % の組織は 種類以上の 監視ツールを使⽤

27.

統合 Observability ツールとしての Elastic Dev & Ops チーム APM データ 稼働時間データ メトリックデータ ログ データ リアルユーザーモニタリング Txn の監視 分散トレース アップタイム 応答時間 コンテナのメトリック コンポーネントメトリック ホストおよびネットワークのメトリック データベースとストレージのメトリック Web ログ アプリ ログ / データベース ログ コンテナログ PaaS コンポーネント ログ Kibana Elasticsearch

28.

Elastic オブザーバビリティ 単⼀のオープンプラットフォームによる完全な可視性を ⼿頃な価格で提供し、 MTTR (データ・分析結果を得るまでの平均時間) をゼロに近づけます。

29.

監視データ間の相関 Elastic Common Schema 利点 • • • 異なるソースからのデータを相関する 分析コンテンツを再利⽤する機能 弾性によって提供されるコンテンツを再利⽤する機能 地位 • • GA および公開 : github.com/elastic /ecs コミュニティのフィードバックは歓迎

30.

統合ダッシュボード KPI 概要と根本原因分析に同じ UI の利⽤

31.

統合アラート 運⽤データをトリガーして、統⼀された SLA 監視を提供

32.

統合された機械学習 (Machine Learning) 複数のデータソースを関連付けて、よりインテリジェントな異常検出を実現

33.

トレース、ログ、メトリック間のより緊密な統合

34.

Demo

36.

最新の デジタルエクスペリエンス を提供するためには Observability が重要 Modern Architecture は複雑 Elastic Observability には、これらの複雑なシステムを 1つのプラットフォームで観察可能にするために必要なものが すべて揃う 「Hipsterオンラインストアアプリは、クラウドネイティブのテ クノロジーアーキテクチャ上に構築されています。 Go、 C#、Java、.js ノード、Pythonなど、さまざまなプログラ ミング⾔語で構築された10層マイクロサービスアーキテク チャを使⽤します。メモリ内データキャッシュに Redis を使 ⽤しています。これらのすべては、Google クラウド プラッ トフォーム (GCP) で実⾏されている Kubernetes ベー スのコンテナープラットフォームで実⾏されています。

37.

APM トレースへのログデータの追加

38.

ログとトレース Response HTTP request Transaction 1 Span Span Span [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" [07/Jan/2019:16:11:58 -0800] "Update database XYZ" [07/Jan/2019:16:20:55 -0800] "Transaction updated successfully" 38

39.

ログとトレース - ラベルを使⽤した範囲のアノテーション Response HTTP request Transaction 1 Span Span Span [07/Jan/2019:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" [07/Jan/2019:16:11:58 -0800] "Update database XYZ" [07/Jan/2019:16:20:55 -0800] "Transaction updated successfully" 39

40.

APM ラベル ラベルは Elasticsearch でインデックス付けされるため検索可能で集計可能 Span span = ElasticApm.currentSpan(); span.setLabel("customer", "J.C.Penny"); span.setLabel("order_id", "XDD669023"); span.setLabel("quantity", 12); span.setLabel("amount", 999.01); span.setLabel("currency", "AUD");

41.

APM アノテーション

42.
[beta]
APM アノテーション
これらの特別な瞬間のために:リリースバージョン、アップデート、イベント
curl -X POST ¥
http://localhost:5601/api/apm/services/opbeans-java/annotation ¥
-H 'Content-Type: application/json' ¥
-H 'kbn-xsrf: true' ¥
-H 'Authorization: Basic YhUlubWZhM0FDbnlQeE6WRtaW49FQmSGZ4RUWXdX' ¥

-d '{
"@timestamp": "2020-05-08T10:31:30.452Z",
"service": {
"version": "1.2"
},
"message": "Deployment 1.2"
}'

43.

And More!

44.

機械学習 (Machine Learning) データの異常や外れ値を⾒つけたり、傾向に基づいて予測 • ボタンをクリックするだけのシンプルな操作で、Elasticsearch のデータから 新しいインサイト を抽出 • 限りなく運⽤性にすぐれた 機械学習 • Elasticsearch と Kibana で直接、簡単に使えるよう設計 簡単にメタデータを補⾜ 異常と外れ値を、瞬時に検出 教師あり機械学習を⼿軽に運⽤

45.

機械学習 (Machine Learning) APM からの機械学習とのワンクリック統合 • APM から応答時間ベースの ML ジョブを作成する機能 ‒ ‒ 異常を計算するためのプロファイル 応答時間 シーズナリティを考慮する

46.

分散トレーシング 複数サービス間でのトレースとマッピング • エンドツーエンドの表⽰を確認し個々の トランザクションに移動 • サービス間のエンドツーエンドのトレース ID の概念に依拠 • Open Tracing API との互換性 • W3C トレースコンテキスト仕様との整 合性

47.

分散トレース OpenTelemetry, OpenTracing, Jaeger…オープンスタンダードのサポート

48.

統⼀された Observability トレース データをコンテキスト内のログおよびメトリック データに関連付ける

49.

コンテキスト対応リアルタイム検索 データストリームを迅速に結び付けて回答を得る

50.

同じレスポンス、 異なるエクスペリエンス ブラウザでの動作 • 要求がエンドユーザーのデバイスに到達すると どうなるか︖ • ユーザーエクスペリエンスがビジネス成果に 与える影は︖ • サードパーティ製の Java スクリプトは︖ • 稼働していますか? 機能していますか?

51.

柔軟なデプロイメントオプション オンプレミス、クラウド、クラウド ネイティブ、マルチクラウド セルフ マネージド Elastic Cloud 単⼀のパッケージを インストールする AWS、Azure、 または Google Cloud に 即座にデプロイ Elastic Cloud Enterprise Elastic Cloud on Kubernetes インフラ上で 複数のデプロイメントを ⼀元管理

52.

柔軟な Agent のデプロイメント • 7 つの異なる⾔語⽤のネイティブ ライブラリ ‒ • フルスタック技術(フロントエンドからバック エンド)を含むさまざまなエコシステムに わたる広範な計測サポート OpenTracing, Jaeger, OpenTelemetry のサポート

53.

DevOps コラボレーション パフォーマンスの問題をデプロイメントに結び付ける • • • コード配置を使⽤してアプリケーションの パフォーマンスを追跡する すべての APM チャートのアノテーション により、 パフォーマンスの変化を迅速に ⾒つけ出し、 新しいデプロイを⾏う バージョンを除外する検索

54.

ITSM コラボレーション 既存のインシデント管理プロセスへの統合

55.

7.13 アップデート APM 最初のスタートにおける改善 • Cloud Instrumentation – – – • エージェント固有の機能強化 – – – – – • Go、Ruby、および Python Agent は、AWS DynamoDB、S3、SNS、および SQS のサポート追加 .NET Agent は、Azure ストレージ、キュー、およびサービスバスのサポートを追加 .NET、Go、Ruby の Agent は Azure App Service のサポートを改善、追加のメタデータを収集 Java: Cassandra 実装 .NET: MongoDB 実装 Node.js: パフォーマンス改善 PHP: support for PHP 8、中央構成のサポート .NET and Node.js:スパン・バイ・タイプと依存関係の内訳 (フィーチャー・パリティ) エージェントのゼロコンフィギュレーション (Fleet との将来の統合)

56.

7.13 アップデート 例: Azure バックエンドを呼び出す .NET サービス

57.

7.13 アップデート Fleet Server の概要 • • • • Fleet Server は新しいスタックインフラストラクチャコンポーネント Elastic Agent を⼀元的に⼤規模に管理 Kibana の⼀部だった以前よりもスケーラブル セグメント化されたネットワークのサポートを強化し、より安全に Standard/Basic Enterprise Platinum Gold OSS Beta GA

58.

7.13 アップデート APM と Fleet への アップグレード どのように役⽴つか ➔ ユーザーは Fleet をすぐに使い始めることができ、 Elastic へのデータの取り込みが容易に ➔ デフォルトで提供され、新しい Elastic Cloud デプロイメントにおいて無料で提供 技術的詳細 ● Fleet Server を既存 APM インスタンスに追加 ● Fleet を通じて APM を管理することが可能に Standard/Basic Enterprise Platinum Gold OSS Beta GA

59.

Google Cloud Day:Digital ʻ21 → d2-gl-27 「クラウド ネイティブへの移⾏における Elastic APM の概要」 https://cloudonair.withgoogle.com/events/google-cloud-day-digital-21?talk=d2-gl-27

60.

Elastic APM のログ活⽤法 https://www.elastic.co/jp/webinars/learn-more-from-your-logs-with-elastic-apm

61.

Elastic 7.13 Update ダイジェスト版(6/24) 今回のWebinarの詳細は以下の通りです。 ========================== ===================== ■開催⽇時 6/24(⽊)19:30〜21:00 ■内容 登壇 1. ⽇本マイクロソフト 惣道 哲也さん 2. Elastic 鈴⽊章太郎さん 3. 募集中 ========================== ===================== 以上 https://www.meetup.com/ja-JP/Tokyo-Elastic-Fantastics/events/278466633/

62.

Elastic on Microsoft Azure: インテグレーション強化による価値の創出 https://www.elastic.co/jp/webinars/elastic-on-microsoft-azure-accelerate-time-to-value-with-enhanced-integration

63.

Elastic x LAC Web セミナー セキュリティー DX : 効果的な基盤構築と運⽤法 https://www.elastic.co/jp/webinars/effective-infrastructure-construction-and-operation-methods

64.

Microsoft Open Tech Night #14 Dapr 勉強会(7⽉14⽇) https://msdevjp.connpass.com/event/215108/

65.

ElasticON Solution Series Japan (7⽉毎週) https://www.elastic.co/elasticon/solution-series/asia-pacific-jp

66.

Thank you for your attention!