Apm enables python app observability
1 like•169 views
https://www.elastic.co/jp/webinars/instrument-and-monitor-a-python-application-using-apm
![ログ
• ログとメトリックには、わずかな違い
• 通常、ログは何かが⽣じたときに発信されるイベント
• あるリクエストが受信された、反応があった、ファイルを開いた、コードで
printf が発⽣... etc.
• ログの情報は、アプリケーションの全体を把握するというより、コンポーネン
トレベルにとどまる
• しかし⼈間が読む上では便利
• ログは通常、対応するアプリケーションやサービスが実⾏されているホスト
/マシン/コンテナーインスタンス上で使⽤でき、この例のように⼈間が読め
る情報であるため"便利"
• ⼀⽅でログには「コードを書いておかなければ、プリントされない」という
本質的なデメリットも
• Ruby で puts、Java で system.out.println、あるいは類似の作
業が必須
• またプリントする場合も、フォーマットが重要
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
たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるロ
グ形式はこんな感じ（フェイクデータ、短縮のため⼀部省略）。
この例では、IPアドレスと、明らかに設定のないフィールド、⽇付、
ユーザーがアクセスしていたページ（とその⽅法）、いくつかの数字
を確認できる
経験から、⼀連の数字がレスポンスコード（200はよい、404は
良くないが、500よりはマシ）等や、データが返された量であること
がわかる](https://image.slidesharecdn.com/apmenablespythonappobservability-201218075452/85/Apm-enables-python-app-observability-25-320.jpg)
![ログと APM とで得られる情報を⽐較
264.242.88.10 - - [22/Jan/2018:16:38:53 -0800]
"POST /checkout/addresses/ HTTP/1.1" 500 5253
⼀定の時間に数回起きているということ、
⼀⽇中発⽣していることがわかる
ログで⾒ても、ログファイルの1つに対応す
るスタックの痕跡が⾒つかるはず
しかし APM のようにそのコンテクストや
メタデータまで⾒つかる可能性は⾼くない
APMが捉えた内容︓最終発⽣⽇時、
発⽣頻度、アプリケーションで処理
されたか否か、という情報が表⽰
たとえば NumberParseException を
使って例外処理の詳細を⾒ると、エ
ラーが発⽣した回数の分布がウイン
ドウで視覚的に表⽰される
⾚い部分はこの例外処理を実施した
コード⾏
APMが提供するメタデータが問題の正
確な内容
プログラマーでない⼈間が⾒ても問題
が正確に理解でき、チケットをオープ
ンのために必要⼗分な情報がある](https://image.slidesharecdn.com/apmenablespythonappobservability-201218075452/85/Apm-enables-python-app-observability-28-320.jpg)
Apm enables python app observability
- 1. APM による Python アプリケーションの 計測と可視化 Date: November 11, 2020 鈴⽊ 章太郎 Elastic テクニカルプロダクトマーケティングマネージャー/エバンジェリスト 内閣官房 IT 総合戦略室 政府 CIO 補佐官
- 2. Elastic Technical Product Marketing Manager/Evangelist 内閣官房 IT 総合戦略室 政府 CIO 補佐官 元 Microsoft Technical Evangelist Twitter : @shosuz Shotaro Suzuki
- 3. Elastic is a search company. Scale RelevanceSpeed
- 5. 3 Solutions, 1 Stack, Deploy Anywhere Elastic スタックで実現 Kibana Elasticsearch Beats Logstash Elastic エンタープライズサーチ Elastic セキュリティElastic オブザーバビリティ 3 つのソリューション SaaS (AWS/Azure/GCP) IaaS (クラウド & オンプレ） Elastic Cloud on Kubernetes Elastic Cloud Elastic Cloud Enterprise 豊富なデプロイ選択肢 Kubernetes (クラウド & オンプレ）
- 6. Elastic Cloud on Azure デプロイ https://www.elastic.co/jp/
- 7. Elastic Cloud on Azure デプロイ https://portal.azure.com https://www.elastic.co/jp/blog/getting-started-with-elastic-cloud-on-microsoft-azure
- 8. Elastic Cloud on GCP デプロイ https://console.cloud.google.com/ https://www.elastic.co/jp/blog/getting-started-with-elastic-cloud-on-google-cloud
- 10. Elastic Cloud デプロイ https://www.elastic.co/jp/
- 11. Elastic Cloud on Azure https://www.elastic.co/jp/
- 13. マイクロサービスコンテナCI / CD オーケストレーションサーバレス クラウド ソフトウェアの開発⽅法とデリバリは常に進化
- 17. 開発チーム 運⽤: ログ監視 可動性 応答時間 アップタイム ツール 運⽤︓ インフラ監視 ウェブログ アプリログ データベースログ コンテナログ ログツール リアルユーザー監視 トランザクション パフォーマンス監視 分散トレーシング APM ツール 運⽤︓ サービス監視 コンテナ指標 ホスト指標 データベース指標 ネットワーク指標 ストレージ指標 メトリック ツール ビジネス KPI ビジネスツール ビジネス チーム 現状 ー 典型的なオブザーバビリティのツール群
- 18. 開発、運⽤、ビジネスチーム Elastic のオブザーバビリティへのアプローチ APM データ アップタイム データ 指標データログデータ ビジネス データ 全ての運⽤にまつわるデータを、⼀つの強⼒なデータストアに集約 - Elasticsearch
- 19. 統合された機械学習 統合されたアラート 単⼀の価格モデル 1つのツールのみを学習・セキュリティ 対策・維持… よりスマートなルールでアラート疲れを軽減 スマート検出で問題を早期発⾒ 単⼀の強⼒なデータストア - Elasticsearch 統合されたダッシュボード 分析における複数システム間のやり取りを排除 ⽀出の簡素化と管理 業務の効率化 縦割りを無くし各レイヤで統合 APM アップ タイム メトリックログ ビジネス 統合されたスキーマ ソース間の相関関係を利⽤して分析⾼速化
- 21. 可観測性は単にログやメトリックやトレースではない • オープンで拡張可能なコード ⾃作か購⼊を待つかという選択に制限されない • 開放的で活気あるコミュニティ コミュニティで⼒を増幅し、素早く先に進む • オープンで柔軟なデータストア ログ、メトリック、トレースのみならず可視性向上の為あらゆるデータを追加可能 • 強⼒で多様な機能拡張 より広範な Elastic エコシステム（Canvas、Lens、Map、SIEM 等） 開発者の創造性を解放し可能性を再想像
- 22. 可観測性を損なうことなく⽀出を管理可能 シンプルに統⼀されたリソースベースの価格設定 直感的、統⼀、透明性 • 価値のあるデータ分だけの⽀払。追加費⽤なし、差し⽌めなし 事業価値との整合性 • 全データを読み込み、全てのアプリを監視でき、可視性を犠牲にしない コスト集約 • 単⼀プラットフォーム、単⼀価格 モダンアーキテクチャー対応 • コンテナ毎、メトリック毎、機能毎などの価格設定はない ホスト当たり 費⽤ モニター当たり 費⽤ 読込当たり 費⽤ エージェント 当たり費⽤
- 23. APM
- 24. Application Performance Monitoring (APM) • ログ、APM、インフラメトリックは監視の3⼤要素 • 3つの領域には重なり合う部分もあり、相互に関連付 ける際に役⽴つ • ログは、エラーが⽣じた痕跡を⽰すが、エラーの理由ま では⽰さない • メトリックはサーバー上で CPU 使⽤量にスパイクが あったことを⽰すかもしれないが、何が原因だったかは ⽰さない • ただし、うまく組み合わせて活⽤すれば、はるかに広い 範囲の問題を解決できる可能性がある
- 25. ログ • ログとメトリックには、わずかな違い • 通常、ログは何かが⽣じたときに発信されるイベント • あるリクエストが受信された、反応があった、ファイルを開いた、コードで printf が発⽣... etc. • ログの情報は、アプリケーションの全体を把握するというより、コンポーネン トレベルにとどまる • しかし⼈間が読む上では便利 • ログは通常、対応するアプリケーションやサービスが実⾏されているホスト /マシン/コンテナーインスタンス上で使⽤でき、この例のように⼈間が読め る情報であるため"便利" • ⼀⽅でログには「コードを書いておかなければ、プリントされない」という 本質的なデメリットも • Ruby で puts、Java で system.out.println、あるいは類似の作 業が必須 • またプリントする場合も、フォーマットが重要 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 たとえば、Apache HTTPサーバーのプロジェクトからくるよくあるロ グ形式はこんな感じ（フェイクデータ、短縮のため⼀部省略）。 この例では、IPアドレスと、明らかに設定のないフィールド、⽇付、 ユーザーがアクセスしていたページ（とその⽅法）、いくつかの数字 を確認できる 経験から、⼀連の数字がレスポンスコード（200はよい、404は 良くないが、500よりはマシ）等や、データが返された量であること がわかる
- 26. インフラメトリック • メトリックは周期的なサマリーやカウントの情報が主 • たとえば右はローカルマシン mac の iostat の例 • この10秒間に、平均 CPU は12％ • アプリケーションが使⽤したメモリ量は 27 MB • プライマリディスクの容量は 71％ • といったこと（多くのメトリックの存在）がわかる • 傾向や履歴を⽰したいときに便利 • シンプルで予測可能、また信頼できるルールを作成してインシデントや 異常を捉える場合に特に役⽴つ • ⼀⽅、メトリックのデメリットとして • インフラレイヤーの監視、コンポーネントインスタンスレベル（ホスト、コ ンテナー、ネットワークなど）のデータ捕捉が中⼼ • カスタムアプリケーションレベルのデータをあまり扱わない • メトリックは⼀定の経過時間に対してサンプルされるため、わずかな外れ 値が"平均化"されるリスクを伴うため
- 27. APM (アプリケーションパフォーマンス監視) • メトリックとログのギャップに橋を架ける存在 • ログやメトリックは、インフラや複数のコンポーネントを扱う横断的なデータ • APM は特にアプリケーションに注⽬し、エンドユーザーエクスペリエンスを含むスタック中の アプリ層を、IT 部⾨や開発者が監視できるようサポート • 監視に APM を追加するメリットとして、次のような点 • サービス提供にかかる時間と、クラッシュの原因を把握できる • サービスと他の要素の通信状況や、ボトルネックを可視化できる • パフォーマンスのボトルネックやエラーの予防的な発⾒・修正に役⽴つ • 最良のシナリオは、多数のエンドユーザーが影響を受ける前の発⾒・修正 • 開発チームの⽣産性向上をサポート • ブラウザー上でエンドユーザーエクスペリエンスを追跡可能
- 28. ログと APM とで得られる情報を⽐較 264.242.88.10 - - [22/Jan/2018:16:38:53 -0800] "POST /checkout/addresses/ HTTP/1.1" 500 5253 ⼀定の時間に数回起きているということ、 ⼀⽇中発⽣していることがわかる ログで⾒ても、ログファイルの1つに対応す るスタックの痕跡が⾒つかるはず しかし APM のようにそのコンテクストや メタデータまで⾒つかる可能性は⾼くない APMが捉えた内容︓最終発⽣⽇時、 発⽣頻度、アプリケーションで処理 されたか否か、という情報が表⽰ たとえば NumberParseException を 使って例外処理の詳細を⾒ると、エ ラーが発⽣した回数の分布がウイン ドウで視覚的に表⽰される ⾚い部分はこの例外処理を実施した コード⾏ APMが提供するメタデータが問題の正 確な内容 プログラマーでない⼈間が⾒ても問題 が正確に理解でき、チケットをオープ ンのために必要⼗分な情報がある
- 29. Elastic Application Performance Monitoring • マルチページアプリ、シングルページアプリの双⽅で有効 • Node.js、Python、Ruby、.NET、 Java、Go Real User Monitoring（JavaScript）をサポート • 対応⾔語のさらなる追加も予定 • Elasticがサポートする⾔語はこちら • Jaeger や OpenTelemetry 等各種のオープンスタンダードもサポート • インストルメンテーション済みのアプリから Elastic APM へ驚くほど簡単にデータを 送れる • 必要なモジュールが⾒つからなくても、独⾃に開発することも、オープンソース コミュニティの成果物を活⽤することも可能
- 30. Application Performance Monitoring (APM) • ブラウザーでのエンド ユーザー エクスペリエンス • JavaScript エージェントを使⽤してエンド・ユーザーの • パフォーマンスをモニターする • エラーログ • コードによってスローされたエラーとスタック トレースをキャプチャする • ログとメトリックとの相関 • ログデータとメトリックデータ間でデータを⾃動的に関連付ける • 根本原因分析 • ドリルダウンしながら探る
- 31. Elastic APM の概要
- 32. Machine learning APM から ML とのワンクリック統合 • APM から応答時間ベースの ML ジョブ を作成する機能 ‒ 異常を計算するためのプロファイル 応答時間 ‒ シーズナリティを考慮する
- 33. 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 … より多くのモジュール登場予定!
- 34. Demo
- 35. APM Python サンプルアプリのインストール • Form Rendering Examples をインストール • ブログ記事 【Djangoフォームを⼿動でレンダリングする⽅法】参照 https://simpleisbetterthancomplex.com/article/2017/08/19/how-to- render-django-form-manually.html git clone https://github.com/sibtc/form-rendering- examples.git pip install -r requirements.txt python manage.py migrate python manage.py runserver
- 36. APM Python Agent のインストール • Agent 側の操作なのでアプリケーション側にて修正 • 今回は Django の処理をモニタリングするため、Python 向けの APM Agent を利⽤ • pip コマンドでインストール python3 -V pip install elastic-apm
- 37. APM Python Agent の構成 (Django) # Add the agent to the installed apps INSTALLED_APPS = ( 'elasticapm.contrib.django', # ... ) ELASTIC_APM = { # Set required service name. Allowed characters: # a-z, A-Z, 0-9, -, _, and space ‘SERVICE_NAME’: ‘（⼀意）', ← 任意の名前 # Use if APM Server requires a token ‘SECRET_TOKEN’: ‘fGVbnnhItHK0PjpFOG’, ← APM ポータルから取得 # Set custom APM Server URL (default: http://localhost:8200) 'SERVER_URL': 'https://d4d99add430d497aaa1eba04b5175497.apm.japaneast.azure.elastic-cloud.com:443‘, } ↑ APM ポータルから取得 # To send performance metrics, add our tracing middleware: MIDDLEWARE = ( 'elasticapm.contrib.django.middleware.TracingMiddleware', #... ) settings.py • あとは Kibana で可視化・モニタリング
- 38. Transactions パフォーマンスのダッシュボード •Transactions duration, Transaction •URL パス単位での平均、95%タイルのレスポンスタイムが表⽰される •特定のパスの処理が遅い時はここを⾒ればすぐに分かる •Request Per Minute •HTTP レスポンスステー タスコード単位での 1分 毎のリクエスト数が表⽰ •リクエスト数が急増した ことが原因でレスポンス タイムが悪化したかここ で判断できる
- 39. .NET などは…
- 41. VS Code Conference Japan 11.21 https://vscode.connpass.com/event/184441
- 42. www.elastic.co Thank You for your attention!