Posted inMonitoring

Apache SkyWalkingのインストール：マイクロサービス監視の「神の目」をAからZまで解説

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

Dockerで5分以内に立ち上げる

環境構築に手間取ることなく、すぐにSkyWalkingを試したい場合は、Docker Composeが最適な選択肢です。設定ファイル一つで、OAP Server（処理エンジン）とUI（監視画面）をすぐに用意できます。

# docker-compose.ymlファイルを作成
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
    ports:
      - "9200:9200"

  oap:
    image: apache/skywalking-oap-server:9.2.0
    container_name: oap
    depends_on:
      - elasticsearch
    links:
      - elasticsearch
    environment:
      SW_STORAGE: elasticsearch
      SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200
    ports:
      - "11800:11800"
      - "12800:12800"

  ui:
    image: apache/skywalking-ui:9.2.0
    container_name: ui
    depends_on:
      - oap
    links:
      - oap
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    ports:
      - "8080:8080"

docker-compose up -d コマンドを実行し、60秒ほど待ちます。http://localhost:8080 にアクセスし、ダッシュボードが表示されれば準備完了です。

SkyWalkingとは何か？なぜ今注目されているのか？

システムが数十ものマイクロサービスに肥大化すると、デバッグは「悪夢」に変わります。1つのリクエストが20のサービスを経由する場合、どこでエラーが発生したのか？なぜデータベースのレスポンスが遅いのか？

以前はPrometheusとGrafanaの組み合わせをよく使っていましたが、これらはCPUやRAMなどのメトリクス監視には強いものの、個々のリクエストの軌跡（フロー）を把握するには、分散トレーシング（Distributed Tracing）が必要です。SkyWalkingは、以下の3つの主要コンポーネントによってこの問題をスマートに解決します。

  • SkyWalking Agent: アプリケーション内に「常駐」し、コードを一行も書き換えることなくデータを収集します。
  • OAP Server: Agentからデータを受け取り、分析を行ってデータベースに保存します。
  • SkyWalking UI: 視覚的なチャートやリクエストのトレースを表示する場所です。

最大のメリットは、Java、Go、.NETからPythonまで多言語をサポートしている点です。さらに、IstioのようなService Meshとの相性も抜群です。

Linuxへのインストール（本番環境向け）

本番環境で運用する場合、リソースを最適化するためにLinuxへ直接インストールすることを推奨します。以下は、私が普段適用している標準的な手順です。

ステップ1：環境の準備

OAPはJVM上で動作するため、JDK 11または17が必要です。また、Elasticsearchも用意しておきましょう。データ量が増えたときにシステムがハングアップするのを避けるため、デフォルトのH2データベースは使用しないでください。

# Java의 버전 확인
java -version

# 適切なSkyWalkingのバージョンをダウンロード（例：9.2.0）
wget https://archive.apache.org/dist/skywalking/9.2.0/apache-skywalking-apm-9.2.0.tar.gz
tar -xvzf apache-skywalking-apm-9.2.0.tar.gz
cd apache-skywalking-apm-bin

ステップ2：Elasticsearchとの接続

config/application.yml ファイルを開きます。storage セクションを探し、自身のElasticsearchクラスタを指すように設定します。

storage:
  selector: ${SW_STORAGE:elasticsearch}
  elasticsearch:
    nameSpace: ${SW_NAMESPACE:""}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
    user: ${SW_ES_USER:""}
    password: ${SW_ES_PASSWORD:""}

ステップ3：起動

SkyWalkingには、OAPとUIの両方を同時に起動できる便利なスクリプトが用意されています。

bin/startup.sh

# ログを監視して正常に動作しているか確認
tail -f logs/skywalking-oap-server.log

注意：UIはポート8080で動作し、Agentはポート11800 (gRPC) を介してデータを送信します。

Spring BootへのAgent導入：コードの修正は不要

ここが最も「魔法」のような部分です。jarファイルを実行する際にJVMパラメータを追加するだけで、データが自動的にダッシュボードに反映されます。

java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=10.0.0.5:11800 \
     -jar order-app.jar

ここで、service_name はUI上に表示される名前、backend_service はOAPがインストールされているサーバーのIPアドレスです。

実践的なアドバイス：アラート疲れ（Alert Fatigue）に陥らないために

最初にセットアップした際、私はあらゆる事象に対してTelegram通知を飛ばすというミスを犯しました。その結果、通知が鳴り止まず、本当の障害を無視してしまうことになりました。これがいわゆる アラート疲れ（Alert Fatigue） です。

私からのアドバイスは以下の通りです：

  1. スマートな閾値（threshold）設定： デフォルト値を使うのではなく、1週間システムを観察してください。平均レイテンシが200msであれば、アラートは400ms（平均の2倍）に設定しましょう。
  2. 優先順位の階層化： 5xxエラーが急増した場合は即座に通知し、レイテンシのわずかな増加は1日の終わりにレポートとしてまとめるだけにします。
  3. alarm-settings.ymlの最適化： このファイルを活用してノイズを除去し、不要なゴミ通知を避けましょう。

ストレージの最適化：Elasticsearchによるディスク容量不足を防ぐ

トレーシングデータは非常に容量を消費します。中規模のシステムでも、1日に数GBのログが生成されることがあります。application.yml で TTL (Time To Live) を設定する必要があります。

core:
  default:
    # トレースデータは3日間、メトリクスデータは7日間のみ保持
    recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3}
    metricsDataTTL: ${SW_CORE_METRICS_DATA_TTL:7}

これによりElasticsearchの負荷を抑え、深夜2時にディスク清掃のために起きる必要がなくなります。

まとめ

SkyWalkingは完全に無料でありながら、DevOpsやバックエンドエンジニアにとって非常に大きな価値をもたらします。コードをデプロイする際の自信に繋がります。Topology Map（トポロジーマップ）を見れば、リクエストのどこがボトルネックになっているか一目で分かります。ぜひ皆さんもインストールに挑戦して、この「神の目」を使いこなしてください！

Share:
Tags: