このドキュメントは、Cloud Logging と Cloud Monitoring を拡張してオンプレミスのインフラストラクチャとアプリを含める方法に関する、2 部構成シリーズの一つです。
- Logging（このドキュメント）: Logging でオンプレミス リソースからのロギングをサポートする方法について説明します。
- モニタリング: Monitoring でオンプレミス リソースのモニタリングをサポートする方法について説明します。
オンプレミス リソースのロギングとモニタリングに Logging と Stackdriver を使用する理由として、次のことが考えられます。
- インフラストラクチャを Google Cloud Platform（GCP）に移行する間に一時的なソリューションが必要であり、オンプレミス リソースを廃止するまでロギングとモニタリングを行う必要がある。
- 複数のクラウドとオンプレミス リソースが含まれる、多様性のあるコンピューティング環境を使用する可能性がある。
いずれの場合も、Logging API、Monitoring API、BindPlane を使用することによって、オンプレミス リソースに対する可視性を向上することができます。このドキュメントは、Google Cloud のリソースと、残存するオンプレミスのインフラストラクチャおよびアプリのリソースのロギング戦略に関心のある、DevOps の技術者、管理者、エグゼクティブを対象としています。
Logging を使用してログを取り込む
サポートされている次の 2 つの方法で API を使用して、Logging にログを取り込むことができます。
- observIQ の BindPlane を使用して、オンプレミスまたは他のクラウドソースからログを取り込む。
- アプリから直接 Cloud Logging API を使用するか、カスタム エージェントを使用する。
BindPlane を使用して Logging ログを取り込む
次の図は、BindPlane でログを取り込む仕組みと、これらのログが Logging に取り込まれる仕組みに関するアーキテクチャを示しています。
BindPlane を使用すると、ユーザーはログを収集するホストにコレクタをリモートでデプロイして管理できます。詳細については、BindPlane のアーキテクチャに関する記事をお読みください。この選択肢で必要になるのは開発ではなく構成設定であるため、デプロイに必要な工数が最小限で済みます。
メリット:
- 必要になるのは開発ではなく構成である。
- Logging の使用料金に含まれる。
- Logging のプロダクトとサポートによってサポートされる構成である。
- デフォルト構成では提供されないログを取り込むように拡張できる。
デメリット:
- サードパーティ製ツールを使用する必要がある。
- ログソースがデフォルトで提供されていない場合は、カスタム構成の指定が必要になることがあります。提供されるログのリストはソースで参照できます。
Logging API を直接使用する
次の図は、ログがインストゥルメンテーションによって収集され、Logging に取り込まれる仕組みに関するアーキテクチャを示しています。
API を直接使用する場合は、アプリケーションのインストゥルメンテーションを行い API にログを直接送信するか、API にログを送信するためのカスタム エージェントを開発する必要があります。開発作業が必要になるため、工数が高くなる選択肢です。
メリット:
- クライアント ロギング ライブラリを使用してインストゥルメンテーションを実装できるため、柔軟性が高い。
デメリット:
- カスタム エージェントなどの、インフラストラクチャ ログ用の独立したソリューションが必要になる。
- コードのインストゥルメンテーションが必要になる（結果として実装コストが高くなる可能性がある）。
- 適切な取り込みのパフォーマンスを実現するには、バッチ処理などのスケーラブルな取り込み手法を使用する必要がある。
- サポートの提供対象は Logging API のみであり、独自開発のコードはサポート対象外である。
BindPlane を使用する
このドキュメントでは、observIQ の BindPlane ツールを使用して Logging にログを取り込む方法について説明します。このソリューションは Logging の料金に含まれているため、BindPlane では開発は不要で、プロダクトでサポートされるソリューションを提供します。
エージェント、ソース、宛先
エージェント、ソース、宛先の詳細については、BindPlane のクイックスタート ガイドをご覧ください。
使用例
企業のお客様は、次のオンプレミス ロギングのシナリオで BindPlane を使用してログを取り込むことができます。
- カスタム アプリケーション ログからのログデータのカスタム解析とフィルタリング。
- Linux または Windows 仮想マシンからのオペレーティング システム イベントの収集。
- ネットワークまたは他の互換デバイスからの syslog ストリームの取り込み。
- Kubernetes のシステムログとアプリケーション ログの収集。
オンプレミスから Logging にログを送信する
BindPlane を設定してログの送信を開始すると、それらのログは Logging に送信されます。ログを表示、処理、エクスポートするには、Google Cloud コンソールに移動します。ログは、generic_node または generic_task リソースタイプとして一覧表示されます。各リソースタイプに含まれるラベルの詳細については、Logging リソースのリストをご覧ください。
Cloud Logging では、次の 2 つのリソースタイプを使用して Cloud Logging 以外のログをサポートします。
- 汎用ノード: 他のリソースタイプを適用できないマシンまたは他の計算リソースを識別します。ラベル値でノードを一意に識別する必要があります。
- 汎用タスク: カスタムのオーケストレーション システムによってスケジュールされたプロセスなど、他のリソースを適用できないアプリプロセスを識別します。ラベル値でタスクを一意に識別する必要があります。
Logging でログを表示する
Google Cloud コンソールでは、[汎用ノード] は Logging ページのリストにリソースタイプとして表示されます。
次のログは、generic_node リソースタイプとしてキャプチャされ、Logging に表示されているものです。
次のログエントリは構造化ロギング形式を使用しています。この形式では、ログのペイロードが jsonPayload として格納されるため、ログ検索用の情報が豊富な形式となっています。構造化ロギング形式では、ペイロード内のフィールドを検索の一部として使用できるため、ログにアクセスしやすくなっています。BindPlane ロギング エージェントは、元のログエントリから Logging の構造化ログへのマッピングを提供します。
まとめ
Logging で利用可能なログを使用すると、Logging の機能をフルに活用できます。ログは Google Cloud コンソールに表示されます。Logging のエクスポート機能を使用してログをエクスポートできます。また、ログベースの指標を使用することにより、Monitoring でログを使用して指標とアラートを作成できます。
次のステップ
- Logging と Monitoring
- Cloud Monitoring と Cloud Logging 向けの BindPlane の設定手順
- Logging でログベースの指標を設定する
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。