0 から 1 で Guance を活用して Spring Cloud サービスの可観測性を構築する¶

本プロジェクトの業務システム概要：¶

本ケースでは、社内業務システムを模擬したシステムを採用し、0 から 1 で Guance を活用してシステムの可観測性を構築します。

今回の可観測性構築では、スタンドアロンの jar パッケージ版アプリケーションを選択しています。

プロジェクトのオープンソースアドレス：https://gitee.com/y_project/RuoYi-Cloud

プロジェクトのデモアドレス：http://demo.ruoyi.vip/login

システム概要：

このシステムは、オープンソースのバックエンド管理システムであり、Java EE エンタープライズ向けの高速開発プラットフォームでもあります。多くの古典的な技術（Spring Boot、Apache Shiro、MyBatis、Thymeleaf、Bootstrap など）を組み合わせています。 内蔵モジュールは多数あり、例：部門管理、ロール・ユーザー、メニュー及びボタン権限、データ権限、システムパラメータ、ログ管理、通知・お知らせなど、主な目的は開発者が業務に集中できるようにし、技術的な難易度を下げ、人件費を削減し、プロジェクト期間を短縮し、ソフトウェアのセキュリティ品質を向上させることです。 このプロジェクトは、すべてのWebアプリケーション（Webサイト管理バックエンド、Webサイト会員センター、CMS、CRM、OAなど）に使用でき、カスタムの深いカスタマイズもサポートしているため、企業はより強力なシステムを構築できます。すべてのフロントエンド・バックエンドコードはカプセル化されており、非常に簡潔で使いやすく、エラー発生率が低くなっています。 また、モバイルクライアントからのアクセスもサポートしています。

プロジェクトの機能モジュール：

• ユーザー管理：ユーザーはシステム操作者です。この機能は主にシステムユーザーの設定を行います。
• 部門管理：システム組織構成（会社、部門、グループ）を設定し、ツリー構造で表示し、データ権限をサポートします。
• 役職管理：システムユーザーの所属する役職を設定します。
• メニュー管理：システムメニュー、操作権限、ボタン権限識別子などを設定します。
• ロール管理：ロールメニュー権限の割り当て、ロールに機関ごとのデータ範囲権限の区分を設定します。
• 辞書管理：システムでよく使用される固定データを管理します。
• パラメータ管理：システムの動的に設定される一般的なパラメータを管理します。
• 通知・お知らせ：システムの通知・お知らせ情報の公開と管理を行います。
• 操作ログ：システムの正常な操作ログの記録と照会、システムの異常情報ログの記録と照会を行います。
• ログインログ：システムのログインログの記録・照会（ログイン異常を含む）を行います。
• オンラインユーザー：現在のシステム内のアクティブユーザーの状態監視を行います。
• 定期タスク：オンラインでの（追加、変更、削除）タスクスケジューリングと実行結果ログを含みます。
• コード生成：フロントエンド・バックエンドコードの生成（java、html、xml、sql）をサポートし、CRUD ダウンロードをサポートします。
• システムインターフェース：業務コードに基づいて関連するAPIインターフェースドキュメントを自動生成します。
• サービス監視：現在のシステムの CPU、メモリ、ディスク、スタックなどの関連情報を監視します。
• キャッシュ監視：システムのキャッシュの照会、表示、クリアなどの操作を行います。
• オンラインビルダー：フォーム要素をドラッグして対応する HTML コードを生成します。

業務システムで使用されている技術スタック：

業務システムのアーキテクチャ：

• Web ページ：Nginx に配置
• レジストリ：Nacos
• ゲートウェイ：Gateway
• サービスモジュール：Auth、System
• データベース：Mysql
• キャッシュ：Redis

注：このデモでは、すべてのサービスモジュールを同一サーバーにデプロイし、異なるポートを使用してサービスにアクセスします。

Guance の概要：¶

概要：[Guance 公式概要]

Guance は、クラウドコンピューティングおよびクラウドネイティブ時代において、すべての完全なアプリケーションに対してフルリンクの可観測性を構築することを目指したクラウドサービスプラットフォームであり、従来の監視システムとは本質的に異なります。

従来の監視システムは、多くの場合、単一領域の監視システムであり、企業内に構築された多くのサイロ（APM、RUM、ログ、NPM、zabbix など）のようなもので、それぞれが単一かつ分断された監視システム（アプリケーション用、ログ用、インフラストラクチャ用など）です。その結果、サイロが林立し、監視システムの分断は監視データの分断も招き、企業内のデータサイロを引き起こします。企業内で問題を調査する際には、通常、部門をまたぎ、プラットフォームをまたいで、多くの人的・物的リソースを費やして異常を特定する必要があります。

一方、可観測性の概念は、統一されたシステムを通じて、業務システムを支える IT システムを可観測にするものです。これには、メトリクス、ログ、分散型トレーシングの3つの主要コンポーネントが含まれ、統一データ収集、統一ストレージ、統一クエリ、統一表示を実現し、メトリクス、トレース、ログのすべての可観測データを関連付けて、IT システム全体の完全な可観測性を実現します。

Guance は、この概念に基づいて開発された可観測性ソリューションであり、企業内の IT サービスの品質向上とエンドユーザーエクスペリエンスの向上に貢献します。

Guance のデータフロー：

注：DQL は dataflux が特別に開発した QL 言語であり、es および influxdb のデータの関連クエリに使用します。

Datakit のインストール：¶

1. console.guance.com にログインします。
2. 新しいワークスペースを作成します。
3. インテグレーション → datakit を選択し、ご自身の環境に適したインストールコマンドを選択してコピーします。
4. サーバーに datakit をインストールします。
5. service datakit status（または systemctl status datakit）を実行して datakit の状態を確認します。

Datakit のインストールが完了すると、デフォルトで以下の内容が収集されます。Dataflux → インフラストラクチャ → ホストで直接関連データを確認できます。

異なるインテグレーション inputs 名を選択すると、対応する監視ビューを表示できます。監視ビューの下では、ログ、プロセス、コンテナなどの他のデータも表示できます。

特定の inputs を有効にする：¶

注：

Nginx：¶

詳細な手順はドキュメント <Nginx 可観測性のベストプラクティス> を参照してください。
前提条件：まず nginx の http_stub_status_module モジュールが有効になっているか確認してください。モジュールが既にインストールされている場合は、手順1をスキップしてください。

1. with-http_stub_status_module モジュールをインストールします（Linux）： このモジュールを有効にするには、nginx を再コンパイルする必要があります。具体的なコマンドは以下の通りです。 ./configure --with-http_stub_status_module configure ファイルの場所を確認する方法： find /| grep configure |grep nginx

$ find /| grep configure |grep nginx

$ cd /usr/local/src/nginx-1.20.0/
$ ./configure --with-http_stub_status_module

1. Nginx.conf に nginx_status の location 転送を追加します。

$ cd /etc/nginx   
   ## nginx パスは実際の状況に応じてください
$ vim nginx.conf

$  server{
     listen 80;   
     server_name localhost;
     ##ポートはカスタマイズ可能

      location /nginx_status {
          stub_status  on;
          allow 127.0.0.1;
          deny all;
                           }

        }

1. Datakit で nginx の inputs を変更します。

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim  nginx.conf

#以下の内容を変更します
[[inputs.nginx]]
        url = http://localhost/nginx_status
[inputs.nginx.log]
        files = ["/var/log/nginx/access.log","/var/log/nginx /error.log"]

#ファイルを保存した後、datakit を再起動します    
$ service datakit restart

データの確認：curl 127.0.0.1/nginx_status

1. Guance プラットフォームで Nginx ビューを作成し、データを確認します。 作成手順は[シナリオとビューの作成] を参照してください。 手順：シナリオ → 新規シナリオ → 新規空白シナリオ → システムビュー（Nginx を作成） ビュー例（このビューを使用すると、Nginx 関連のメトリクスとログ情報を迅速に確認でき、Nginx の健全性を判断できます）:

Mysql：¶

詳細な手順はドキュメント <Mysql DataKit インテグレーション> を参照してください。

# mysql にログインします
$ mysql -uroot -p  
# パスワードを入力：Solution****

# 監視アカウントを作成します
$ CREATE USER 'datakit'@'localhost' IDENTIFIED BY 'Datakit_1234';

# 監視アカウントに権限を付与します
$ grant process,select,replication client on *.* to 'datakit'@'%' identified by 'Datakit_1234';

# 権限をリフレッシュします
flush privileges;

1、Datakit で mysql の inputs を変更します。¶

$ cd /usr/local/datakit/conf.d/db/
$ cp mysql.conf.sample mysql.conf
$ vim mysql.conf

# 以下の内容を変更します
## mysql の読み取り専用アカウントをカスタム作成することを推奨します
[[inputs.mysql]]
     user ="datakit"
     pass ="Datakit_1234“

#ファイルを保存した後、datakit を再起動します    
$ service datakit restart

2、Guance プラットフォームで Mysql ビューを作成し、データを確認します。¶

作成手順は[シナリオとビューの作成] を参照してください。 手順：シナリオ → 新規シナリオ → 新規空白シナリオ → システムビュー（Mysql を作成） ビュー例（このビューを使用すると、Mysql 関連のメトリクスとログ情報を迅速に確認でき、Mysql の健全性を判断できます）:

Redis：¶

詳細な手順はドキュメント <Redis DataKit インテグレーション> を参照してください。

1、Datakit で redis の inputs を変更します。¶

$ cd /usr/local/datakit/conf.d/db/
$ cp redis.conf.sample redis.conf
$ vim redis.conf

#以下の内容を変更します
## redis の読み取り専用アカウントをカスタム作成することを推奨します
[[inputs.redis]]
     pass ="Solution******“
#pass の前のコメント記号 # を外してください
[inputs.redis.log]
    files = ["/var/log/redis/redis.log"]

#ファイルを保存した後、datakit を再起動します    
$ service datakit restart

2、Guance プラットフォームで Redis ビューを作成し、データを確認します。¶

作成手順は[シナリオとビューの作成] を参照してください。 手順：シナリオ → 新規シナリオ → 新規空白シナリオ → システムビュー（Redis を作成） ビュー例（このビューを使用すると、Redis 関連のメトリクスとログ情報を迅速に確認でき、Redis の健全性を判断できます）:

JVM：¶

詳細な手順はドキュメント <jvm DataKit インテグレーション> を参照してください。

1、Datakit で jvm の inputs を変更します。¶

デフォルトでは jvm の inputs を変更する必要はありません。conf ファイルをコピーして生成するだけで済みます。

$ cd /usr/local/datakit/conf.d/statsd/
$ cp statsd.conf.sample ddtrace-jvm-statsd.conf 
$ vim ddtrace-jvm-statsd.conf

# デフォルトでは変更不要

2、Java アプリケーションの起動スクリプトを変更します。¶

### JVM は APM と同様に ddtrace-agent を介してデータ収集を実装するため、アプリケーション起動スクリプトは APM 関連の内容 [APM] を参照してください。 ###

3、Guance プラットフォームで JVM ビューを作成し、データを確認します。¶

作成手順は[シナリオとビューの作成] を参照してください。 手順：シナリオ → 新規シナリオ → 新規空白シナリオ → システムビュー（JVM を作成） ビュー例（このビューを使用すると、JVM 関連のメトリクスとログ情報を迅速に確認でき、JVM の健全性を判断できます）:

APM（アプリケーションパフォーマンスモニタリング（APM））：¶

詳細な手順はドキュメント 分散型トレーシング（APM）のベストプラクティス を参照してください。 Guance がサポートする APM インテグレーション方式には、ddtrace、skywalking、zipkin、jaeger など、opentracing プロトコルをサポートする複数の APM ツールが含まれます。本例では ddtrace を使用して APM の可観測性を実現します。

1、Datakit で APM（ddtrace）の inputs を変更します。¶

デフォルトでは jvm の inputs を変更する必要はありません。conf ファイルをコピーして生成するだけで済みます。

$ cd /usr/local/datakit/conf.d/ddtrace/
$ cp ddtrace.conf.sample ddtrace.conf
$ vim ddtrace.conf

# デフォルトでは変更不要

2、Java アプリケーションの起動スクリプトを変更します。¶

APM の可観測性を実現するには、Java アプリケーションに agent を追加する必要があります。この agent はアプリケーションの起動時に、バイトコードインジェクション技術を使用して、アプリケーション内部のメソッド呼び出し、SQL 呼び出し、外部システム呼び出しなどの関連パフォーマンスデータを収集し、アプリケーションシステムのコード品質の可観測性を実現します。

#元のアプリケーション起動スクリプト
$ cd /usr/local/ruoyi/
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-gateway.jar > logs/gateway.log  2>&1 & 
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-auth.jar > logs/auth.log  2>&1 & 
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-modules-system.jar > logs/system.log  2>&1 &

元のアプリケーションの起動プロセスを kill し、ddtrace パラメータを追加した後、アプリケーションを再起動する必要があります。具体的な停止・強制終了方法は以下の図を参照してください。

# ddtrace-agent を追加した後のアプリケーション起動スクリプト

$ cd /usr/local/ruoyi/

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-gateway -Ddd.service.mapping=redis:redis_ruoyi -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000  -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-gateway.jar > logs/gateway.log  2>&1 &

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar  -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-auth -Ddd.service.mapping=redis:redis_ruoyi -Ddd.env=staging -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000 -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-auth.jar > logs/auth.log  2>&1 & 

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-modules-system -Ddd.service.mapping=redis:redis_ruoyi,mysql:mysql_ruoyi -Ddd.env=dev -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000 -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-modules-system.jar > logs/system.log  2>&1 & 

！Guance プラットフォームで APM 関連データが表示されない場合は、datakit のログを確認してください。 cat /var/log/datakit/gin.log 正常なログ：

エラーログ：

この種のエラーは、 /usr/local/datakit/con.d/ddtrace/ddtrace.conf を以下の画像のように変更する必要があります。 ddtrace.conf 設定の path パスが datakit/gin.log ログのパスと一致していることを確認してください。

ddtrace 関連の環境変数（起動パラメータ）の説明：

• Ddd.env：カスタム環境タイプ。オプション項目です。
• Ddd.tags：カスタムアプリケーションタグ。オプション項目です。
• Ddd.service.name：カスタムアプリケーション名。必須項目です。
• Ddd.agent.port：データアップロードポート（デフォルトは9529）。必須項目です。
• Ddd.version：アプリケーションバージョン。オプション項目です。
• Ddd.trace.sample.rate：サンプリングレートの設定（デフォルトは全サンプリング）。オプション項目です。サンプリングが必要な場合は、0〜1の間の数値（例：0.6は60%サンプリング）を設定できます。
• Ddd.service.mapping：現在のアプリケーションが呼び出す redis、mysql などに、このパラメータを使用してエイリアスを追加し、他のアプリケーションが呼び出す redis、mysql と区別できます。オプション項目です。使用例：プロジェクトAとプロジェクトBが両方とも mysql を呼び出し、それぞれ mysql-a、mysql-b を呼び出している場合、mapping 設定項目を追加しないと、Guance プラットフォーム上ではプロジェクトAとプロジェクトBが同じ名前の mysql データベースを呼び出しているように表示されます。mapping 設定項目を追加し、mysql-a、mysql-b と設定すると、Guance プラットフォーム上ではプロジェクトAが mysql-a を呼び出し、プロジェクトBが mysql-b を呼び出しているように表示されます。
• Ddd.agent.host：データ転送先 IP。デフォルトはローカルホスト localhost。オプション項目です。

3、Guance プラットフォームで APM データを確認します。¶

APM（アプリケーションパフォーマンスモニタリング（APM））は Guance のデフォルトの内蔵モジュールであり、シナリオやビューを作成しなくても確認できます。 パス：Guance プラットフォーム → アプリケーションパフォーマンスモニタリング（APM） ビュー例:（このビューを使用すると、アプリケーション呼び出し状況、トポロジービュー、異常データなどの APM 関連データを迅速に確認できます）

RUM（リアルユーザーモニタリング（RUM））：¶

詳細な手順はドキュメント [ユーザーアクセス（RUM）可観測性のベストプラクティス] を参照してください。

1、Dataflux プラットフォームにログインします。¶

2、ユーザーアクセス監視 → アプリケーションの新規作成 → Web タイプを選択 → 同期読み込みを選択します。¶

3、フロントエンドページの index.html に Guance RUM 可観測性 JS ファイルを組み込みます。¶

$ cd /usr/local/ruoyi/dist/

// バックアップを忘れずに
$ cp index.html index.html.bkd

// index.html に df-js を追加します
// DF プラットフォーム上の JS の内容をコピーし、index.html の </head> の前に配置し、ファイルを保存します。例は以下の通りです。

$ vim index.html

<script src="https://static.guance.com/browser-sdk/v2/dataflux-rum.js" type="text/javascript"></script>
<script>
  window.DATAFLUX_RUM &&
    window.DATAFLUX_RUM.init({
      applicationId: 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
      datakitOrigin: 'xxx.xxx.xxx.xxx:9529',
      env: 'test',
      version: '1.0.0',
      trackInteractions: true,
      allowedTracingOrigins:["xxx.xxx.xxx.xxx"]
      })
</script></head> 

# xxx はすべて実際の状況に応じて変更する必要があります。詳細な変更内容は以下を参照してください。

datakitOrigin：datakit アドレス（datakit が存在するサーバーの IP またはドメイン名）。Guance における RUM データフローは、rum.js ファイル → datakit → dataway → Guance プラットフォーム です。本番環境の場合は、この IP をドメイン名または SLB アドレスに設定する必要があります。テスト環境の場合は、datakit サーバーの 9529 ポートに対応するプライベート IP を入力する必要があります。

trackInteractions：ユーザー行動収集設定項目。ページ上のユーザー操作行動の統計を実現します。

allowedTracingOrigins：フロントエンドとバックエンド（RUM と APM）を連携させるための設定項目です。必要に応じて設定できます。ここには、フロントエンドページとインタラクションのあるバックエンドサーバーに対応するドメイン名または IP を入力する必要があります。

注意事項：

• datakitOrigin：データ転送アドレス。本番環境でドメイン名を設定する場合、ドメイン名のリクエストを datakit-9529 ポートがインストールされた任意のサーバーに転送できます。フロントエンドのアクセス量が多すぎる場合は、ドメイン名と datakit サーバーの間に SLB レイヤーを追加できます。フロントエンド JS はデータを SLB に送信し、SLB も 9529 ポートを開放する必要があります。SLB はリクエストを複数の datakit-9529 がインストールされたサーバーに転送します。複数の datakit が RUM データを引き受けます。フロントエンドリクエストの再利用要因により、セッションデータは中断されず、RUM データ表示にも影響しません。

例：

• allowedTracingOrigins：フロントエンドとバックエンド（APM と RUM）の連携を実現します。このシナリオは、フロントエンドに RUM、バックエンドに APM をデプロイしている場合にのみ有効です。ここには、フロントエンドページとインタラクションのあるバックエンドアプリケーションサーバーに対応するドメイン名（本番環境）または IP（テスト環境）を入力する必要があります。使用例：フロントエンドユーザーのアクセスが遅い場合、その原因がバックエンドコードのロジック異常にある可能性があります。フロントエンド RUM の遅延リクエストデータから直接 APM データにジャンプして、その時点のバックエンドコード呼び出し状況を確認し、遅延の根本原因を特定できます。実装原理：ユーザーがフロントエンドアプリケーションにアクセスし、フロントエンドアプリケーションがリソースとリクエストを呼び出すと、rum-js がパフォーマンスデータ収集をトリガーします。rum-js は trace-id を生成し、リクエストの request_header に書き込みます。リクエストがバックエンドに到達すると、バックエンドの ddtrace がこの trace_id を読み取り、自身のトレースデータに記録します。これにより、同じ trace_id を使用してアプリケーションパフォーマンスモニタリング（APM）とリアルユーザーモニタリング（RUM）のデータを連携させることができます。
• env：必須。アプリケーションが属する環境。test や product などのフィールドを指定します。
• version：必須。アプリケーションのバージョン番号。
• trackInteractions：ユーザー行動統計。例：ボタンのクリック、情報の送信などのアクション。

4、ページを保存、確認、公開します。¶

ブラウザで対象のページにアクセスし、f12 開発者ツールを使用して、ページのネットワークリクエストに RUM 関連のリクエストがあるかどうか、ステータスコードが 200 であるかどうかを確認します。

注意！！：f12 開発者ツールでデータが報告されず、ポートが refused と表示される場合は、telnet IP:9529 でポートが疎通しているか確認してください。疎通していない場合は、/usr/local/datakit/conf.d/datakit.conf を変更し、http_listen の localhost を 0.0.0.0 に変更する必要があります。

5、ユーザーアクセス監視で RUM 関連データを確認します。¶

6、RUM と APM のデータ連携デモ¶

設定方法：[Java サンプル]

使用例：フロントエンドとバックエンドの連携。フロントエンドのリクエストとバックエンドのメソッド実行パフォーマンスデータを1対1でバインドし、フロントエンドとバックエンドに関連する問題の特定を容易にします。例えば、フロントエンドユーザーのアクセスが遅い場合、その原因がバックエンドサービスの呼び出し異常にある場合、チームや部門をまたいで迅速に問題を特定できます。例は以下の通りです。

Security Checker（セキュリティチェック）：¶

Security Checker の概要：[Guance 公式概要]

注意：現在は Linux のみをサポートしています。 詳細な手順はドキュメント [Security Checker のインストールと設定] を参照してください。

1、Security Checker をインストールします。¶

##  インストール
$ bash -c "$(curl https://static.guance.com/security-checker/install.sh)"
## または実行   sudo datakit --install scheck
## 更新
$ bash -c "$(curl https://static.guance.com/security-checker/install.sh) --upgrade"
## 起動・停止コマンド
$ systemctl start/stop/restart/status scheck
## または
$ service scheck start/stop/restart/status
## インストールディレクトリ  /usr/local/scheck

2、Security Checker を Datakit に接続します。¶

Security Checker のデータを datakit に送信し、その後 dataflux プラットフォームに転送します。

$ cd /usr/local/scheck/
$ vim scheck.conf


    # ##(required) directory contains script
    rule_dir='/usr/local/scheck/rules.d'

    # ##(required) output of the check result, support local file or remote http server
    # ##localfile: file:///your/file/path
    # ##remote:  http(s)://your.url
    output='http://127.0.0.1:9529/v1/write/security'


    # ##(optional)global cron, default is every 10 seconds
    #cron='*/10 * * * *'

    log='/usr/local/scheck/log'
    log_level='info'
    #disable_log=false

3、Security Checker 関連データを確認します。¶

ログ：¶

詳細な手順はドキュメント ログ収集 を参照してください。

1、標準ログ収集（Nginx、Mysql、Redis など）¶

DataKit 内蔵の各種 inputs を有効にすることで、関連するログ収集を直接開始できます。例：Nginx、Redis、コンテナ、ES など。

例：Nginx

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim nginx.conf

## ログパスを正しい nginx パスに変更します
$ [inputs.nginx.log]
$     files = ["/usr/local/nginx/logs/access.log","/usr/local/nginx/logs/error.log"]
$     pipeline = "nginx.p"

## pipeline は grok ステートメントであり、テキストログのカットに使用されます。datakit には nginx、mysql などを含む複数の pipeline が内蔵されています。pipeline のデフォルトディレクトリは /usr/local/datakit/pipeline/ です。ここで pipeline パスを変更する必要はありません。datakit はデフォルトで自動的に読み取ります。

ビュー表示：

2、カスタムログ収集（アプリケーションログ、業務ログなど）¶

例：アプリケーションログ

pipeline（ログ grok カット）[Guance 公式ドキュメント]

$ cd /usr/local/datakit/conf.d/log/
$ cp logging.conf.sample logging.conf
$ vim logging.conf

## ログパスを正しいアプリケーションログのパスに変更します

## source と service は必須フィールドです。アプリケーション名を直接使用して、異なるログ名を区別できます。

$  [inputs.nginx.log]
$    logfiles = [
      "/usr/local/ruoyi/logs/ruoyi-system/error.log",
      "/usr/local/ruoyi/logs/ruoyi-system/info.log",]
$    source = "ruoyi-system"
$    service = "ruoyi-system"
#    pipeline = "ruoyi-system.p"

## pipeline は grok ステートメントであり、テキストログのカットに使用されます。この設定を有効にしない場合、デフォルトでは DF プラットフォームにログの元のテキスト内容が表示されます。記入すると、対応するログが grok カットされます。ここで記入する .p ファイルは手動で作成する必要があります。

$ cd /usr/local/datakit/pipeline/
$ vim ruoyi_system.p

##例：
#ログ形式
#2021-06-25 14:27:51.952 [http-nio-9201-exec-7] INFO  c.r.s.c.SysUserController - [list,70] ruoyi-08-system 5430221015886118174 6503455222153372731 - ユーザーの照会

## grok 例。以下の内容を ruoyi_system.p にコピーします。

grok(_, "%{TIMESTAMP_ISO8601:time} %{NOTSPACE:thread_name} %{LOGLEVEL:level} \\s+%{NOTSPACE:class_name} - \\[%{NOTSPACE:method_name},%{NUMBER:line}\\] %{DATA:service} %{DATA:trace_id} %{DATA:span_id} - %{GREEDYDATA:msg}")

default_time(time)

ビュー表示：

Nginx ログ異常検出の作成：¶

1. Guance プラットフォーム → 異常検出ライブラリ → 新規検出ライブラリ → カスタム監視 を開きます。

2. 新しく作成した検出ライブラリ名をクリック → 新規検出ルール → 新規ログ検出 をクリックします。

3. 具体的な検出ルールの内容を記入し、保存します。 ルール名： Nginx ログ ERROR 回数が多い異常検出 検出メトリクス： 図を参照 トリガー条件： Result>=5 イベント名： Nginx ログ ERROR 回数が多い異常アラート イベント内容：

   レベル：{{status}} ホスト：{{host}} 内容：ログ ERROR 回数が多すぎます。エラー数は {{ Result }} です。 提案：ログ ERROR 回数が多い場合、アプリケーションに異常が発生している可能性があります。アプリケーションの健全性を確認することを推奨します。 検出頻度：1分

異常検出メカニズムの確認：¶

1. サーバー上で ruoyi-gateway 関連のプロセスを確認し、kill します。 2.

   $ ps -ef|grep ruoyi-gateway
   $ kill -9 xxxxx
   

1. RuoYi サイトにアクセスします（複数回リフレッシュし、少なくとも5回以上）。

1. Guance プラットフォームのイベント関連内容を確認します。

1. Nginx ログ関連内容と関連ビューを確認します。

inputs 有効化時の問題トラブルシューティング方法：¶

1. inputs のエラー情報を確認します。 Guance は、inputs の状態情報を一定の頻度で Guance プラットフォームにアップロードするようデフォルト設定されています。インフラストラクチャ → 特定のホスト内でインテグレーション状況を直接確認できます。 例：Apache サービスがダウンし、inputs にエラーが表示されます。

1. データアップロード情報を確認します。

方法1： ブラウザまたはコンソールで curl 127.0.0.1:9529/monitor を入力して確認します。 方法2： ブラウザまたはコンソールで curl 127.0.0.1:9529/stats を入力して確認します。

1. datakit のログを確認します。

datakit ログディレクトリ：cd /var/log/datakit

シナリオとビューの作成：¶

システムビューテンプレートを使用して作成する（Nginx を例に）¶

1. シナリオ → 新規シナリオ

1. 新規空白シナリオ

1. シナリオ名を入力 → 確定

1. システムビュー → Nginx ビュー（作成）

1. Nginx ビューを確認する

1. その他

他のビューの作成方法も同様です。カスタムビューの内容やレイアウトが必要な場合は、空白ビューを作成して自分で構築することもできます。

まとめ：¶

これにより、今回のデモ業務システムのトレース、メトリクス、ログ、インフラストラクチャなどに対して、全方位的な可観測性が構築されました。

Guance を全体的に試用した結果、設定が便利で管理が容易であり、統一された表示ビューも提供されます。すべてのメトリクス、トレース、ログが同じタグ（host）を介してデータの関連付けが実現され、プラットフォーム上で簡単にカスケード表示が可能になり、IT システム全体の可観測性を実現できます。

最後に、異常検出を組み合わせることで、システムの統合管理が可能になり、運用・開発の効率が向上し、IT の意思決定能力が向上します！

この製品はまだ改良を続けており、今後ますます強力で使いやすくなり、UI もより美しくなります。

Guance、可観測性の代弁者を目指します！