Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年9月22日にAaron Newcombが投稿したブログ(https://sysdig.com/blog/prometheus-exporters-best-practices/)を元に日本語に翻訳・再構成した内容となっております。
以下のPrometheusエクスポーターのベストプラクティスは、Prometheusをベースにしたモニタリングソリューションを導入する際の参考になり、生産性の向上にもつながります。
Prometheusは、クラウドネイティブ環境の基盤の一つです。Kubernetes環境における可視性のデファクトスタンダードとなっており、Prometheusモニタリングという新しいカテゴリーを生み出しています。しかし、あなたが担当するシステムの多くのアプリケーションは、サードパーティ製のアプリケーションやクラウドサービスである可能性があり、それらはPrometheus形式のメトリクスをネイティブに公開していません。例えば、Linuxは、Prometheus形式のメトリクスを公開しません。そのため、ノード エクスポータのような Prometheusエクスポータが存在します。これをダウンロードして実行すれば、何百ものマシンレベルのメトリクスを公開することができます。
DevSecOpsとしても知られるSecure DevOpsは、開発から本番までのアプリケーションライフサイクル全体にセキュリティと監視をもたらします。これにより、安全で安定した高性能なアプリケーションを提供できるようになります。このワークフローは、既存のツールチェーンにプラグインされ、DevOps、開発者、およびセキュリティチーム全体に単一の真実のソースを提供し、効率を最大化し、トラブルシューティングと最適化のための可視性を提供します。
この記事では、Prometheusのエクスポーターを使ってアプリケーションやクラウドサービスを監視する際のベストプラクティスを見ていきたいと思います。
最近、あるお客様から言われました。
"私は、Prometheus エクスポータ、ダッシュボード、アラートのどのバージョンを使用すべきか、どのように設定するか、オープンソースの変更にどのように対応するかを考えるために、1つの統合につき1週間の開発者時間を費やしています。"
多くのPrometheusエクスポーターを実行しているときに発生するメンテナンスの負担は、思っている以上に深刻であることが多いです。考慮しなければならない非常に多くのエクスポーターと設定があるため、時には西部開拓時代のように感じることもあります。先回りして考え、これらのPrometheusエクスポーターのベストプラクティスを身につけることで、あなたの生活を楽にし、 エクスポーターのメンテナンスに費やす時間を減らし、組織のために変化をもたらすことに時間を割くことができるようになります。
Prometheusを使い始めると、アプリケーション環境にとって重要な様々なアプリケーションやクラウドサービスを監視するために利用できる多くのPrometheusエクスポーターがあることにすぐに気づくでしょう。しかし、どれを使用するかを選択するという問題も出てきます。
これを処理する1つの方法は、各候補のエクスポーターがどれだけあなたが興味を持っているメトリクスを提供しているか、またそのエクスポーターがソフトウェアプロジェクトとしてどれだけ健全であるかを個人的に評価することです。例えば、何年も前に一人で開発され、最近のアップデートがなく、PR/issue/Githubスターの数が少ないエクスポータは、未使用でメンテナンスされていない可能性が高いです。
メトリクスと Prometheus エクスポータのベストプラクティスの多くの側面は、一見して明らかではないので、既存のキュレーションされたリストに頼ることで、将来的にもうまく機能しそうなものを見つけるのに役立ちます。
最初に立ち寄るべきは、PrometheusのメインWebサイトのExporters and Integrationsページです。あなたのアプリケーションや、それがメトリクスを提供するプロトコルがそこにリストされている場合、そのエクスポーターが良い選択である可能性があります。
また、Sysdig がメンテナンスしている PromCat.ioや、デフォルトのポート割り当てページのようなサードパーティのエクスポーターリストもありますが、うっかりするとかなり包括的なエクスポーターリストになってしまいます。
PromCatは、Prometheusエクスポーター、ダッシュボード、アラートの選択とテストにかかる時間を短縮するのに役立ちます。Sysdigには、このサイトを維持するエンジニアチームがあり、継続的にコンテンツをテストして正常に動作することを確認しています。例えば、以下のようなものです。
各エクスポーターには、それが公開する独自のメトリクスのセットが付属しています。その情報を提供することは、Prometheusエクスポーターのベストプラクティスです。メトリクスの詳細は、通常、エクスポーターのプロジェクトページに記載されていますが、ヘルプファイルやドキュメントページで探さなければならないこともあります。エクスポーターがOpenMetricsフォーマットを使用している場合、メトリクスにタイプ、情報、単位などの追加情報を含むいくつかのフィールドを追加することができます。
エクスポーターのドキュメントで探すべきもう一つのことは、そのメトリクスを理解するのに役立つようにどのようにラベルを付けるかということです。
インストゥルメンテイションのラベルは、「これは本番サービスなのか開発環境なのか」、「サービスはどのホストで実行されているのか」、「このサービスはどのアプリケーションに属しているのか」などのコンテキストを提供します。例えば、バックエンドチームとアナリティクスチームの両方が独自のMySQLdsを持っている場合があります。後で、これらのメトリクスをフィルタリングして、アプリケーション名、生産と開発、または地域ごとに分割したいと思うでしょう。
インストゥルメンテイションラベルがアプリケーション内部で何が起こっているかを分析するときに便利であるように、ターゲットラベルは、デプロイメント全体のメトリクスを集約するときに便利です。ターゲットラベルを適切に使用することで、「すべての開発アプリケーションが現在世界中でどのくらいのCPUを使用しているか」や「ヨーロッパのフロントエンドチームが所有するすべてのアプリケーションの総RAM使用量はどれくらいか」などの質問に答えることができます。このウェビナーでは、ターゲットラベルの使用例を見ることができます。
アラートは、Prometheusエクスポーターのような新しいアプリケーション監視やクラウド監視ツールを学習する際に困難になることがあります。低いしきい値でアラートを設定すると、サポートチームはアラート疲労に陥ります。逆に、アラートが適切なタイミングでトリガーされない場合、エンドユーザーに影響を与えている可能性のある状態に関する重要な情報を見逃してしまう可能性があります。
アラート戦略を見極めるための最初のステップは、アプリケーションを理解することです。アプリケーションやサービスのゴールデンシグナルとともに、サービスレベルメトリクスとサービスレベル目標のDevOpsガイドラインに従うことで、どのような重要な要素がアラートを必要とするかを判断することができます。深い可視性とKubernetesコンテキストを備えた優れたモニタリングツールは、これらの重要な要素を見つけるのに役立ちます。
アラートにネイティブのPromQLを使用するツールを使用することで、アラートを別の形式に翻訳する必要がなくなり、エラーの原因になることを避けることができます。例えば、promtoolは、PromQLアラートの設定をテストするのに役立ちます（他のものの中でも）。
しかし、アラートのためのツールはPromQL以上のものを扱うことができなければなりません。任意のメトリクスやイベントに基本的なアラートを設定するだけでなく、そのアラートの結果を電子メール、Slack、Pagerduty、Service Nowなどに出力できるようにしなければなりません。
Prometheusエクスポーターからこの貴重なデータを入手し、アプリケーションの監視やクラウドサービスの監視に使用していますが、チームがそれを見て使用できるようにしてください。
これらのメトリクスを使用する最も一般的な方法は、ダッシュボード内でデータを可視化することです。ダッシュボードの作成を支援するために、PromCat.ioはGrafanaやSysdig Monitorにインポートできるダッシュボードテンプレートを提供しています。
しかし、あなたのチームはこれらのダッシュボードをどのように管理していますか？各チームメンバーがそれぞれのダッシュボードを作成するのではなく、1つのダッシュボードを作成し、DevOpsチーム全体で共有するというのが、Prometheusのエクスポーターのベストプラクティスです。チームメンバーはこれを例として使用し、必要に応じてマイナーチェンジを行うだけでよいのです。物事をうまく運ぶために、モニタリングツールは、誰がこれらのダッシュボードを見ることができ、どのレベルのアクセスが許可されているかを定義できるようにしておく必要があります（ビューのみ、または編集権限を持つコラボレーター）。
場合によっては、メトリクスデータへのアクセスを制限できるようにする必要があります。モニタリングツールでRBACが完全にサポートされている場合は、各チームに必要なデータだけを提供することができます。たとえば、アプリケーション・チームは自分のネームスペースから放出されるメトリクスのみにアクセスし、オンコール・チームはすべての本番ホストへの読み取り専用アクセスを必要とします。
PromQLは、Prometheusエクスポーターから収集したメトリクスをクエリーするためのパワフルな仕組みです。PromQLを使用すると、複雑な数学的操作や統計分析を実行したり、さまざまな関数を使用したりすることができます。
PromQLをマスターすると、モニタリングの専門知識がレベルアップしたように感じられるかもしれませんが、学習曲線が急なので、見過ごすことはできません。新規ユーザーにすぐに使いこなせるようにしたいのであれば、ダッシュボードを作成する際にフォームベースの簡単な入力ができるツールを使用するようにしましょう。新しいユーザに、結合と関数で構成される複雑なPromQLクエリを書かせるべきではありません。また、単純なレポートを実行して権利化タスクを実行したいだけの非技術者にとっては、ツールが複雑になるべきではありません。
Prometheusをより多くのエクスポーターと一緒に使い続けると、可視性、水平方向のスケーリング、および長期保存のボトルネックが発生するかもしれません。問題が発生する前に、Prometheus エクスポーターのメトリクスをどのようにスケーリングするかを計画することは、Prometheus エクスポーターのベストプラクティスです。
ここでは、これらの Prometheusのスケーリングの課題と、それに対処するためのいくつかの異なる方法を見てみましょう。
グローバルなPrometheusの可視性：規模が大きくなるにつれて、1つのクラスタからのデータだけでなく、インフラストラクチャーに適合する複数のクラスタ間でデータを確認し、より広範な環境のパフォーマンスを確認したいと思うようになるでしょう。
水平方向のスケーリング：環境が大きくなると、Kubernetesのサービス数、メトリクスカーディナリティ、Prometheusのメモリ使用量も大きくなります。設計上、Prometheusは水平方向にはスケーリングしません。垂直方向のスケーリングの限界に達したら、それで終わりです。
長期保存：Prometheus は、何百万もの測定値をリアルタイムで追跡することができます。しかし、データを長期間保存したいと思えば思うほど、より多くのリソースを消費することになります。メトリクスをすぐに削除しても、数週間、数ヶ月、数年にわたるトレンド分析のためのモニタリングデータを評価することはできません。
これらのスケーリングの問題に対処するには、Grafanaの統合、ThanosやCortexの導入、あるいはSysdigのような商用のソリューションを利用することができます。また、SaaSベースのソリューションは、SaaSソフトウェア・ベンダーが自社での拡張よりも容易に対応できるはずですので、スケールに関するいくつかの問題を確実に解決することができます。スケールに対応するためのこれらのソリューションの潜在的な問題点については、"Challenges using Prometheus at scale "で詳しく説明しています。
Prometheusは、クラウドネイティブ環境の基盤の一つとして、Kubernetes環境における可視性のデファクトスタンダードとなっています。重要なアプリケーションやクラウドサービスを監視するためには、エクスポーターが必要になります。すべてのエクスポーターが同じではなく、モニタリングソリューションはスケールに対応できない可能性があることを覚えておくことが重要です。これらのヒントが、メンテナンスの行き届いたプロジェクトを探し、メトリクスを理解し、前もって成長のための計画を立てることで、エクスポーターを使用したPrometheusの監視を成功させるのに役立つことを願っています。
適切なツールの選択が鍵となります。SysdigはこれらのPrometheusエクスポーターのベストプラクティスに従うことを可能にし、そのガイド付きのオンボーディングで5分以内に設定されます。当社のPrometheusとの完全な互換性、すぐに使えるダッシュボード、そして長期間の保持により、お客様の環境のパフォーマンスと可用性を向上させながら、MTTRを下げることができます。今すぐお試しください。
アプリケーションとクラウドサービスの監視ワークフローを実際に見るには、ウェビナー「So Many Metrics, So Little Time: 5 Prometheus Exporter Best Practices」をご覧ください。
