デプロイメントプラン自身のオブザーバビリティを有効にする¶

概要¶

このドキュメントの目的は、プライベートデプロイメントユーザーがデプロイメントプランに対してオブザーバビリティを実装し、Guance サービスの全体の運用信頼性を向上させることです。この記事では、2つの古典的なオブザーバビリティパターンと、Kubernetes環境で Datakit データ収集、ログとログのパース、APM、Synthetic モニタリング、RUM などをデプロイする方法について説明します。さらに、インフラストラクチャとミドルウェアの監視およびアプリケーションサービスの監視のためのワンクリックインポートテンプレートファイルを提供し、ユーザーが自身の環境をより簡単に監視できるようにします。

デプロイメントプランのオブザーバビリティパターン¶

自己観測モード1対多統一観測モード

このモードは、自分自身を監視することを意味します。つまり、自分自身のデータを自分のワークスペースに送信します。これは、環境がダウンすると、自分の情報データも監視できなくなり、さらに原因を調査できなくなることを意味します。この方式の利点は、デプロイが簡単なことです。欠点は、データが継続的に生成されるため、データの自己反復が発生し、ループが続くこと、そしてクラスターがクラッシュしたときに自身の問題を監視できないことです。

このモードは、ユーザーの複数の Guance が同じノードにデータを送信することを意味します。利点：データ転送の閉ループが発生せず、自身のクラスターの状態をリアルタイムで監視できます。

アカウント情報の準備¶

名前	タイプ	説明	作成構文（パスワードは適宜変更）	重要度
プライベート FUNC データベースアカウント	DB & USER	FUNC サービス接続アカウント	CREATE DATABASE private_func; create user 'private_func'@'%' identified by 'V4KySbFhzDkxxxx'; GRANT ALL PRIVILEGES ON private_func.* TO private_func; FLUSH PRIVILEGES;	任意
MySQL 自己観測アカウント	USER	自己観測用アカウント、MySQL メトリクス収集	CREATE USER 'datakit'@'%' IDENTIFIED BY 'SFGS&DFxxxx32!'; -- MySQL 8.0+ create the datakit user with the caching_sha2_password method CREATE USER 'datakit'@'%' IDENTIFIED WITH caching_sha2_password by 'SFGS&DFxxxx32!'; GRANT PROCESS ON . TO 'datakit'@'%'; GRANT SELECT ON . TO 'datakit'@'%'; show databases like 'performance_schema'; GRANT SELECT ON performance_schema.* TO 'datakit'@'%'; GRANT SELECT ON mysql.user TO 'datakit'@'%'; GRANT replication client on . to 'datakit'@'%';	重要
業務データ収集アカウント	USER	FUNC を使用した業務データ収集用	CREATE USER 'read'@'%' IDENTIFIED BY 'u19e0LmkL8Fxxxx'; GRANT SELECT ON df_core.* TO 'read'@'%'; FLUSH PRIVILEGES;	任意
PostgreSQL 自己観測アカウント	USER	GuanceDB 3.0 監視用	CREATE USER datakit WITH PASSWORD 'Z7ZdQ326EeexxxxP'; GRANT pg_monitor TO datakit; GRANT CONNECT ON DATABASE scopedb_meta TO datakit; GRANT SELECT ON pg_stat_database TO datakit;	任意

データ収集の設定¶

DataKit のデプロイ¶

1) datakit.yaml をダウンロード

注意

注意：上記の DataKit のデフォルトのミドルウェア設定はすべて完了しています。少し修正するだけで使用できます。

2) datakit.yaml の DaemonSet テンプレートファイルを修正

   - name: ENV_DATAWAY
     value: https://openway.guance.com?token=tkn_a624xxxxxxxxxxxxxxxxxxxxxxxx74 ## ここに DataWay の実際のアドレスを入力
   - name: ENV_GLOBAL_TAGS
     value: host=__datakit_hostname,host_ip=__datakit_ip,guance_site=guance,cluster_name_k8s=guance # ダッシュボード変数は実際の状況に応じて変更
   - name: ENV_GLOBAL_ELECTION_TAGS
     value: guance_site=guance,cluster_name_k8s=guance     # ダッシュボード変数に応じて実際の状況に合わせて変更
   image: pubrepo.guance.com/datakit/datakit:1.65.2     ## 最新のイメージバージョンに変更

3) datakit.yaml の ConfigMap 関連設定を修正

apiVersion: v1
kind: ConfigMap
metadata:
  name: datakit-conf
  namespace: datakit
data:
    mysql.conf: |-
        [[inputs.mysql]]
          host = "xxxxxxxxxxxxxxx"      ## 対応する MySQL 接続アドレスに変更
          user = "ste3"                 ## MySQL ユーザー名を変更
          pass = "Test1234"             ## MySQL パスワードを変更
          ......

    redis.conf: |-
        [[inputs.redis]]
          host = "r-xxxxxxxxx.redis.rds.ops.ste3.com"            ## Redis 接続アドレスを変更
          port = 6379                                                   
          # unix_socket_path = "/var/run/redis/redis.sock"
          # 複数の db を設定。dbs を設定すると、db も収集リストに追加されます。dbs=[] または未設定の場合は、redis 内のすべての空でない db を収集します。
          # dbs=[]
          # username = "<USERNAME>"
           password = "Test1234"                                        ## Redis パスワードを変更
          ......

    openes.conf: |-
        [[inputs.elasticsearch]]
          ## Elasticsearch サーバー設定
          # Basic 認証をサポート:
          # servers = ["http://user:pass@localhost:9200"]
          servers = ["http://guance:123.com@opensearch-cluster-client.middleware:9200"]   ## ユーザー名、パスワードなどを変更
          ......

4) マウント操作

        - mountPath: /usr/local/datakit/conf.d/db/mysql.conf
          name: datakit-conf
          subPath: mysql.conf
          readOnly: false

注意：複数の設定も同様です。順次追加していきます。

6) 修正後、DataKit をデプロイ

kubectl apply -f datakit.yaml

環境変数の説明¶

変数名	説明
ENV_DEFAULT_ENABLED_INPUTS	デフォルト収集を設定：self,cpu,disk,diskio,mem,swap,system,hostobject,net,host_processes,container,zipkin
ENV_ENABLE_ELECTION	選挙メカニズムを有効にすると、Prometheus 収集（またはその他のコンポーネント）はマスターノードまたは候補ノードとして動作します
ENV_GLOBAL_ELECTION_TAGS	選挙コンポーネントに追加のタグディメンションを追加。Prometheus 収集時のタグ付けに使用（選挙有効時）
ENV_INPUT_DDTRACE_COMPATIBLE_OTEL	`otel Trace` と `DDTrace Trace` の互換性を有効にする
ENV_INPUT_DISK_USE_NSENTER	`nsenter` 方式でディスク使用量情報を収集。クラスターの動的ストレージブロック情報を収集します。動的ストレージブロックを使用する場合は必ず設定
ENV_INPUT_HOSTOBJECT_USE_NSENTER	`nsenter` 方式でディスク使用量情報を収集。クラスターの動的ストレージブロック情報を収集します。動的ストレージブロックを使用する場合は必ず設定
ENV_INPUT_CONTAINER_ENABLE_CONTAINER_METRIC	コンテナメトリクス収集を有効にする
ENV_INPUT_CONTAINER_ENABLE_POD_METRIC	Pod メトリクス収集を有効にする（CPU とメモリ使用量）
ENV_INPUT_CONTAINER_ENABLE_K8S_METRIC	k8s メトリクス収集を有効にする

ビュー、モニターテンプレート、Pipelines のインポート¶

注意

監視テンプレートをインポートした後、アラートポリシーとアラート通知先を手動で設定する必要があります。

ビュー、モニターテンプレートのインポート¶

ビューおよびモニターテンプレートをダウンロード

「管理」-「ワークスペース設定」-「インポート」

注意

インポート後、監視の対応するジャンプリンク設定を修正する必要があります。URL 内の dsbd_xxxx を対応するダッシュボードに、wksp_xxxx を監視対象のワークスペースに変更してください。

Pipelines のインポート¶

guance-self-observing-latest.zip ファイルを解凍します。パス：guance-self-observing-latest/pipeline

「管理」-「Pipelines」-「インポート」

アプリケーションサービス監視¶

サービス prom 収集の設定¶

prom 設定ファイルをダウンロード

guance-self-observing-prom-latest.zip を解凍し、以下のコマンドを実行：

cd guance-self-observing-prom-latest
kubectl patch deploy kodo-x -n  forethought-kodo  --type merge --patch "$(cat kodo-x-prom.yaml)" 
kubectl patch deploy kodo -n  forethought-kodo  --type merge --patch "$(cat kodo-prom.yaml)" 
kubectl patch deploy kodo-inner -n  forethought-kodo  --type merge --patch "$(cat kodo-inner-prom.yaml)" 
kubectl patch sts kodo-servicemap -n  forethought-kodo  --type merge --patch "$(cat kodo-servicemap-prom.yaml)" 
kubectl patch sts kodo-x-backuplog -n  forethought-kodo  --type merge --patch "$(cat kodo-x-backuplog-prom.yaml)" 
kubectl patch deploy inner -n  forethought-core  --type merge --patch "$(cat core-inner-prom.yaml)"

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

forethought-core への設定注入¶

#!/bin/bash
set -euo pipefail

# 名前空間
NAMESPACE="${NAMESPACE:-forethought-core}"

# —— 各 deployment の専用 KV をここに記述（スクリプト内、外部ファイルは使用しない）——
# 1行1つ："<deploy> KEY=VAL KEY=VAL ..."
DEPLOY_ENV_CONFIG=(

  'front-backend DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=front-backend DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'inner DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=inner DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'management-backend DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=management-backend DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'open-api DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=open-api DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'sse DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=sse DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'core-worker DD_TRACE_ENABLED=false'
  'core-worker-0 DD_TRACE_ENABLED=false'
  'core-worker-beat DD_TRACE_ENABLED=false'
  'core-worker-correlation DD_TRACE_ENABLED=false'
)

# —— args[0] にのみ ddtrace-run を前置（command は変更しない）——
prefix_ddtrace_run_args_only() { # $1 deploy
  local d="$1"

  # トレースが明示的に無効化されている場合は追加しない
  local trace_enabled
  trace_enabled="$(kubectl get deploy "$d" -n "$NAMESPACE" \
     -o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="DD_TRACE_ENABLED")].value}' 2>/dev/null || true)"
  if [[ "$trace_enabled" == "false" ]]; then
    echo "  • DD_TRACE_ENABLED=false、ddtrace-run をスキップ。"
    return 0
  fi

  # args[0] を読み取り
  local first_arg
  first_arg="$(kubectl get deploy "$d" -n "$NAMESPACE" \
     -o jsonpath='{.spec.template.spec.containers[0].args[0]}' 2>/dev/null || true)"

  # 既に ddtrace-run で始まっている場合はスキップ
  if [[ "$first_arg" == "ddtrace-run" ]]; then
    echo "  • args は既に ddtrace-run で始まっています、スキップ。"
    return 0
  fi

  # args 配列が存在するか確認
  local has_args
  has_args="$(kubectl get deploy "$d" -n "$NAMESPACE" \
     -o jsonpath='{.spec.template.spec.containers[0].args}' 2>/dev/null || true)"

  if [[ -n "$has_args" ]]; then
    # 既存の args の先頭に ddtrace-run を挿入
    kubectl patch deploy "$d" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/args/0","value":"ddtrace-run"}
    ]' >/dev/null
    echo "  • args[0] に ddtrace-run を挿入しました"
  else
    # args がない場合、args を作成し ddtrace-run を最初の要素として追加
    kubectl patch deploy "$d" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/args","value":["ddtrace-run"]}
    ]' >/dev/null
    echo "  • args なし：args=[\"ddtrace-run\"] を作成しました"
  fi
}


# —— ユーティリティ関数 —— #
has_env() { # $1 deploy  $2 KEY
  kubectl get deploy "$1" -n "$NAMESPACE" \
    -o jsonpath="{.spec.template.spec.containers[0].env[?(@.name=='$2')].name}" 2>/dev/null | grep -qx "$2"
}
ensure_env_array() { # $1 deploy
  local has_array
  has_array="$(kubectl get deploy "$1" -n "$NAMESPACE" -o jsonpath="{.spec.template.spec.containers[0].env}" 2>/dev/null || true)"
  if [[ -z "${has_array}" ]]; then
    kubectl patch deploy "$1" -n "$NAMESPACE" --type='json' -p="[
      {\"op\":\"add\",\"path\":\"/spec/template/spec/containers/0/env\",\"value\":[]}
    ]" >/dev/null
  fi
}

for item in "${DEPLOY_ENV_CONFIG[@]}"; do
  deploy="${item%% *}"
  # 行がデプロイ名のみの場合はスキップ
  rest="${item#* }"; [[ "$rest" == "$deploy" ]] && rest=""

  echo "→ 処理中: $deploy"

  # 存在確認
  if ! kubectl get deploy "$deploy" -n "$NAMESPACE" >/dev/null 2>&1; then
    echo "  - 見つかりません、スキップ。"
    continue
  fi

  # env 配列が存在することを確認（ないと /env/- の追加に失敗する）
  ensure_env_array "$deploy"

  # Downward API を追加（不足している場合）：DD_AGENT_HOST=status.hostIP、POD_NAME=metadata.name
  if ! has_env "$deploy" "DD_AGENT_HOST"; then
    kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/env/-",
       "value":{"name":"DD_AGENT_HOST","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.hostIP"}}}}
    ]' >/dev/null
    echo "  • DD_AGENT_HOST (status.hostIP) を追加"
  else
    echo "  • DD_AGENT_HOST は既に存在します、スキップ。"
  fi

  if ! has_env "$deploy" "POD_NAME"; then
    kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/env/-",
       "value":{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}}}
    ]' >/dev/null
    echo "  • POD_NAME (metadata.name) を追加"
  else
    echo "  • POD_NAME は既に存在します、スキップ。"
  fi

  # 静的 KEY=VAL を1つずつ追加（不足している場合のみ；既存の場合はスキップ）
  for kv in $rest; do
    key="${kv%%=*}"
    val="${kv#*=}"
    if has_env "$deploy" "$key"; then
      echo "  • $key は既に存在します、スキップ。"
    else
      kubectl set env deploy/"$deploy" -n "$NAMESPACE" "$key=$val" >/dev/null
      echo "  • $key=$val を追加"
    fi
  done
  # 起動コマンドの先頭に ddtrace-run を追加
  prefix_ddtrace_run_args_only "$deploy"
  echo "  -> 完了: $deploy"
done

forethought-kodo への設定注入¶

#!/bin/bash
set -euo pipefail

# 名前空間
NAMESPACE="${NAMESPACE:-forethought-kodo}"

# —— 各 deployment の専用 KV をここに記述（スクリプト内、外部ファイルは使用しない）——
# 1行1つ："<deploy> KEY=VAL KEY=VAL ..."
DEPLOY_ENV_CONFIG=(
  'kodo DD_TRACE_ENABLED=true DD_TRACE_AGENT_PORT=9529 DD_TRACE_SAMPLE_RATE=0 DD_SERVICE=kodo DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
  'kodo-inner DD_TRACE_ENABLED=true DD_TRACE_AGENT_PORT=9529 DD_SERVICE=kodo-inner DD_TAGS=pod_name:$(POD_NAME),project:dataflux'

)

# —— ユーティリティ関数 —— #
has_env() { # $1 deploy  $2 KEY
  kubectl get deploy "$1" -n "$NAMESPACE" \
    -o jsonpath="{.spec.template.spec.containers[0].env[?(@.name=='$2')].name}" 2>/dev/null | grep -qx "$2"
}
ensure_env_array() { # $1 deploy
  local has_array
  has_array="$(kubectl get deploy "$1" -n "$NAMESPACE" -o jsonpath="{.spec.template.spec.containers[0].env}" 2>/dev/null || true)"
  if [[ -z "${has_array}" ]]; then
    kubectl patch deploy "$1" -n "$NAMESPACE" --type='json' -p="[
      {\"op\":\"add\",\"path\":\"/spec/template/spec/containers/0/env\",\"value\":[]}
    ]" >/dev/null
  fi
}

for item in "${DEPLOY_ENV_CONFIG[@]}"; do
  deploy="${item%% *}"
  # 行がデプロイ名のみの場合はスキップ
  rest="${item#* }"; [[ "$rest" == "$deploy" ]] && rest=""

  echo "→ 処理中: $deploy"

  # 存在確認
  if ! kubectl get deploy "$deploy" -n "$NAMESPACE" >/dev/null 2>&1; then
    echo "  - 見つかりません、スキップ。"
    continue
  fi

  # env 配列が存在することを確認（ないと /env/- の追加に失敗する）
  ensure_env_array "$deploy"

  # Downward API を追加（不足している場合）：DD_AGENT_HOST=status.hostIP、POD_NAME=metadata.name
  if ! has_env "$deploy" "DD_AGENT_HOST"; then
    kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/env/-",
       "value":{"name":"DD_AGENT_HOST","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.hostIP"}}}}
    ]' >/dev/null
    echo "  • DD_AGENT_HOST (status.hostIP) を追加"
  else
    echo "  • DD_AGENT_HOST は既に存在します、スキップ。"
  fi

  if ! has_env "$deploy" "POD_NAME"; then
    kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
      {"op":"add","path":"/spec/template/spec/containers/0/env/-",
       "value":{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}}}
    ]' >/dev/null
    echo "  • POD_NAME (metadata.name) を追加"
  else
    echo "  • POD_NAME は既に存在します、スキップ。"
  fi

  # 静的 KEY=VAL を1つずつ追加（不足している場合のみ；既存の場合はスキップ）
  for kv in $rest; do
    key="${kv%%=*}"
    val="${kv#*=}"
    if has_env "$deploy" "$key"; then
      echo "  • $key は既に存在します、スキップ。"
    else
      kubectl set env deploy/"$deploy" -n "$NAMESPACE" "$key=$val" >/dev/null
      echo "  • $key=$val を追加"
    fi
  done

  echo "  -> 完了: $deploy"
done

Synthetic モニタリングの設定¶

1) 監視するウェブサイトを新規作成

2) Synthetic テストを設定

注意

実際に設定したドメイン名に応じて修正してください

名前	テストアドレス	タイプ	タスクステータス
xx-dataflux-api	https://xx-console-api.guance.com	HTTP	開始
xx-open-api	https://xx-open-api.guance.com	HTTP	開始
xx-dataway	https://xx-dataway.guance.com	HTTP	開始
xx-static-res	https://xx-static-res.guance.com/dataflux-template/README.md	HTTP	開始
xx-dataflux	https://xx-dataflux.guance.com	HTTP	開始
xx-management-api	https://xx-management-api.guance.com	HTTP	開始
xx-management	https://xx-management.guance.com	HTTP	開始

リアルユーザーモニタリング（RUM）の設定¶

注意

「パブリック DataWay を使用」が見つからない場合は、namespace「forethought-webclient」- configmap「front-web-config」を修正し、rumDatawayUrl:<https://<Dataway アドレス> を追加して、front-webclient サービスを再起動してください。

1) RUM 設定を取得

自己観測ワークスペースにログインし、RUM app を作成

App Name：Guance
App ID: xxx_guance_com
site を取得
clientToken を取得

2) forethought-webclient namespace の front-web-config ConfigMap 設定を修正（パラメータがない場合は追加）

rumEnable: 1 (1 で有効)
rumOpenwayUrl: 「取得した site」
rumClientToken: 「取得した clientToken」
rumApplicationId: 「App ID」
rumAllowedDdtracingOrigins: ["https://xxx-console-api.guance.com", "https://xxx-console.guance.com"]
rumJsUrl: "https://static.guance.com/browser-sdk/v3/dataflux-rum.js", ## Guance バージョン 1.123.216 より前では v2 を v3 に変更してください

window.DEPLOYCONFIG = {
    cookieDomain: '.guance.com',
    apiUrl: 'https://cn4-console-api.guance.com',
    wsUrl: 'wss://.guance.com',
    innerAppDisabled: 0,
    innerAppLogin: 'https://cn4-auth.guance.com/redirectpage/login',
    innerAppRegister: 'https://cn4-auth.guance.com/redirectpage/register',
    innerAppProfile: 'https://cn4-auth.guance.com/redirectpage/profile',
    innerAppCreateworkspace: 'https://cn4-auth.guance.com/redirectpage/createworkspace',
    staticFileUrl: 'https://cn4-static-res.guance.com',
    staticDatakit: 'https://static.guance.com',
    cloudDatawayUrl: '',
    isSaas: '1',
    showHelp: 1,
    rumEnable: 1,                                                                              ## 0は無効、1は有効、ここでは有効にします
    rumOpenwayUrl: "",                                                                         ## openway アドレス
    rumApplicationId: "",                                                                      ## 実際の appid に変更
    rumJsUrl: "https://static.guance.com/browser-sdk/v3/dataflux-rum.js", ## Guance バージョン 1.123.216 より前では v2 を v3 に変更してください
    rumDataEnv: 'prod',

アラートポリシーの説明¶

アラートポリシー名	アラートレベル	アラート説明	備考
P0 アラート - Lark & 電話通知	重大	このポリシーは最高レベルのアラートで、イベント発生後直ちに対処する必要があります。トリガー条件： 1. サイトページにアクセス不可； 2. データの報告または書き込みに失敗し、データ損失が発生； 3. モニターが停止し、ユーザーの監視が機能しなくなる； 4. 自動トリガータスクが停止または失敗し、データ損失が発生； 5. ミドルウェア障害により、システムが利用不可になるかデータ損失が発生。	アラート通知先の推奨：電話
インフラストラクチャアラート - Lark通知	重大、重要	このポリシーは P0 アラートより低いレベルで、イベント発生後は継続的な監視と調査が必要です。トリガー条件： 1. サービスの異常再起動； 2. ノードのメモリ異常； 3. ノードの負荷が高い、またはその他のシステムリソースの異常。	アラート通知先の推奨：通常（メール、Lark など）
業務アラート - Lark通知	重大、重要、警告	このポリシーは通常レベルのアラートで、イベント発生後は継続的な監視を推奨します。トリガー条件： 1. サービスのログエラー； 2. ビジネスロジック関連の異常。	アラート通知先の推奨：通常（メール、Lark など）
ScopeDB 関連サービスアラート	すべて	このポリシーは通常レベルのアラートで、イベント発生後は継続的な監視を推奨します。トリガー条件： 1. ScopeDB サービスのログエラー； 2. ScopeDB のパフォーマンスアラート	アラート通知先の推奨：通常（メール、Lark など）

アラート設定手順¶

通知先の作成¶

自己観測ワークスペースにログインし、「監視」-「通知先管理」にアクセス
3つの異なる通知先を作成（通知先の種類は問いません。異なる通知グループを推奨）
業務アラート
インフラストラクチャアラート
P0 アラート

アラートポリシーの設定¶

「監視」- 「アラートポリシー管理」で通知設定を行います

アラートポリシー名	通知設定 - レベル	通知設定 - 対象	再通知間隔
インフラストラクチャアラート - Lark	重大、重要	インフラストラクチャアラート	30 分
P0 アラート - Lark & 電話通知	重大	P0 アラート	6 時間
業務アラート - Lark通知	重大、重要、警告	業務アラート	30 分
ScopeDB 関連サービスアラート	すべて	業務アラート	30 分

Func 自己観測（オプション）¶

Func タスクログデータの報告¶

DataFlux Func の関数実行ログ、自動トリガー設定などの情報は、Guance に直接報告できます。手順は以下の画像の通りです。

Guance のデータ報告で、DataWay / OpenWay アドレスと Token 情報を以下の形式で入力します。

https://openway.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

注意：Func のデータ報告が失敗した場合は、DataFlux Func ドキュメントを参照してください

業務監視収集（オプション）¶

プライベート Func のデプロイ¶

注意：storageClass、MYSQL_HOST、MYSQL_USER、MYSQL_PASSWORD、MYSQL_DATABASE などのパラメータ

helm install func func --repo https://pubrepo.guance.com/chartrepo/func -n datakit  --create-namespace  \
    --set storage.pvc.enabled=true,storage.pvc.storageClass="xxxxxxxx" \
    --set mysql.enabled=false,func.MYSQL_HOST='xxxxxx' \
    --set func.MYSQL_USER=private_func,func.MYSQL_PASSWORD=xxxxx,func.MYSQL_DATABASE=private_func

Ingress の設定¶

事前に証明書を設定

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: xxx-private-func
  namespace: datakit
spec:
  ingressClassName: nginx
  rules:
    - host: xxx-private-func.guance.com
      http:
        paths:
          - backend:
              service:
                name: func-server
                port:
                  number: 8088
            path: /
            pathType: ImplementationSpecific
  tls:
    - hosts:
        - xxx-private-func.guance.com
      secretName: guance.com

初期化¶

ブラウザでドメインにアクセスし、次へ進みます。

スクリプトのインポート¶

スクリプトパッケージをダウンロード

「スクリプトセットのインポート」-「スクリプトのインポート」にアクセス

データベース環境変数設定の変更¶

【業務データ収集アカウント】の情報を入力

確認方法¶

guance_site パラメータを切り替える必要があります

名前	確認方法	確認操作
MySQL	DQL	M::`mysql`:(avg(`max_connections`)) { `guance_site` = 'xxx' } BY `host`
Redis	DQL	M::`redis_info`:(avg(`maxmemory`)) { `guance_site` = 'xxx' } BY `host`
PostgreSQL	DQL	M::`postgresql_connection`:(max(`percent_usage_connections`)) { `guance_site` = 'xxx' }
NSQD	DQL	M::`nsq_topics`:(max(`message_count`)) { `guance_site` = 'xxx' } BY `topic`
DataWay	DQL	M::`dw`:(max(`dataway_cpu_cores`)) { `guance_site` = 'xxx' } BY `guance_site`
Studio トレース	DQL	T::`front-backend`:(count(`*`)) { `guance_site` = 'xxx' } BY `guance_site`
Kodo-inner トレース	DQL	T::`kodo-inner`:(count(`*`)) { `guance_site` = 'xxx' } BY `guance_site`
Kodo メトリクス	DQL	M::kodo_workers:(count(`job_point_bytes_total`), count(`write_byte_total`)) BY `guance_site`