Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年7月23日にBrian Brazilが投稿したブログ(https://sysdig.com/blog/introduction-instrumenting-applications-prometheus/)を元に日本語に翻訳・再構成した内容となっております。
開発者として、アプリケーションから Prometheus のグラフにメトリクスを取得することは、大変なことのように思えるかもしれません。ここでは、サービスを分析してメトリクスを追加するための最も有用な場所を見つけ、どのようにインストルメンテーションを追加し、それを公開してスクレイプし、グラフ上でそれらのメトリクスを使用するための基本的なクエリーを取得するかを見ていきます。
インストルメンテーションに関する一般的な参考として、私の別の記事、Prometheusのメトリクスに関するこの記事、またはインストルメンテーションの代替品に関するこの比較をチェックしてください。
Prometheus は大きく成長しているエコシステムを持っているので、アプリケーションから素早くグラフを取得しようとしている開発者は、どこから始めればいいのか必ずしも明確ではありません。良いニュースは、組織全体でアラートとダッシュボードを備えたグローバルな冗長性と可用性の高いモニタリングシステムを実装する必要がないということです。むしろ、最小限の時間投資で、デスクトップ上で非常に小さなことから始めることができます。
最初のステップは、アプリケーションが HTTP 経由で Prometheus のメトリクスを公開するようにすることです。Javaでは、これは以下のように簡単にできます。
DefaultExports.initialize();
HTTPServer server = new HTTPServer(8000);
localhost:1234/metricsにアクセスすると、発生したガベージコレクションの数を表すjvm_gc_collection_seconds_countや、それらがすべてにかかった時間を表すjvm_gc_collection_seconds_sumのような、様々なJVMメトリクスをすぐに見ることができます。
metrics を見ることでデバッグすることは可能ですが、通常はグラフの方が明快です。Prometheus はこの /metrics を、以下のような最小限の設定でスクレイプすることができます。
global:
scrape_interval: 5s # Reduced for demo sake
scrape_configs:
- job_name: example
static_configs:
- targets: ['localhost:8000']
Prometheus を起動した後、PromQL クエリを実行して、アプリケーションのメトリクスをリアルタイムで集計して分析することができます。jvm_gc_collection_seconds_count をグラフ化したり、過去 1 分間の 1 秒あたりの GC を見るために rate(jvm_gc_collection_seconds_count[1m]) を実行したりすることができるようになりました。rate(jvm_gc_collection_seconds_sum[1m]) / rate(jvm_gc_collection_seconds_count[1m])は、それぞれのGCがかかる平均時間を見るために、または各メモリプールがどのくらいいっぱいになるかのためにjvm_memory_pool_bytes_used / jvm_memory_pool_bytes_maxを使用しています。
GCについて知ることは重要ですが、メトリクスが本当に輝く場所は、あなたに関連する独自のメトリクスを追加できることです。良いニュースは、メトリクスを追加することが簡単で、多くの場合、2 行のコードで済むということです。まず、メトリクスが何であるかを定義します。
static final Counter functionCounter = Counter.build()
.name("my_function_calls_total")
.help("Number of times my_function was called").register();
そして、関心のあることが発生した場合は、次のメトリクスを使用します。
functionCounter.inc();
Prometheusクライアントライブラリは、ブックキーピングやスレッドセーフなどの重要な詳細すべてを処理します。カウンターを定義してからインクリメントすることだけを気にする必要があります。このコードが含まれると、このメトリクスが時間の経過とともにどのように変化するかをグラフにしたり、メモリ使用量とリクエストの間におそらく関係があるかどうかを確認したりできます。
もちろん、これはワークステーションでの設定と実行がいかに簡単であるかを見ただけです。 基本に慣れてきたら、システム内でぶら下がっている果物を探すことができます。そこでは、インストルメンテーションが大きなメリットをもたらすでしょう。 開始するのに適した場所は、RPCクライアントやサーバーなど、要求の大部分が流れる自然のボトルネックです。 基本的なリクエスト、レイテンシ、およびエラーメトリクスをこれらを提供するライブラリに一度追加できる場合、すべてのアプリケーションがそれらの恩恵を受けます。
より実運用に近いユースケースでは、アプリケーションの既存の HTTP サーバにエクスポージョニングをフックして、はるかに多くのメトリクスを持ち、マシン上だけではない Prometheus を使用することになるでしょう。
しかし、Prometheusのアプローチの美しさの一つは、それぞれが一つのことをうまく行うデカップリングされたコンポーネントの一つであり、ローカルでデバッグしている間にいくつかのグラフをまとめることが完全に実行可能であるということです。
SysdigはPrometheusと完全に互換性があり、Prometheusのモニタリングを数百万のメトリクスにスケールアップして長期的に保持することができます。今すぐお試しください。