TAG（タグ）のGuanceにおけるベストプラクティス¶

この記事はあくまで参考例であり、皆さんがこれを基に想像力を発揮して、独自のタグの使い方を生み出していただくことを期待しています。

はじめに¶

OpenTelemetry プロトコルは、CNCF（Cloud Native Computing Foundation） が定義する最新世代の可観測性の標準仕様（現在もインキュベーション中）であり、可観測性の三本柱である metrics、trace、log（メトリクス、トレース、ログ） を定義しています。しかし、単にこれら三本柱のデータを収集するだけで、関連付けを行わなければ、いわゆる可観測性は従来の監視ツール（APM、ログ、Zabbix など）と何ら変わりません。単なる監視ツールの集合に過ぎないのでしょうか？ここで重要な概念が登場します。それが TAG（タグ） です。例えば、フロントエンドとバックエンドで共通の traceID も一種のタグと見なせますし、メトリクス・トレース・ログを初歩的に関連付けるホストもタグと見なせます。それ以外にも、プロジェクト、環境、バージョン番号など、すべてがタグです。
つまり、TAG によってデータの関連付けと、より多くのカスタマイズ可能な可観測性の活用が可能になります。Guanceの現在のアーキテクチャでは、すべての可観測項目がタグの設定をサポートしており、理論上タグの数に上限はありません。

例えるなら、日常生活でよくある就職活動や採用担当者の募集です。採用には具体的な要件があります。例えば、XX のポジションにはプログラミングスキル、コンピュータの基礎知識、学士号、XX 年の実務経験などが必要です。これらの要件はタグのようなものです。タグを満たした人だけがそのポジションを得られる可能性があります。IT システムで言えば、XX サーバー上で XX アプリケーション、XX データベース、XX Nginx が動作しており、環境は XX 環境、担当者は XXX という具合です。問題が発生した場合、タグが十分にあれば、どのサーバーに問題があるのか、具体的にどのビジネスやアプリケーションコンポーネントに影響があるのか、誰がそのコンポーネントを担当しているのかを迅速に特定できます。その結果、適切な担当者を素早く見つけて修復・対応を行い、問題解決の効率を向上させることができます。

この記事では、Guanceを利用して、4 つの例を通じてタグの拡張性と可能性を検証します。

実験 1：サーバーをグループ化する¶

背景：企業内には複数のプロジェクトチームや事業部が存在することが多く、各チームや事業部は独自の業務開発を行う際に、専用のインフラストラクチャを使用することがあります。インフラからアプリケーションまで全てGuanceに接続して可観測性を実現する場合、ワークスペースを分割する以外にも、プロジェクトリソースを区別する方法はあるのでしょうか？
もちろんあります。Guanceは設計当初からこの状況を想定しており、デフォルトの DataKit メイン設定ファイルには global_tag というタグがあります。このタグはインフラストラクチャレベルでタグを設定するもので、そのインフラ上の他のコンポーネント（アプリケーションやデータベースなど）も自動的にこのタグを継承します。

1 datakit-inputs を編集し、global_tag を設定する¶

$ vim /usr/local/datakit/conf.d/datakit.conf

# global_tags にタグを追加します。デフォルトの 3 つ以外に、他のタグも追加できます。

$ [global_tags]
$  cluster = ""
$  project = "solution"
$  site = ""

同様に、関連するすべてのホストの DataKit にこのタグを追加します。

2 Guanceでサーバーのグループを確認する¶

実験 2：datakit が認識する hostname を変更する¶

背景：DataKit はデフォルトでホストレベルの hostname を収集し、その hostname をグローバルタグとして使用して、すべてのメトリクス、トレース、ログ、オブジェクトなどのデータを関連付けます。しかし、多くの企業の実際の環境では、hostname はルールのない単なる文字列であり、実質的な意味を持ちません。また、hostname はアプリケーションや管理データベースなどへの接続に使用されている可能性があるため、hostname を変更（識別可能な文字列に変更）することのリスクを評価できず、変更を望まないケースが多くあります。このようなリスクを回避するために、datakit には ENV_HOSTNAME が組み込まれており、このような状況に対応できます。

Warning

注意：この方法を適用すると、新しい hostname を持つホストのデータは新たにアップロードされ、元の hostname のホストデータは更新されなくなります。
推奨：hostname を変更する必要がある場合は、datakit の初回インストール時に変更することをお勧めします。

1 datakit-inputs を編集し、[environments] を設定する¶

$ vim /usr/local/datakit/conf.d/datakit.conf

# [environments] で ENV_HOSTNAME を変更し、識別しやすい hostname にします。

[environments]
  ENV_HOSTNAME = "118.178.57.79"

2 Guanceで変更前後のデータを比較する¶

実験 3：Nginx ログをサービス別に統計してデータを表示する¶

背景：企業内の nginx は通常、ドメイン名の転送やサービスの転送を担っており、多くの場合、nginx が対応するドメイン名はフロントエンドのリクエストをバックエンドの複数の異なるサブドメインや異なるポートのサービスに転送します。また、nginx が複数のドメイン名サービスを直接受け持つこともあります。このような状況では、統一的な nginx 監視では対応できません。Guanceはどのようにこの問題を解決するのでしょうか？

シナリオ：nginx は外部に 18889 と 80 のポートを公開し、それぞれ内部サーバー 118.178.57.79 の 8999 ポートと 18999 ポートに転送します。

要件：nginx の 18889 ポートと 80 ポートの各サービスに対応するデータ（PV、UV、リクエストエラー数など）をそれぞれ統計します。

前提条件：nginx の 80 および 18889 のアクセスログは、それぞれ異なるディレクトリ（または異なるログファイル名）に設定されている必要があります。

80 ポートのログディレクトリ	/var/log/nginx/80/
18889 ポートのログディレクトリ	/var/log/nginx/18999/

1 Nginx 自身のメトリクス監視を設定する¶

詳細な設定は統合ドキュメント <Nginx> を参照してください。

1、 nginx.conf の自身のパフォーマンスメトリクス統計モジュールを有効にする

nginx の http_stub_status_module モジュールが有効になっているか確認します。

（この例では有効になっています）

2、 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;
                             }

          }

3、 nginx -s reload を実行して nginx をリロードします

4、 Datakit で nginx.inputs を有効にします

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

5、以下のように修正します

[[inputs.nginx]]
    url = http://localhost/nginx_status

6、 nginx.conf ファイルを保存した後、DataKit を再起動します

$ service datakit restart

2 80 ポートと 18889 ポートのサービスに対応するログ監視をそれぞれ設定する¶

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

$ vim nginx80.conf

## ログパスを正しいアプリケーションログのパスに変更します
## source 、service 、pipeline は必須フィールドです。アプリケーション名を直接使用して、異なるログ名を区別できます
## タグ domainname を追加します

## 以下のように修正します：
[[inputs.logging]]

  logfiles = ["/var/log/nginx/80/access.log","/var/log/nginx/80/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:80"

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

## ログパスを正しいアプリケーションログのパスに変更します
## source 、service 、pipeline は必須フィールドです。アプリケーション名を直接使用して、異なるログ名を区別できます
## タグ domainname を追加します

## 以下のように修正します：
[[inputs.logging]]

  logfiles = ["/var/log/nginx/18889/access.log","/var/log/nginx/18889/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:18889"

3 カスタムビューを設定する（タグでドメイン名を区別する）¶

手順：Guanceにログイン - 「シーン」 - 「新しいシーンを作成」 - 「新しい空白のシーンを作成」 - 「システムビュー」（NGINX を作成）

ポイント：システムテンプレート上で nginx ビューの関連設定を変更します

1、ビューの編集状態に入り、「ビュー変数を編集」 - 「ビュー変数を追加」をクリックします

L::nginx:(distinct(`domainname`)){host='#{host}'}

意味の説明： nginx メトリクスの host を継承し、L（ログ）で nginx ログ内の異なる domainname をクエリします

2、具体的なビューのパラメータを変更します

4 Guanceでサービス別データを表示する¶

同様に、異なるタグを付与することで、異なるプロジェクト、異なる担当者、異なるビジネスモジュール、異なる環境などを区別できます。タグの具体的な能力は、あなたの想像力次第です。

実験 4：タグでサービスの具体的なオーナーを特定し、アラート通知を行う¶

背景：企業のビジネスが発展するにつれて、マイクロサービスやコンテナが広く利用され、サービスコンポーネントが増加し、それに伴って開発者や運用担当者も増え、各人の役割分担も細分化されています。ビジネスシステムや IT システムに障害が発生した場合、最適なアラートプラクティスは、関連する担当者を直接指定してアラートを送信し、アラートのクローズ効率を向上させることです。この方法の一般的な実装としては、アラートを関連担当者にのみ送信するか、Jira でチケットを割り当てる方法があります。Guanceではどのように操作するのでしょうか？Guanceでは、該当する可観測 inputs にタグを追加するだけです（理論上、タグの数に上限はありません）。例えば、nginx-inputs にカスタムタグ owner = "xxx" を追加し、異常検知で owner を変数として設定すると、異常検知が自動的にそのフィールドを認識し、DingTalk や WeCom グループに送信します。効果は以下の通りです。

例えば、上記の nginx カスタムログに追加する場合：

TAG（タグ）のGuanceにおけるベストプラクティス¶

はじめに¶

実験 1：サーバーをグループ化する¶

1 datakit-inputs を編集し、global_tag を設定する¶

2 Guanceでサーバーのグループを確認する¶

実験 2：datakit が認識する hostname を変更する¶

1 datakit-inputs を編集し、[environments] を設定する¶

2 Guanceで変更前後のデータを比較する¶

実験 3：Nginx ログをサービス別に統計してデータを表示する¶

1 Nginx 自身のメトリクス監視を設定する¶

2 80 ポートと 18889 ポートのサービスに対応するログ監視をそれぞれ設定する¶

3 カスタムビューを設定する（タグでドメイン名を区別する）¶

4 Guanceでサービス別データを表示する¶

実験 4：タグでサービスの具体的なオーナーを特定し、アラート通知を行う¶

1 inputs にタグを追加する¶

2 異常検知を設定する¶

3 アラートをトリガーし、アラートイベントを確認する¶

このページは役に立ちましたか？

TAG（タグ）のGuanceにおけるベストプラクティス¶

はじめに¶

実験 1：サーバーをグループ化する¶

1 datakit-inputs を編集し、global_tag を設定する¶

2 Guanceでサーバーのグループを確認する¶

実験 2：datakit が認識する hostname を変更する¶

1 datakit-inputs を編集し、[environments] を設定する¶

2 Guanceで変更前後のデータを比較する¶

実験 3：Nginx ログをサービス別に統計してデータを表示する¶

1 Nginx 自身のメトリクス監視を設定する¶

2 80 ポートと 18889 ポートのサービスに対応するログ監視をそれぞれ設定する¶

3 カスタムビューを設定する（タグでドメイン名を区別する）¶

4 Guanceでサービス別データを表示する¶

実験 4：タグでサービスの具体的なオーナーを特定し、アラート通知を行う¶

1 inputs にタグを追加する¶

2 異常検知を設定する¶

3 アラートをトリガーし、アラートイベントを確認する¶

このページは役に立ちましたか？ ×

このページは役に立ちましたか？