GlueSyncでNoSQL活用を加速：通知アラート、ログ、モニタリング

GlueSyncはログ、アラートをLogbackで実装しています。これにより、ログをコンソールのみでなくファイルとして出力、エラーレベルのものはメール通知するといった対応が可能です。

また監視についてはPrometheus 互換のメトリクスをサポートしていますので、/metricsエンドポイント介してPrometheus で監視できます。

今回はそれぞれの構成を具体的に紹介していきます。

ログ出力、アラートの通知

ログファイルやアラート通知を構成するにはLogbackの構成を変更する必要があります。このため、LOG_CONFIG_FILEに対して構成ファイルであるlogback.xmlのパスを指定します。

また、ログの出力先をマウントするように構成しています。

# docker-compose.yml
version: '3.7'

services:
  gluesync-s2n:
    image: molo17com/gluesync-sql-to-nosql:mssql-to-couchbase-1.5.33
    restart: 'no'
    environment:
      - CONFIG_FILE=/opt/app/config/config.json
      - LICENCE_KEY=/opt/app/config/gs-licence.dat
      - LOG_CONFIG_FILE=/opt/app/config/logback.xml
    volumes:
      - "$PWD/config:/opt/app/config"
      - "$PWD/log:/var/log"
    ports:
      - "111:80"

  prometheus:
    image: prom/prometheus
    restart: always
    volumes:
      - "$PWD/prometheus:/etc/prometheus"
    command: "--config.file=/etc/prometheus/prometheus.yml"
    ports:
      - 9090:9090

logback.xmlでは以下のようにappender でコンソールだけではなくファイルやメールでの通知を追加、logger でappender を参照して、出力するログレベルを指定します。

この例では、コンソールとログファイルにはdebugレベルで出力し、メール通知にはerrorレベルのみ出力しています。

<?xml version="1.0" encoding="UTF-8"?>
<included>
   <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
       <encoder>
           <pattern>
               %d{yyyy-MM-dd'T'HH:mm:ss.SSS} [%t] %c{0} %p - %msg%n
           </pattern>
       </encoder>
   </appender>
   <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
       <file>/var/log/gluesync/gluesync-n2s.log</file>
       <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
           <fileNamePattern>/var/log/gluesync/archived/gluesync-n2s.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
           <!-- 各アーカイブファイルのサイズ上限10MB -->
           <maxFileSize>10MB</maxFileSize>
           <!-- 全てのアーカイブファイルの合計サイズ上限20GB、上限を超えた場合古いものから削除 -->
           <totalSizeCap>20GB</totalSizeCap>
           <!-- 60日分保持 -->
           <maxHistory>60</maxHistory>
       </rollingPolicy>
       <encoder>
           <pattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSS} %c{1} %p %m%n</pattern>
       </encoder>
   </appender>
   <logger name="com.gluesync" level="debug" additivity="false">
       <appender-ref ref="CONSOLE"/>
       <appender-ref ref="FILE"/>
   </logger>
   <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">
      <smtpHost>smtp.gmail.com</smtpHost>
      <smtpPort>587</smtpPort>
      <STARTTLS>true</STARTTLS>
      <username>myusername@mycompany.com</username>
      <password>mysecretpassword</password>
      <asynchronousSending>true</asynchronousSending>
      <to>receiveremailaddress@mydomainname.com</to>
      <from>mysenderemailaddress@mydomainname.com</from>
      <subject>Gluesync SQL-to-NoSQL: %c{1} - %msg</subject>
      <layout class="ch.qos.logback.classic.html.HTMLLayout"/>
      <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker">
           <!-- メール1通につきログを1つ送信 -->
           <bufferSize>1</bufferSize>
       </cyclicBufferTracker>
   </appender>
   <logger name="com.gluesync" level="error" additivity="false">
       <appender-ref ref="EMAIL"/>
   </logger>
</included>

詳細は下記をご参照ください。
https://logback.qos.ch/documentation.html

このように設定して実行することで、ログファイルへ出力、エラーが発生した場合はそれを通知するといった構成が可能です。

Prometheus での監視

GlueSync自体に実装されているわけではないため、Prometheus を別途実行する必要があります。今回はGlueSyncと同サーバ上でPrometheus も実行しています。また、GlueSyncの/metricsエンドポイントへアクセスできるようにportsでポートを紐づけています。

# docker-compose.yml
version: '3.7'

services:
  gluesync-s2n:
    image: molo17com/gluesync-sql-to-nosql:mssql-to-couchbase-1.5.33
    restart: 'no'
    environment:
      - CONFIG_FILE=/opt/app/config/config.json
      - LICENCE_KEY=/opt/app/config/gs-licence.dat
    volumes:
      - "$PWD/config:/opt/app/config"
    ports:
      - "111:80"

  prometheus:
    image: prom/prometheus
    restart: always
    volumes:
      - "$PWD/prometheus:/etc/prometheus"
    command: "--config.file=/etc/prometheus/prometheus.yml"
    ports:
      - 9090:9090

Prometheusの設定では、そのポートを参照するように構成しておきます。

global:
 scrape_interval:     15s

scrape_configs:
 - job_name: 'gluesync'
   static_configs:
     - targets:
       - '192.168.33.230:111'

また、GlueSyncの同期設定としてはsourceEntitiesで4つの同期を構成し、SQL ServerからCouchbaseへデータを連携させています。同期設定を自体を記載すると長くなるため省略していますので、詳細は前回の記事をご確認ください。https://www.climb.co.jp/blog_dbmoto/archives/7154

{
  "sourceHost": "192.168.33.15",
  "sourcePort": "1433",
  "sourceName": "日本語テスト",
  "sourceUsername": "sa",
  "sourcePassword": "P@ssword123",
  "sourceEntities": {
    "alias": {
      "schema": "dbo",
      "table": "商品情報",
      "type": "alias",
      "scope": "data"
    },
    "driverwithmapping": {
     省略：https://www.climb.co.jp/blog_dbmoto/archives/7154#i
        }
    },
    "shippinginfowithINNER_JOIN": {
     省略：https://www.climb.co.jp/blog_dbmoto/archives/7154#SQLJSON
    },
    "orderwithdatamodeling": {
     省略：https://www.climb.co.jp/blog_dbmoto/archives/7154#i-2
    }
  },
  "mssql": {
    "temporaryTableNamePrefix": "gs",
    "statePreservationTableNamePrefix": "gs"
  },

  "sourceChangeRetention": 5,
  "copySourceEntitiesAtStartup": true,

  "targetHost": "192.168.33.15",
  "targetPort": "8091",
  "targetName": "JP_Test",
  "targetUsername": "Administrator",
  "targetPassword": "password",
  "maxItemsCountPerTransaction": 100,
  "maxMigrationItemsCountPerIteration": 20000,

  "couchbase": {
    "useCollections": true
  }
}

これを実行してモニタリングしてみます。まず、Prometheusにアクセスし、Status＞Targetsを確認すると以下のようにGlueSyncのメトリクスを参照できていることが確認できます。

そして、GraphにてGlueSyncのメトリックを参照すれば、GlueSyncの実行状況を監視できます。

上記は各同期設定に関してGluesync実行開始から、いくつのイベントを処理したカウント（累計）した値を示すメトリックgluesync_processed_eventsを基に、60秒間の差分(delta)を表示することで、毎分で処理しているイベント数をグラフ化しています。

他にも以下のようなメトリクスがあり、GlueSyncの動作をモニタリングできます。

メトリック名	説明	種類
gluesync_processed_events_total	処理されたイベントの合計数	カウンタ
gluesync_errors_count_total	エラーの合計数	カウンタ
gluesync_uptime	GlueSyncの起動時間（ミリ秒）	カウンタ
gluesync_processed_events	各同期設定で処理されたイベント数	カウンタ
gluesync_errors	各同期設定のエラー数	カウンタ
gluesync_buffer_pressure	各同期設定のバッファ（％）	カウンタ
gluesync_sync_status	各同期設定のステータス、1がビジー（実行中）で0がアイドル（待機）状態	ゲージ

関連したトピックス

• GlueSyncでNoSQL活用を加速：導入編
• Gluesync 2.0： 新しい統合とパフォーマンス向上へ
• GlueSyncでNoSQL活用を加速：データモデリング編
• Snowflake Target Connectorのサポートで:Gluesyncとのシームレスなデータ統合へ
• Syniti(旧DBMoto)サーバーの移行方法の選択肢
• PostgreSQLに対してバルクインサートが可能に【DBMoto Ver8.5新機能①】
• GlueSyncがAWS S3（互換も含む）に対応：分析、データレイク、コールドストレージ向けに、AWS S3 へのリアルタイムデータレプリケーションがシンプルに
• AS/400でレプリケーションに必要なジャーナルが起動済みかを確認するためには？
• Gluesync用Redisエージェント：ターゲットとしてのRedisディプロイのためのシームレスな統合
• 現実的なMongoDB Realmアプリケーションの移行:オプションと戦略の検討