この記事ではKubernetesの監視方法とソリューションを説明し、ロギングシナリオに焦点を当てています。
著者：アリババのテクニカルエキスパートであるLiu Zhongwei (Moyuan)氏
1) 背景
モニタリングとロギングは、大規模な分散システムの重要なインフラストラクチャコンポーネントです。モニタリングは開発者がシステムの稼働状況を確認するのに役立ち、ロギングは問題のトラブルシューティングや診断に役立ちます。
Kubernetesでは、モニタリングとロギングはエコシステムの一部ではありますが、コアコンポーネントではありません。そのため、ほとんどの場合、両方の機能を適用するには、上位層のクラウドベンダーが適合させる必要があります。Kubernetesでは、アクセス基準やAPIの仕様が定義されており、API基準に準拠したあらゆるコンポーネントとの迅速な統合が可能です。
2）モニタリング
モニタリングの種類
Kubernetesでは、4種類のモニタリングサービスを提供しています。
1) リソース監視
CPU、メモリ、ネットワークの使用率など、一般的なリソースメトリクスは、通常、数字やパーセンテージで収集されます。これは最も一般的なモニタリングサービスです。Zabbix Telegraphなどの従来の監視システムでも提供されているサービスです。
2) パフォーマンス監視
パフォーマンス監視とは、APM(Application Performance Management)監視のことで、一般的なアプリケーションのパフォーマンス指標をチェックするものです。一般的には、仮想マシン層やバイトコード実行層で暗黙的に呼び出されるフック機構や、アプリケーション層で明示的に注入されるフック機構があり、高度なメトリクスを取得します。これらの高度なメトリクスは、通常、アプリケーションの最適化や診断に使用されます。例えば、Java仮想マシン(JVM)用のZend EngineやPHP(Hypertext Preprocessors)などの一般的な実装では、一般的なフック機構を使用して、JVM内のガベージコレクション(GC)の数、異なる世代のメモリの分布、ネットワーク接続の数などのメトリクスを収集します。これらのメトリクスは、アプリケーションのパフォーマンスを診断し、最適化するために使用されます。
3）セキュリティモニタリング
セキュリティモニタリングとは、主に不正アクセスの管理やセキュリティ脆弱性のスキャンなど、一連のセキュリティモニタリングポリシーを実行することです。
4）イベントモニタリング
イベントモニタリングは、Kubernetesの特別なモニタリングサービスです。前回の記事では、Kubernetesの設計思想として、ステートマシンによる状態遷移が挙げられていました。具体的には、ステートマシンが正常な状態から別の正常な状態に遷移すると正常イベントが発生し、正常な状態から異常な状態に遷移すると警告イベントが発生します。その間、通常は警告イベントが重要となります。イベントモニタリングとは、正常なイベントや警告イベントをデータセンターにキャッシュし、データセンターがイベントを分析してアラートを生成し、DingTalkメッセージ、SMSメッセージ、または電子メールを通じて対応する例外を公開することです。このモニタリングサービスは、従来のモニタリングの欠陥や欠点を克服しています。
Kubernetesにおけるモニタリングの進化
バージョン1.10以前のKubernetesでは、アナリストはHeapsterなどのコンポーネントを使ってメトリクスを収集していました。Heapsterの設計思想は、実はとてもシンプルなものです。
まず、データを収集するために、パッケージ化されたcAdvisorコンポーネントが各Kubernetesのトップに提供されます。cAdvisorがデータ収集を完了すると、Kubernetesがデータをパッケージ化し、対応するAPIとして公開します。初期の段階では、3つのAPIが提供されます。
- Summary API
- Kubelet API
- Prometheus API
これらのAPIは、データフォーマットが異なることを除いて、すべてcAdvisorのデータソースに対応しています。Heapster は Summary API と Kubelet API をサポートしています。Heapsterは定期的に各ノードからデータを取り出し、メモリにデータを集約し、対応するサービスを上位層のコンシューマーに公開します。Kubernetesでは、ダッシュボードやHPA（horizontal pod autoscaler）コントローラなどの一般的なコンシューマが、対応するサービスを呼び出して監視データを取得し、必要なオートスケーリングを実行してモニタリングデータを表示します。
これは初期の頃に使われていたデータ消費リンクで、多くの問題がなく曖昧さがないように思えます。では、なぜKubernetesはHeapsterからmetrics-serverに変わったのでしょうか。実は、HeapsterがモニタリングデータのAPIを標準化したことが大きな理由です。では、なぜHeapsterは監視データのAPIを標準化したのでしょうか。
- お客様の要求は刻々と変化しています。例えば、今日はHeapsterを使って基本的なデータを収集したいが、明日はアプリケーション内のオンラインユーザー数を公開するためのデータAPIを開発したいということがあるかもしれません。さらに、データAPIを独自のAPIシステムに追加して、監視データを表示し、HPAコントローラと同じ方法でデータを消費したいと思うかもしれません。このシナリオをHeapsterで実装することは可能でしょうか？答えはノーです。これは、Heapsterのスケーラビリティが低いことを示しています。
- 2つ目の理由は、Heapsterがデータをキャッシュするために多くのシンクを提供していることです。これらのシンクには、InfluxDB、Simple Log Service（SLS）、DingTalkなどがあり、主にデータの収集とキャッシュを担当しています。多くのお客様は、InfluxDBを使ってデータをキャッシュし、InfluxDBをGrafanaなどのモニタリングデータ可視化ソフトウェアに接続して、モニタリングデータを表示しています。
しかし、コミュニティでは、これらのシンクはたいていメンテナンスされずに放置されていることがわかりました。その結果、多数のバグがHeapsterプロジェクト全体に常駐し、コミュニティにも残っていましたが、誰にも修正されませんでした。これは、コミュニティのプロジェクトの活動と安定性に大きな課題をもたらします。
この2つの理由から、KubernetesはHeapsterを壊し、その後、合理化されたメトリクス収集コンポーネントであるmetrics-serverを作りました。
前述の図は、Heapsterの内部アーキテクチャを示しています。図に示すように、Heapsterはいくつかの部分に分かれています。最初の部分はコアです。上の部分は、標準的なHTTPまたはHTTPSで公開されるAPIです。真ん中のソース部分は、収集したデータを公開するための異なるAPIに相当します。真ん中のプロセッサ部分は、データの変換や集計に使われます。最後の部分はシンクで、データのキャッシングを担当します。これがHeapsterの初期段階のアプリケーションアーキテクチャです。後期になると、Kubernetesが監視APIを標準化し、Heapsterは徐々にmetrics-serverに切り替わっていきます。
現在、metrics-server 0.3.1の構造は、前掲の図に示すように、非常にシンプルなものとなっています。コア層、ソース層、シンプルなAPI層、そして追加のAPI登録層が含まれています。追加API登録層では、対応するデータAPIをKubernetesのAPIサーバーに登録することができます。将来的には、metrics-serverを利用するために、お客様はAPI層にアクセスする必要がなくなり、代わりにAPIサーバーを利用してAPI登録層にアクセスできるようになります。この場合、実際のデータ消費者はmetrics-serverを認識するのではなく、そのようなAPIの特定の実装を認識する可能性があり、その場合の実装はmetrics-serverとなります。これが、Heapsterとmetrics-serverの最大の違いです。
KubernetesにおけるデータモニタリングのAPI規格
Kubernetesでは、モニタリングサービスのために3つのAPI標準を用意しています。具体的には、監視データの消費機能を標準化して切り離し、その機能をコミュニティに統合しています。コミュニティでは、APIを3種類に分類しています。
タイプ1）リソースメトリクス
対応するAPIはmetrics.k8s.ioで、その主な実装はmetrics-serverです。このAPIは、ノード・レベル、ポッド・レベル、ネームスペース・レベル、クラス・レベルで共通のリソース・メトリクスを提供します。このタイプのメトリクスは、metrics.k8s.io APIを通じて取得します。
タイプ2）カスタムメトリクス
対応するAPIはcustom.metrics.k8s.ioであり、主な実装はPrometheusです。リソース・メトリクスとカスタム・メトリクスを提供しています。これらのメトリクスは、実際には先行するリソースメトリクスと重複しています。カスタム・メトリクスはユーザーが定義するもので、例えば、アプリケーション内で公開されるオンライン・ユーザー数や、次のデータベースのMySQLで呼び出されるスロー・クエリなどがあります。このようなメトリクスは、顧客がアプリケーション・レイヤーで定義し、Prometheusクライアントが公開し、Prometheusが収集します。
この種のAPIを介して収集されたデータは、custom.metrics.k8s.io APIを介して収集されたデータと同じ方法で消費されます。つまり、この方法でPrometheusにアクセスすれば、custom.metrics.k8s.io APIを通じて水平方向のポッドオートスケーリングを実装し、データを消費することができます。
タイプ3）外部メトリクス
外部メトリクスAPIは、実はとても特別なものです。周知の通り、KubernetesはクラウドネイティブなAPIの実装標準となっています。ほとんどの場合、クラウド上ではクラウドサービスしか使われません。例えば、あるアプリケーションがフロントエンドでメッセージキューを使用し、バックエンドでリモートBLOBストレージ（RBS）データベースを使用するような場合です。時には、データ消費時に一部のクラウド製品のメトリクスも消費されます。これらのメトリクスには、メッセージキュー内のメッセージ数、アクセス層のサーバーロードバランサー（SLB）への接続数、SLBの上位層での200リクエストの数などがあります。
では、これらのメトリクスをどのように消費するのか。これらのメトリクスを消費するために、Kubernetesにもexternal.metrics.k8s.ioという規格を実装しています。この規格は、主にクラウドプロバイダーによって実装されています。プロバイダはこのAPIを使ってクラウドのリソースメトリクスを取得します。Alibaba Cloudでは、External.metrics.k8s.io APIを実装するためのAlibaba Cloud Metrics Adapterも提供しています。
Prometheus - オープンソース・コミュニティのモニタリング・スタンダード
ここで、オープンソース・コミュニティで一般的なモニタリング・ソリューションであるPrometheusを紹介しましょう。なぜPrometheusは、オープンソース・コミュニティのモニタリング・スタンダードになっているのでしょうか？
- まず、Prometheusは、Cloud Native Computing Foundation（CNCF）のプロジェクトです。現在、Prometheusをモニタリング標準として採用するオープンソースプロジェクトが増えています。実際、Spark、TensorFlow、Flinkなどの一般的なプログラムには、それぞれ標準のPrometheusコレクションAPIが用意されています。
- 次に、データベースやミドルウェアなどの一般的なプログラムには、対応するPrometheusの収集クライアントがあり、etcd、ZooKeeper、MySQL、PostgreSQLなどのプログラムには、対応するPrometheusのAPIがあります。Prometheus APIがない場合は、コミュニティが対応するエクスポーターを提供してAPIを実装します。
次に、Prometheusの全体的なアーキテクチャを見てみましょう。
前述の図は、Prometheusのデータ収集リンクを示したもので、3つのデータ収集モデルに分類されます。
- 1つ目は、プッシュ・モデルです。このモデルでは、Pushgatewayを通じてデータを収集してキャッシュし、PrometheusがPushgatewayからデータを引き出します。この収集方法は、主にタスクが短時間しか続かないシナリオでの問題点を解決します。具体的には、Prometheusで最も一般的な収集方法として知られているプルモデルでは、データ宣言サイクルがデータ収集サイクルよりも短い場合、一部のデータが収集できないことがあります。例えば、収集サイクルが30秒であるのに対し、タスクの実行時間が15秒しかない場合、一部のデータが収集されない可能性があります。この問題に対処するには、最もシンプルなソリューションは、Pushgatewayにデータを送信してメトリクスをプッシュし、その後Pushgatewayからデータをプルすることです。この方法では、過渡的なタスクはジョブを失うことなく完全に実行されます。
- 2つ目は、標準的なプルモデルです。このモデルでは、データは対応するタスクから直接引き出されます。
- 3つ目はPrometheus on the Prometheusモデルです。このモデルでは、データはあるPrometheusインスタンスから別のPrometheusインスタンスに同期されます。
以上が、Prometheusの3つのデータ収集方法です。データソースについては、Prometheusは標準的な静的設定だけでなく、サービスディスカバリーによってデータソースをスクレイピングします。具体的には、Prometheusは特定のサービス・ディスカバリー・メカニズムを使って収集対象を動的に発見します。Kubernetesでは一般的ですが、この動的発見メカニズムでは、いくつかのアノテーションを設定するだけで、データを収集するための収集タスクを自動的に設定してくれるので、非常に便利です。
さらに、PrometheusではAlertmanagerという外部コンポーネントが用意されており、メールやSMSメッセージでアラートを送信することができます。また、Prometheusはデータを表示・消費するための上位層のAPIクライアント、Web UI、Grafanaを提供しています。
まとめると、Prometheusには以下のような特徴があります。
- シンプルで強力なアクセス規格：データを収集するために、開発者はAPI標準としてのPrometheusクライアントを実装するだけです。
- 多様なデータ収集・キャッシュ方法：Prometheusでは、Pushing、Pulling、Prometheus on Prometheusの各モードでデータを収集し、キャッシュすることができます。
- Kubernetesとの互換性。
- 豊富なプラグインメカニズムとエコシステム。
- Prometheusオペレーター：Prometheus オペレータは、おそらく我々が見てきた中で最も複雑なオペレータです。しかし、Prometheus オペレータは、Prometheus のスケーラビリティを利用できるオペレータでもあります。KubernetesでPrometheusを使用している場合は、Prometheus演算子を使用してKubernetesのデプロイとメンテナンスを行うことをお勧めします。
Kube-eventer - Kubernetesのイベントキャッシングツール
最後に、KubernetesのイベントキャッシングツールであるKube-eventerを見てみましょう。Kube-eventerコンポーネントは、Alibaba Cloud Container Serviceのオープンソースのコンポーネントです。Kubernetesでは、ポッドやノード、コアコンポーネント、カスタムリソース定義（CRD）などのコンポーネントのイベンターをキャッシュします。APIサーバーのウォッチ機構により、Kbe-eventerはSLS、DingTalk、Kafka、InfluxDBなどのアプリケーションへのイベンターをキャッシュし、一定期間の監査、監視、アラートを行います。現在、このプロジェクトをGitHubでオープンソース化しています。ご興味のある方は、GitHubにアクセスして本プロジェクトをご覧ください。
前述の図は、DingTalk上の警告のスナップショットを示しています。図に示すように、Kube-system名前空間に対して警告イベントが生成されており、原因は「バックオフによりポッドの再起動に失敗した」というものです。また、障害が発生した具体的な時刻も表示されています。これらの情報をもとにチェックを行います。
3) ロギング
ロギングのシナリオ
次に、Kubernetesのロギングサービスを見てみましょう。Kubernetesでは、主に4つのシナリオでロギングが提供されています。
1) ホストのカーネル・ログ
- ホストのカーネルログは、開発者が一般的な問題を見つけて診断するのに役立ちます。最初の一般的な問題は、ネットワークスタックの例外です。このような例外が発生すると、コントローラ・テーブルに関するメッセージがiptablesマークに表示されることがあります。
- 2つ目の共通の問題は、ドライブの例外です。これらは、一部のネットワークソリューションやGPU関連のシナリオでよく見られます。
- 3番目によくある問題は、ファイルシステムの例外です。実は、Dockerが未熟だった初期の段階では、これらの例外はオーバーレイファイルシステム（OverlayFS）や高度な多層統一ファイルシステム（AUFS）で頻繁に発生していました。当時は、開発者がこれらの問題を監視・診断する手段がありませんでした。現在では、このような例外は、ホストのカーネルログで直接発見することができます。
- 4つ目の共通の問題は、いくつかのノード例外です。例えば、カーネルパニックやカーネル内のメモリ不足（OOM）の問題は、ホストのカーネルログにも反映されます。
2）ランタイムログ
Dockerのログの中には、一般的なランタイムログがあります。Podの削除がうまくいかないなどのトラブルシューティングに利用されます。
3）コアコンポーネントのログ
Kubernetesのコアコンポーネントには、etcdなどの外部ミドルウェアや、APIサーバ、kube-scheduler、controller-manager、kubeletなどの内部コンポーネントがあります。これらのコンポーネントのログにより、Kubernetesクラスタ全体のコントロールプレーンにおけるリソースの使用状況や、現在の実行状態で例外が発生していないかなどを知ることができます。
また、ネットワークミドルウェアのingressなど一部のコアミドルウェアでは、アクセスレイヤー全体のトラフィックを見ることができます。ingressのログを使って、アクセス層の詳細なアプリケーション分析を行うことができます。
4）導入済みアプリケーションのログ
配置されているアプリケーションのログから、サービス層の状況を確認することができます。例えば、アプリケーションのログでは、サービス層に500のリクエストがあるか、パニックが発生していないか、異常なアクセスや不正なアクセスが発生していないかなどを確認できます。
ログ・コレクション
さて、ここからはログ収集について説明します。一般的に、さまざまな場所からログを収集するために、Kubernetesには大きく分けて3つのログ収集方法が用意されています。
- 1つ目の方法は、ホストファイルからログを収集する方法です。一般的に、ボリュームなどのコンテナのコンポーネントは、ログファイルをホストに書き込みます。そして、ホストのログローテーションポリシーに基づいて、ログファイルがローテーションされます。最後に、ホスト上のエージェントがログを収集します。
- 2つ目は、コンテナ内からログファイルを収集する方法です。しかし、これらのファイルを処理する一般的な方法は何でしょうか？一般的には、サイドカー・ストリーミング・コンテナがログファイルを標準出力に書き込み、それが対応するログファイルに書き込まれます。その後、ログファイルはローカルにローテーションされます。最後に、外部のエージェントがログを収集します。
- 3つ目の方法は、ログをstdoutに直接書き込む方法です。これは、一般的なロギングポリシーです。リモートエンドは、エージェントを使用するか、いくつかのサーバーレスAPIなどの標準APIを呼び出して、ログを直接収集します。
コミュニティでは、Fluentdという収集ソリューションを推奨しています。Fluentdでは、各ノードでエージェントが選出され、そのエージェントがFluentdサーバーにデータを集約します。このサーバーは、データをElasticsearchなどの対応するコンポーネントにキャッシュし、Kibanaがデータを表示します。あるいは、サーバーはデータをInfluxDBにキャッシュし、Grafanaがデータを表示します。これは、コミュニティで推奨されている方法です。
4）まとめ
最後に、本日のコースの締めくくりとして、Alibaba Cloudでのモニタリングとロギングのベストプラクティスを見てみましょう。コースの最初で述べたように、モニタリングとロギングはKubernetesのコアコンポーネントではありません。Kubernetesはほとんどのモニタリングとロギング機能をサポートするためのAPI標準を定義しており、それを上位層のクラウドベンダーが個別に適応しています。
Alibaba Cloud Container Serviceのモニタリングシステム
モニタリングシステムのコンポーネント
まず、Alibaba Cloud Container Serviceの監視システムを見てみましょう。この図は、監視システムの全体的なアーキテクチャを示しています。
右の4つの製品は、モニタリングやロギングサービスと密接に関連しています。
SLS
SLSは、ログサービスです。前述したように、ログはKubernetes内の収集場所に応じて異なる方法で収集されます。例えば、コアコンポーネントのログ、アクセスレイヤーのログ、アプリケーションのログはそれぞれ異なる形で収集され、同様に、Alibaba Cloud Container Serviceでは、監査ログはAPIサーバーから、アクセス層のログはサービスメッシュやingress controllerから、アプリケーションのログはアプリケーション層から収集することができます。
しかし、このデータリンクは我々の要求を満たすには不十分です。データをキャッシュするだけではなく、上位層のデータを表示したり、分析したりする必要があります。SLSはその要求を完璧に満たしてくれます。例えば、監査ログでは、今日の操作回数、変更回数、攻撃回数、システム例外の発生の有無などを確認することができます。これらの結果は、すべて監査ダッシュボードで確認できます。
ARMS
本製品は、アプリケーションのパフォーマンス監視に関する製品です。ARMS(Application Real-Time Monitoring Service)などの製品でパフォーマンス監視を行うことができます。現在、ARMSはJavaとPHPの言語に対応しており、アプリケーションのパフォーマンスを診断・チューニングすることができます。
AHAS
AHAS(Application High Availability Service)という製品は特別です。AHASは、アーキテクチャの自動発見機能を持つシステムです。ご存知のように、Kubernetesのコンポーネントは通常、マイクロサービスアーキテクチャに従って展開されます。マイクロサービスアーキテクチャでは、コンポーネントやコンポーネントレプリカの数が増えていきます。そのため、トポロジー管理が複雑になります。
実際、十分な可視性がなければ、Kubernetesにおけるアプリケーションのトラフィックフローを見たり、トラフィックの例外をトラブルシューティングしたりすることは困難です。AHASは、ネットワークスタックを監視することで、Kubernetesにおけるアプリケーションのトポロジー全体を提示するように設計されています。トポロジーに基づいて、AHASはリソース、ネットワーク帯域、トラフィックを監視し、例外イベントを診断します。また、AHASは、発見されたアーキテクチャトポロジーに基づいて、別のモニタリングソリューションを実装することができます。
クラウドモニター
クラウドモニターは、基本的なクラウド監視機能を実装しています。標準的なリソースメトリクスを収集し、モニタリングデータを表示します。また、ノードやポッドなどのコンポーネントのメトリクスを表示し、アラートを出すことができます。
Alibaba Cloudで強化された機能
このセクションでは、Alibaba Cloudが行ったオープンソースの機能強化について説明します。まず、冒頭で述べたように、metrics-serverは大幅に効率化されています。しかし、お客様から見ると、この合理化は一部の機能を切り捨てることで実現されているため、多くの不便さがあります。例えば、多くのお客様はモニタリングデータをSLSやInfluxDBなどのシンクにキャッシュしたいと考えています。しかし、この機能はコミュニティ版では利用できなくなっています。この問題を解決するために、Alibaba Cloudは頻繁にメンテナンスされる共通のシンクを保持しています。これが最初の強化点です。
2つ目は、全体的な互換性の向上です。ご存知の通り、Kubernetesに統合されたエコシステムは同期して進化しません。例えば、ダッシュボードのリリースは、Kubernetesのメジャーバージョンと一致しません。具体的には、Kubernetes 1.12がリリースされると、ダッシュボードも同期してバージョン1.12にアップグレードされるのではなく、独自のペースでリリースされます。その結果、Heapsterに依存している多くのコンポーネントが、Heapsterがmetrics-serverにアップグレードされた直後に壊れてしまいます。この問題を防ぐために、Alibaba Cloudはmetrics-serverがHeapsterと完全な互換性を持つようにしています。現在のKubernetes 1.7バージョンからKubernetes 1.14では、Alibaba Cloudのmetrics-serverは、すべての監視コンポーネントのデータ消費量に対応しています。
また、Kube-eventerとノード問題検出器（NPD）も強化しました。Kube-eventerコンポーネントの強化については以前に説明しました。NPDについては、カーネルハングアップ、ノード問題、ソースネットワークアドレス変換（SNAT）の検出や、インバウンドおよびアウトバウンドトラフィックの監視など、多くの監視・検出指標を追加しました。また、FDなどのその他のチェック項目もNPDのもので、Alibaba Cloudでも大きく強化されています。これらの機能強化により、開発者はNPDのチェック項目を直接導入し、ノード診断に基づいてアラートを生成し、Kube-eventerを介してKafkaやDingTalkにアラートをキャッシュすることができます。
また、上位層のPrometheusエコシステムも強化されています。ストレージレイヤーでは、開発者がAlibaba CloudのHiTSDBやInfluxDBに接続できるようになり、コレクションレイヤーでは、最適化されたノードエクスポーターコンポーネントと、Spark、TensorFlow、Argoなどのいくつかのシナリオベースのモニタリングエクスポーターが提供されます。また、Alibaba Cloudでは、単一のGPUの監視やGPU共有の監視など、GPUに関する多くの追加機能を提供しています。
Prometheusについては、ARMSチームと提携して、Prometheusのホスト版を立ち上げました。開発者は、Prometheusサーバーをデプロイすることなく、すぐに使えるヘルムチャットを使うことで、Prometheusの監視・収集機能に直接アクセスできるようになります。
Alibaba Cloud Container Serviceのロギングシステム
Alibaba Cloudはロギングシステムにどのような改良を加えたのでしょうか。まず、収集方法があらゆる種類のログに完全対応しています。ポッド、コアコンポーネント、Dockerエンジン、カーネル、そして一部のミドルウェアのログはすべてSLSに収集されます。そして、これらのログはSLSからObject Storage Service（OSS）にキャッシュされてアーカイブされ、MaxComputeにキャッシュバジェットされます。
さらに、OpenSearch、E-Map、Flinkによって、ログを検索し、上位層のデータをリアルタイムに消費することができます。ログを表示するには、オープンソースのGrafanaや、DataVなどのサービスに接続します。このようにして、完全なデータ収集と消費の連携が成立します。
結論
本記事では、まず監視サービスについて、4つのコンテナシナリオにおける共通の監視方法、Kubernetesにおける監視の進化とAPIの標準化、共通のデータソースに対する2つの監視ソリューションを紹介しました。次に、4つのロギングシナリオとFluentdと呼ばれる収集ソリューションについて説明し、最後に、Alibaba Cloudにおけるロギングとモニタリングのベストプラクティスを挙げています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ