「“まずはMetricsだけ”はあり？」「通知部分はどう行う？」　可観測性を向上させる3つのシグナル導入に対するQ&A

とりあえずObservabillityをやってみる場合のおすすめ

司会者：質問してくれている人がいますね。質問者さん、マイクをオンにしてもらって。

質問者：はい。発表ありがとうございました、メッチャおもしろかったです。

相原魁氏（以下、相原）：ありがとうございます。

質問者：Observabillityをとりあえずやってみようとなった場合は、Prometheusを使ってみるのが一番簡単ですか？

相原：簡単という点でいったら、Prometheusの場合はMetricsを収集してくれるPrometheusのサーバを自分で用意しないといけなくなってしまうので、ちょっとハードルが高いです。ただ、最近GCPが、フルマネージドのPrometheusのサーバをサービスにしてくれたので、それを使うことでだいたい感覚はわかりそうです。

趣味であれば「Datadog」のようなSoftware as a Serviceを使うと、Prometheusのサーバに相当するものが簡単に手に入るので、そういうものでもいいかもしれません。

質問者：ありがとうございます。あともう1個あって、先ほどもトレーシングやMetricsのを見せてもらいましたが、可視化をしてMySQLの例で遅くなっているから調べ始めたという話だったと思いますが、アクションを始めるルールは決めておくものですか？

相原：そこはチームごとにがんばって文化を作らなければいけない部分です。我々のチームだと、相当大事な仕事をしていない限りは、通知を受け取った瞬間に即時に調査するルールにしていたりします。

だいたいSlackの通知で異常を検知できるようにしてあるので、そのSlackの通知を受け取った後にチームとしてどう動くかはわりと組織の話というか、チーム内でがんばってルールを決める感じになります。こういう話で合っていますかね。

質問者：ありがとうございます。以上です。

相原：これは大変ですね。深夜に問題が起きた時にどうするのかとかは、会社との契約の話にもなってきます。

質問者：ちなみに、それを知るためのことは、Slackに通知などで自動化することが多いですか。

相原：そうですね。実際にPrometheusとほとんど同じような開発者が、Prometheusと一緒に使うための「Alertmanager」というソフトウェアを開発しています。Prometheusには「Metricsがこうなったらアラートをする」という機能が組み込まれています。

Prometheusのアラートにする情報をアラートマネージャーというソフトウェアから受け取って、Slackなどのチャットサービスに通知するという機能をPrometheusコミュニティで全部用意してくれているので、それらを全部使ってSlackに通知するところまでは作っておくというような感じです。

質問者：通知する部分は自前でやる感じですか？

相原：そうですね。どういうルールを作るかは、大量のルールを経験のあるSREがたくさん用意して、Slackに通知されるようにしておくという感じですね。

質問者：ありがとうございます。

サービス初期にロギングで注意しておきたいこと

相原：「サービス初期のKubernetes使用サービスでは、どのようなロギング観点がありますか？」ということですが、このサービスがWebのアプリケーションだった場合、特にKubernetes特有のものというのはないです。

ただ、サービス初期から「あれは必要だろう」「これも必要だろう」とたくさんのロギングを実施しておくと、先ほど話したように、ログの保存のコストは高いので、あまり好ましくありません。実際にサービスを動かして運用をとおしていった上で、「ああ、じゃあこういう情報が必要だよね」と、後から必要な情報を足していくほうが失敗はしづらいと思います。

もちろん、経験があるエンジニアであれば、「だいたいこのくらいものが必要になるでしょ」と最初から用意できると思いますが、サービス初期という特有の事情であれば、最初からあまりたくさんのログを出し過ぎないというのは気をつけておいたほうがいいかもしれないです。

「まずはMetricsだけ」はありなのか？

相原：「ロギングとMetrics、トレーシングを全部やるのが大変だから、まずはMetricsだけみたいなこともありですか？」という質問です。ありがとうございます。

これはあまりおすすめはしていなくて。先ほど話したように、これらはすべてそれぞれ補完し合う関係にあるので、できれば全部一遍に欲しいです。どれか1つを外すのであれば、トレースだけは外してログとMetricsだけはやるのが、よくある妥協の仕方かなと思います。

ただ一方で、先ほど話したように、OpenTelemetryのSDKを入れるだけで、Metricsとトレースの出力は完了します。あとはこれを入れるだけで大まかなトレースの収集も終わってしまうので、がんばってOpenTelemetryのSDKを入れた上で、必要最低限のロギングをしておくだけでも、可観測性は十分になります。

一方で、これだけだとMetricsは足りなかったりするので、それはそれぞれのメソッドに従って徐々に付け足していきます。トレースに関しても、OpenTelemetryのSDKによって導入ができるのはHTTPのクラアイントやDBのクライアントに対してなので、外部のI/Oだけです。

本当はI/Oを伴わない部分のトレースも考えないといけないのですが、それは別に後からでいいので、大変だとは思いますが、ログとOpenTelemetryのSDKの導入まではやっておくといいと思います。

これは導入はすごく簡単で、言語ごとのSDKを導入して、READMEに従って設定するだけなのでやっておきたいかなという感じです。

将来はログのサポートも入るみたいなので、将来的にはもうOpenTelemetryを入れるだけで全部が、すべてが済む世界観が実現されると思います。

今後は継続的プロファイリングも重要になってくる

司会者：ありがとうございます。では、せっかく準備されたので、おまけのところで伝えたいことがあれば。

相原：ちょっと重たい話なので、興味があれば、SlideShareからおまけも読んでもらえるといいと思います。

（スライドを示して）このプロファイリングはPrimary Signalsに追加されるもう1つのシグナルとして最近注目されている概念で、今後重要になってくると思うので、このあたりも追っておくと可観測性のさらに次の一歩に踏み出せると思います。興味がある方はぜひご覧ください。

司会者：ありがとうございます。あらためて読み返してもらったり、おまけのところもぜひ見てもらえればと思います。では、最後に一言コメントをいただいて終わりますか。

相原：おまけに書いておいたのですが、我々が作っている内製PaaSの「KEEL」は、このような可観測性に関して考えて、開発者に対して環境を提供するみたいなことをやっています。2023年卒のエンジニア採用の話ではありませんが、興味がある方はお待ちしていますので、ぜひお越しください。では、今日はご清聴いただきありがとうございました。

司会者：ありがとうございました。