監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み

[utterances-bot]

監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み

https://k8sjp.github.io/kubefest-2020/sessions/27/

[bells17]

"CIOps/GitOpsによる運用自動化"について

デプロイ作業をCIOpsで行っている箇所もあるのでしょうか？

[kwy8791]

集約システム側では、全サービスのメトリクス値が見えてしまう気がするのですが、社内セキュリティルールとしては許容していらっしゃるのでしょうか？
（技術的な話ではないのですが…）

[bells17]

クラスターのアプリケーション別の固有の監視についてはこのクラスター監視とは別で行っているのでしょうか？

[TakumaNakagame]

基本的なメトリクスはKaaSチームが見ているとのことでしたが、クラスタ利用者がより詳細なメトリクスを取得したいとなった場合は、KaaSチームが利用しているPrometheusに相乗りする形になるのでしょうか？それとも、別途Prometheusを構築する形になるのでしょうか。
より詳細なメトリクスを収集したいという要望のときの動きが気になりました。

[hkatsuta]

ご質問ありがとうございます。回答させていただきます。

[hkatsuta]

@bells17 さん

"CIOps/GitOpsによる運用自動化"について

デプロイ作業をCIOpsで行っている箇所もあるのでしょうか？

ヤフー社内では Screwdriver.cd という CI/CD プラットホームがあり、KaaS 自体のデプロイや、クラスタアドオンのデプロイも CI から実施しております。k8s の manifest がブランチにマージされ次第、デプロイされるようになっています。

参考：

• CI/CDを通じて日本のソフトウェア開発を変えていくために今何が必要か？：CodeZine
• CI/CDの巨大パイプライン、デプロイを高速化するには？ 〜 インフラにおけるscrewdriver.cdカスタマイズ事例 - Yahoo! JAPAN Tech Blog

[hkatsuta]

@kwy8791 さん

集約システム側では、全サービスのメトリクス値が見えてしまう気がするのですが、社内セキュリティルールとしては許容していらっしゃるのでしょうか？
（技術的な話ではないのですが…）

ヤフー社内では情報管理規則があり、情報のレベルに応じて管理者側で見れるかどうかを調整しております。
KaaS 管理者がサービスの k8s のトラブルシュートに必要なメトリクスのみを収集し、例えばサービス側が公開したくない情報 (KPIなど) についてはサービス側で管理している Prometheus などに集約するなどの対応をお願いしています。

[hkatsuta]

@bells17 さん

クラスターのアプリケーション別の固有の監視についてはこのクラスター監視とは別で行っているのでしょうか？

はい、クラスタ利用者で作成されたアプリケーションの監視はクラスタ利用者の方で実施いたします。
PrometheusなどはKaaSチームがデフォルトで提供していますので、ruleを作成するだけで監視が実現できます。
その他として、ヤフー社内のログ監視プラットホームがあり、そちらでアプリケーション個別の監視設定を入れてもらっています。

[hkatsuta]

@TakumaNakagame さん

基本的なメトリクスはKaaSチームが見ているとのことでしたが、クラスタ利用者がより詳細なメトリクスを取得したいとなった場合は、KaaSチームが利用しているPrometheusに相乗りする形になるのでしょうか？それとも、別途Prometheusを構築する形になるのでしょうか。
より詳細なメトリクスを収集したいという要望のときの動きが気になりました。

Kubernetesクラスタ毎にPrometheusをデプロイし、よく使われる監視設定をプリセットしてサービス開発チームに渡しています。
クラスタ利用者(サービス開発チーム)がより詳細なメトリクスを取得したい場合は、そのPrometheusに自由にruleを追加してもらっています。
KaaSチームでは、集約用のPrometheusを別途立てて、そこにアラートメトリクスを集約しています。

[TakumaNakagame]

@TakumaNakagame さん

基本的なメトリクスはKaaSチームが見ているとのことでしたが、クラスタ利用者がより詳細なメトリクスを取得したいとなった場合は、KaaSチームが利用しているPrometheusに相乗りする形になるのでしょうか？それとも、別途Prometheusを構築する形になるのでしょうか。
より詳細なメトリクスを収集したいという要望のときの動きが気になりました。

Kubernetesクラスタ毎にPrometheusをデプロイし、よく使われる監視設定をプリセットしてサービス開発チームに渡しています。
クラスタ利用者(サービス開発チーム)がより詳細なメトリクスを取得したい場合は、そのPrometheusに自由にruleを追加してもらっています。
KaaSチームでは、集約用のPrometheusを別途立てて、そこにアラートメトリクスを集約しています。

ご回答ありがとうございます！
なるほどですねー！そして、 集約用のPrometheus というのが、セッションでもお話のあったFederationさせているPrometheusということなんですね！
ありがとうございます！とても参考になりました！

[bells17]

@hkatsuta ご回答いただきありがとうございます！

[kwy8791]

@hkatsuta さん。本編でもご回答頂きましたが、改めてご説明いただきありがとうございます。
なるほど、KaaS (CaaS?) チームはk8s に関する情報専任、サービス固有のメトリクスは、サービスを担当している方が独自に設定している（＆外には出さないようにしている）のですね。

それでは各サービス間で、監視項目の統一が取れない（監視がゆるいサービスとキツいサービスが出る）かと思ったのですが、@TakumaNakagame さんへの回答で、御社内での「この辺りは見ておいて」という社内標準みたいなものがあることも理解できました。
今回はとても参考になる発表をありがとうございました。超感謝です。