TeleTrackingのGrafana Cloudを用いた優れた可観測性プラットフォーム構築の旅
オレン・ライオン、ソフトウェアエンジニアリングディレクター、プロダクティビティエンジニアリング、およびティム・シュルーベン、物流エンジニアリング副社長、共に勤務しています。テレトラッキング、医療システムがケアへのアクセスを最適化し、ケアの提供を合理化し、ケアの移行をつなぐことでExpanding the Capacity to Care™することを支援する、統合型医療オペレーションプラットフォームプロバイダー。
今日の分散アプリケーションが多くの複雑さをもたらすならば、観測性チームの究極の目標は、開発チームが自分たちのサービスに観測性を簡単に統合し、フィードバックを得て、潜在的な問題に対応することを容易にすることです。
私たちのエンジニアリングチームはテレトラッキング私たちの集中化された可観測性スタックの採用を通じて、その哲学を現実にしています。それは、次の要素を組み合わせています。プロメテウスとグラファナクラウドメトリクスとログのために。これらのツールはサービスへの可視性を高めるだけでなく、常に進化する開発者体験のための重要なフィードバックメカニズムとしても機能します。また、以下を使用してオーバーヘッドを削減しました。適応メトリクス、Grafana Cloud のメトリクスコスト管理ツール、および他の高インパクトプロジェクトへのチームの投資を増やしました。
このブログでは、私たちがどのようにここにたどり着いたか、会社の他の人々をどのように巻き込んだか、そしてGrafana Cloudがどのようにビジネスにより多くの価値をもたらし、同時にお金と時間を節約するのに役立ったかを紹介します。
SaaSからOSSへ、そして再び戻る
私たちが今日Grafana Cloudをどのように使用しているかについて話し始める前に、まずここに至った経緯を簡単に振り返りたいと思います。約6年前、私たちの観測コストは非常に高額になっていたため、それを変える決断をし、オープンソースツールを使ってすべてを自社開発することにしました。グラファナ、プロメテウス、およびサノス。
私たちのシステムは、サービスのグローバルな視点を持つように設計されており、AWSやMicrosoft Azureを通じて自然に成長し、Amazon EKSやAzure Kubernetes Service (AKS) のクラスター、Amazon EC2、AWS Lambda、Azure VM、Azure App Servicesを含むさまざまなクラウドリソース上で動作していました。そして、オープンソースを愛用する一方で、最初に設定した目的、すなわち観測可能性を効果的でセルフサービスで低コストにするということを見失ってしまいました。運用が拡大する中で、逆の方向に進んでしまい、管理されたソリューションに戻る必要があると気づきました。
最終的に、Grafana Cloudを選択しました。メトリクスとログの間で共通のラベルを持てる点が気に入りました。また、どれだけうまく...グラファナ・ロキ（オープンソースのロギングソリューションであるGrafana Cloud ログ) 実行されました。そして、ログを事前にどのように解析したいかを定義する必要がなかったことを気に入りました。また、リモートライトモデルを使用するGrafana Cloud Metricsの中央集権的なアプローチや、Grafanaのダッシュボードでメトリクスとログを並べて視覚化できる機能も気に入りました。
Grafana Cloudでより良い可観測性への道
一度切り替えた後、私たちは開発者がどのようにサービスを監視するかを構成しやすくしたいと考えました。以下は、私たちが行った変更の概要です。
簡易設定
私たちが行った最初の変更の一つは、開発者がアラートルールを含む監視設定を、自分たちのサービスのソースコードと同じリポジトリに保存できるようにすることでした。
アラートルールの設定はワンライナーで簡素化されました。Bitbucketパイプアラートルールこれはリポジトリのビルドファイルにあります。それはGrafana Cloudにアラートルールを公開します。多くのアラートルールはすべてのサービスに共通しており、例えば、アップおよびアブセントアラートやイベント処理の偏差ですので、標準アラートを集中リポジトリに保存しました。
監視構成は、追加によって簡素化されましたサービスモニターリポジトリへ。簡単なデプロイのため、デプロイパイプラインに変更を加えることなく、それを追加するだけで済みます。カスタマイズファイル。
目的地: 2つのキーレーベル
ソフトウェアエンジニアリングチームはサービスラインとサービスに沿って再編成されました。それにより、チームが同じ組織原則を可観測性に適用することを容易にしたいと考えました。そのために、すべてのメトリックとログに付ける2つの主要ラベル（サービスラインとサービス）を標準化しました。メトリックとログの全体にわたるシンプルかつ一貫したラベリングは、開発者がデータを相関させ、二つを行き来し、一貫したアラートを受け取ることを容易にします。
これらのラベルはすでにKubernetesで実行されるサービスのサービスマニフェストに設定されていたため、メトリクスにこれらのラベルを追加するのは、設定を行うことによって行われました。ターゲットラベルServiceMonitorファイルのフィールドを「service」と「serviceline」に。ターゲットラベルKubernetesサービスからラベルをメトリクスに注入します。
ログについては、サービスラインラベルとして注入する値をどこから引き出すかという問題に直面しました。そこで、Kubernetesのネームスペースをサービスラインラベルとして使用することに決定しました。しかし、私たちのチームはサービスラインにちなんで名付けられたネームスペースにサービスをデプロイしていなかったため、開発者たちはこれらの新しいネームスペースに再デプロイする必要がありました。
Kubernetesクラスターで実行されないサービスには追加の変更が必要でした。これらはベーキングからグラファナエージェントAMIsにレガシーサービスにログアペンダーを追加するコード変更。すべての設定は、サービスラインとサービスラベルを挿入する必要がありました。
それらの2つの重要なラベルを持つことで、チームはメトリクスやログを簡単にクエリし、アラートを出すことができました。ダッシュボードの設定も同様に、そのラベルをフィルタリングすることで簡素化されました。これで、可視性を簡単に得ることができます。赤プラットフォーム全体の指標をサービスラインに絞り込み、さらに各サービスにまで詳細化する。
関数のための舗装された道
AWS Lambdaで実行されるサービス向けに、次の機能を備えた新しいコードリポジトリを事前に構築する「舗装された道」リポジトリクリエイターを構築しました。
- SpinnakerおよびTerraformを使用してAWSにコードをデプロイする
- メトリクスをPrometheus Pushgatewayにプッシュする
- Grafana Cloudにアラートルールを公開する
- ログをLokiに転送する
舗装された道路Lambdaリポジトリを使用する開発者は、サービスのデプロイや監視などの依存関係にかける時間が減り、ビジネス機能に集中する時間が増えました。今年の後半には、このモデルをマイクロサービスに拡大する予定です。
2つのラベル、1つのルート、そして1人の受信者がバーに入る
アラートはサービスラインとサービスラベルに基づいていたため、定義されたすべてのサービスラインに対してすべてのルートとレシーバーが事前構築されていました。オンコールエンジニアに24時間体制で通知する優先度の高いアラートと、あまり緊急性のない情報アラートを区別するために、各サービスラインには2つのレシーバーがあります。1つはオンコールエンジニアに送信される高い重大度用で、もう1つは中央のSlackチャンネルに投稿される低い重大度用です。
はい、最初はそのアイデアに尻込みしたエンジニアもいましたが、キーレーベルを使用し始め、ダッシュボードを設定し、簡単にアラートを書けるようになると、その価値をすぐに理解しました。それにログとメトリックの間をシームレスに行き来できる機能も加わり、開発者たちはこの新しいフレームワークにすぐに飛びつきました。
より少ないものでより多くを得る
Grafana Cloudは、私たちのチームの作業負担を大幅に軽減しました。自分たちでホスティングしたスタックの管理や、ネットワーク全体のクエリに関する権限のトラブルシューティングを心配する必要がなく、すべてが処理されています。
そして、その2キーラベリングのディシプリンが成果を上げています。現在、細かく分けたビューと粗く分けたビューの組み合わせがあります。ダッシュボードのラベルに配置した変数を使用することで、ビジネスメトリクスから低レベルのサービスラインやサービスメトリクスまで、また戻ることができます。
ツール間のこの統一性により、多くのタスクを簡単に実行できます。なぜなら、すべてを1つのダッシュボードに集約し、他の人が独自のアラートを作成することを許可できるからです。これは他の観測ツールではできなかったことであり、ラベルフックが私たちの成長に伴って引き続き効果を発揮し、他のGrafana Cloudサービスを採用したり、サードパーティのデータソースを統合したりすることを期待しています。
コストを抑える
メンテナンスが少ないことに加えて、かなりのコスト削減も実現しましたが、初期の予算制約に直面するまでには至りませんでした。初期のコストはGrafana Cloud Logsの月間目標を上回る傾向がありましたが、チームがより良いログ管理の実践を取り入れるにつれて、多少の変動は予想していました。これらの超過を解消するために、ログのインジェストボリュームを監視し、デバッグ作業が完了した後に開発チームと協力してログレベルを引き下げました。
私たちが不意を突かれたのは、Grafana Cloud Metricsでのコストがどれほど速く増加するかということでした。メトリックのコストを予測するのは難しい場合がありますが、新しいサービスやエクスポーターがそれぞれ重要な支出の増加と相関していることに気づきました。
私たちは使用しましたカーディナリティ管理Grafana Cloud のダッシュボードで、支出の増加を引き起こしたメトリクスを特定しましたが、コードの変更とデプロイが完了するまでコスト削減が実現されなかったため、すぐには節約にはつながりませんでした。しかし、支出に対する迅速かつ低労力の対応を見つけました。適応型メトリクス、未使用または部分的に使用されたメトリックを低カードシナリティのバージョンに集約します。それはメトリックにとって「ログレベル」のように機能する特徴です。積極的にデバッグを行い、詳細な情報を提供するラベルが必要なときにメトリックの冗長性を高めることができます。そして、デバッグが終わると、Adaptive Metricsを使ってラベルを再集約することで、より冗長性の低いメトリックに戻すことができます。それにより、Grafana Cloud Metricsでの支出が50%削減されました！
また、Grafana Cloudが予想外の方法でお金を節約してくれたことにも満足しています。まず、Grafana Labsと協力して契約を調整し、予測された使用量に基づいて事前支払いの支出コミットメントで運用できるようにしました。この変更により、潜在的な超過を回避し、全体の請求書を20％削減することができました。また、Grafana Cloudでのリソース配分に柔軟性が生まれました。最後に、最近の経済的不確実性の中で重要であった支出の予見可能性を提供しました。
より多くの機能、より低いコスト
現在、それらの節約を全体の請求額の削減と組み合わせることで、主要ラベルでまとめられたこの可観測性フレームワークの下でより多くの機能を整合させる準備が整いました。私たちは、その節約分をGrafana Cloudに再投資する予定です。
フロントエンド可観測性リアルタイムのフロントエンドメトリクスを取得するために採用され、ブラウザ内のユーザーエクスペリエンスとバックエンドサービスとの相関を引き出すことができます。そしてグラファナインシデントオンコールサービスラインチームメンバーを、彼らが使用するログとメトリクスとより緊密に統合するために採用され、サービスの回復を迅速化します。
フロントエンド可観測性への移行（オープンソースによって提供されるGrafana Faroweb SDK)、Grafana Incident（の一部Grafanaインシデント＆レスポンス管理一連のサービスは、今年後半に移行する競合製品への支出を大幅に削減することを可能にします。
それはほんの数年前とは大違いです。もうただ灯りをともして火を消すだけではありません。今日では、私たちは積極的にビジネスをサポートする新しい方法を見つけ、開発者がより簡単に、迅速に、そしてより良く仕事をするのを助けています。
Grafanaクラウドメトリクス、ログ、トレース、ダッシュボードなどを始める最も簡単な方法です。私たちには寛大な永遠に無料のプランがあり、あらゆるユースケースに対応したプランがあります。今すぐ無料でサインアップ！