SAP 監視を Amazon Managed Prometheus と Grafana で強化

ビジネス上の重要な処理に SAP システムを利用している企業は、高い可用性とパフォーマンスを求められるため、オブザーバビリティ戦略は運用の効率化に欠かせない重要な要素となります。

SAP HANA、SAP Business Suite on HANA、または SAP S/4HANA などのソリューションを実行する大規模な SAP 環境を持つ企業は、これらの環境に複数のモニタリングオプションがあります。SAP Solution Manager、Amazon CloudWatch Application Insights などのソリューションは、一般的にシステムの正常性とパフォーマンスを監視するために使用されます。しかし、エンタープライズのモニタリング戦略を見ると、SAP と非 SAP ソリューションを組み合わせ、さらにマルチクラウド構成にすることで、可視化やアラートを単一の画面上で表示するダッシュボードを実現し、長期的なアーキテクチャを最適化します。Prometheus や Grafana などのツールは、SAP と非 SAP 環境を組み合わせたシステム監視のセットアップを実現するため、SAP と Amazon のマネージドオファリング (Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG)) を使用する組織でも既に使用されており、クラウドネイティブ技術を提供します。

SAP のお客様も、RISE with SAP で AWS を選択することが増えています。RISE に移行していないお客様のために、この解決策により、SAP ワークロードの監視能力が向上します。このブログでは、AWS Well-Architected Framework の SAP Lensのベストプラクティスに従って AMP と AMG を構成することで、SLES (SUSE Linux Enterprise Server) OS と SAP S/4HANA の監視ダッシュボードのセットアップ方法を学びます。
セットアップが完了すると、オペレーティングシステム、SAP アプリケーションサーバー、SAP 高可用性クラスターの各コンポーネントについて、複数のダッシュボードにまたがって SAP 環境全体の正常性を確認できます。

定義

このブログで使用する用語を定義しましょう。

オブザーバビリティ: オブザーバビリティ（可観測性）とは、システムの状態や性能を把握するための仕組みを指します。具体的には、システムの状態を示すメトリクス（指標）、ログ、トレースを用いて分析します。システムのパフォーマンスを理解することは、運用の優秀性を達成し、ビジネス目標を満たすための鍵となります。
「監視」という用語は時にオブザーバビリティとは異なると定義されますが、しかし監視はトレースやログ収集などの活動と並んで、システムを観測可能にする活動です。

Amazon Managed Prometheus (AMP): AMP はメトリクスのためのサーバーレス、Prometheus 互換のモニタリングサービスで、大規模なコンテナ環境をセキュアに監視することを簡単にします。AMP を使えば、お客様は今日使っているオープンソースの Prometheus データモデルとクエリ言語を使って、ワークロードのパフォーマンスを監視できます。また、基盤となるインフラストラクチャを管理する必要がなく、スケーラビリティ、可用性、セキュリティの向上もあります。

Amazon Managed Grafana (AMG): AMG は、完全にマネージドされ、セキュリティが確保されたデータ可視化サービスで、顧客はさまざまなデータソースから運用状況のデータを素早く照会、関連付け、視覚化できます。AMG は、拡張可能なデータサポートで広く利用されているデータ可視化ツール Grafana を簡単にデプロイ、運用、スケーリングできるようにしています。

前提条件

前提条件として、高可用性の有無にかかわらず、AWS アカウント内に SAP システムをセットアップする必要があります。設定を行うユーザーアカウントには、AWS IAM でロールを割り当てる権限が必要です。このブログでは、SAP S/4HANA システム (ASCS/ERS と SAP HANA DB クラスターおよび 2 つのアプリケーションサーバー) を、SLES for SAP 15 SP4 オペレーティングシステム上で動作させています。

アーキテクチャ

まずはこのソリューションの基本的なアーキテクチャを理解しましょう。図 1 は AWS 上で SAP S/4HANA を高可用性 (HA) 構成にした典型的なアーキテクチャを、図 2 はオブザーバビリティのアーキテクチャを示しています。
すべての SAP システムは SAP 認定 Amazon EC2 インスタンス上にインストールされ、データの移動は全て VPC エンドポイントを経由します。

図 1: AWS 上の SAP S/4HANA 高可用性 (HA) アーキテクチャの表現

図 2: Amazon Managed Prometheus (AMP) と Amazon Managed Grafana (AMG) を使用した SAP の可観測性アーキテクチャ

設定と構成

図 3 の下に示すように、ソリューションを構成する手順は以下の通りです。

図 3: AMP を使用した SAP の監視構成と AMG での可視化のためのステップ

AMP ワークスペースの作成と設定

データは AMP Workspace に「リモートライト」方式で取り込まれ、AMG のダッシュボードのデータソースとして使用されます。
ユーザー ID に Amazon Managed Service for Prometheus (AMP) コンソールから「Create workspace (ワークスペースの作成)」を選択する権限があることを確認し、図 4 に示すようにしてください。

図 4: AMP ワークスペースの作成

AMP でワークスペースが作成されると、サービスがリモート書き込み URL (図 5 に示されている) を提供します。後のセクションの構成手順でこの URL が必要になるので、リモート書き込み URL を控えておいてください。

図 5: AMP ワークスペースエンドポイントの詳細例

EC2 IAM から AMP にメトリクスをストリーミングする

AmazonPrometheusRemoteWriteAccess AWS 管理ポリシーを使用して、Amazon EC2 インスタンスの IAM ロールを作成します。このロールを EC2 インスタンスに割り当てるか、この新しく作成したロールで EC2 インスタンスを起動するか、または既存のロール (AWS ドキュメントの図 6 のように) に AmazonPrometheusRemoteWriteAccess ポリシーを割り当てることができます。

図 6: AMP ポリシー名

VPC エンドポイント

EC2 インスタンスから AWS バックボーンネットワークを経由して AMP にメトリクスをプライベートに送信するために、AMP 用の VPC エンドポイントを設定する必要があります。
VPC エンドポイントにより、VPC 内のリソース (この場合は EC2 インスタンス) から管理型サービスに安全にアクセスできるようになります。

次に、以下の手順で AMP の VPC インターフェイスエンドポイントを作成します:

AWS コンソールから、VPC サービスの「Endpoints」を選択し、図 7 のように「Amazon WorkSpaces」サービスを選択します。

図 7: AMP 用の AWS VPC エンドポイントサービス名

VPC 内のリソースがこれらのインターフェイスエンドポイントに HTTPS で通信を行えるように、VPC 内のセキュリティグループを変更する必要がある場合もあります。インターフェイスエンドポイントの作成方法の詳しい手順は、AWS ドキュメントで確認できます。

さらに、VPC から直接インターネットにアクセスできない場合は、図 8 に示すように、sigv4 がエンドポイントを介して機能できるよう、AWS Security Token Service 用のインターフェイス VPC エンドポイントも作成する必要があります。

図 8: AWS Security Token Service の VPC エンドポイントサービス名

Metrics Exporters と Prometheus の EC2 インスタンスへのインストールと設定

この手順では、EC2 インスタンス上に必要なエクスポーターと Prometheus エージェントをインストールする方法を学びます。
Prometheus のエクスポーターは、システムからメトリクスを収集し、Prometheus で読み取り可能にする役割を果たします。
Prometheus のエージェントは、メトリクスをエンドポイントに転送する役割を果たします。
各 SAP アーキテクチャコンポーネントのエクスポーターのリストは表 1 にまとめられています。
さらに、すべての EC2 インスタンスで Prometheus エージェントのインストールが必要で、そのことでデータを AMP に転送できるようになります。

SAP システムロール	エクスポーター名	詳細情報の URL
SAP ASCS/ERS クラスター	ClusterLabs ha_cluster_exporter Prometheus node_exporter	https://github.com/ClusterLabs/ha_cluster_exporter https://github.com/prometheus/node_exporter
SAP アプリケーションサーバー	SUSE sap_host_exporter Prometheus node_exporter	https://github.com/SUSE/sap_host_exporter https://github.com/prometheus/node_exporter

表 1: SAP 各コンポーネントで EC2 にインストールするエクスポーターのリスト

2.1 Node Exporter

Prometheus Node Exporter は、ハードウェアやカーネルに関する様々なメトリクスを公開し、それらのメトリクスを使って EC2 のヘルスステータスをダッシュボードで表示できます。
EC2 インスタンス上で node exporter をインストールして実行する手順は次のとおりです。( Prometheus のウェブサイトにも記載があります)。

Linux (SLES) オペレーティングシステムを実行している EC2 インスタンスで node exporter をインストール、展開、実行するには、以下のコマンドを実行してください。は node exporter のバージョン、-は OS のアーキテクチャに置き換えてください。
ダウンロードできる Node exporter パッケージはPrometheus のウェブサイトで確認できます。

wget https://github.com/prometheus/node_exporter/releases/download/v/node_exporter-.-.tar.gz

tar xvfz node_exporter-*.*-amd64.tar.gz

cd node_exporter-*.*-amd64

./node_exporter

Node Exporter はお好みのディレクトリ(例: /usr/local/bin)にインストールできます。実行すると、Node Exporter はローカルサーバーの 9100 番ポートの /metrics エンドポイントでメトリクスを公開します。
次の curl コマンドを実行して、9100 /metrics エンドポイントでメトリクスがエクスポートされていることを確認できます。

curl http://localhost:9100/metrics

コマンドの出力は次のようになります:

# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.

# TYPE node_cpu_seconds_total counter

node_cpu_seconds_total { cpu ="0",mode ="idle"} 6.8382833e + 06

node_cpu_seconds_total { cpu ="0",mode ="iowait"} 824.38

node_cpu_seconds_total { cpu ="0",mode ="irq"} 0

# その他の設定など

この手順を完了すると、SAP の役割に関係なく、すべての SAP EC2 インスタンスに node exporter がインストールされます。

2.2 ASCS/ERS EC2 インスタンスでの HA クラスターエクスポーター

Clusterlabs HA Cluster Exporter はステートレス HTTP エンドポイントです。
各 HTTP リクエストで、さまざまなクラスタコンポーネントのツールによって提供される既存の分散データを解析することで、クラスタの状況をローカルで検査します。
エクスポートされるデータには、次のような情報が含まれます。

ペースメーカークラスタの概要、ノードとリソースの統計情報
Corosync の通信リングのエラーとクォーラム投票
DRBD リソースなど

高可用性 SAP システムの設定では、corosync、pacemaker、フェイルオーバーの状態などのサービスの状況を把握することで、システムをよりよく理解し、障害の根本原因を特定するのに役立ちます。

ASCS と ERS の両方の EC2 インスタンスで、root ユーザーまたは sudo 権限を持つユーザーとしてエクスポーターパッケージをインストールして実行してください。

zypper install prometheus-ha_cluster_exporter

./ha_cluster_exporter

HA Cluster Exporter を実行すると、デフォルトでポート 9664 の /metrics パスの下にメトリクスがエクスポートされます。
ホスト上で実行中の /usr/bin/ha_cluster_exporter プロセスを確認すれば、HA クラスタのプロセスの状態を確認できます。

2.3 アプリケーションサーバーインスタンス上の SAP ホストエクスポーター

SAP Host Exporter はステートレスの HTTP エンドポイントです。
各 HTTP リクエストでは、SAPControl Web インターフェイスを介して SAP システムからランタイムデータを取得します。
エクスポートされたデータには、以下のような情報が含まれます:

サービスプロセスを起動する
サーバー統計を (統計情報を)キューに登録する
SAP アプリケーションサーバーディスパッチャーのワークプロセスキュー統計

sap_host_exporter をインストールするには、以下のコマンドを使用してください。

export DISTRO = SLE_15_SP4 # 自身の OS のバージョンに合わせて変更してください
zypper addrepo https://download.opensuse.org/repositories/server:/monitoring/$ DISTRO/server:monitoring.repo
zypper install prometheus-sap_host_exporter

インストール後は、次のように exporter を実行し、図 9 に示されているように、Unix ドメインソケットを経由して SAPControl Web サービスに接続できます。

./sap_host_exporter — sap-control-uds /tmp/.sapstream51213

図 9: SLES でプロセスとして実行されている sap_host_exporter サービス

これにより、デフォルトでポート 9680 の /metrics パスでメトリクスを公開します。

SAP アプリケーションサーバーが実行中の SAP EC2 インスタンスで SAP ホストエクスポーターをインストールするには、これらの手順を実行してください。

2.4 Prometheus エージェント

Prometheus は EC2 インスタンスからデータを収集し、AMP に保存します。したがって、このステップでは、リソースの使用量が少ない Prometheus のエージェントモードをインストールします。Prometheus に同梱されている UI 機能やアラート機能は必要ありません。また、AMP へのリモートライトを設定します。

Prometheus サーバーは任意のディレクトリにインストールできます。例えば /usr/bin です。この例では、以下のコマンドで示したように、SLES for SAP 15 SP4 オペレーティングシステムに Prometheus v2.49.1 をインストールします。
Prometheus がインストールされたディレクトリに移動します。

wget https://github.com/prometheus/prometheus/releases/download/v2.49.1/prometheus-2.49.1.linux-amd64.tar.gz

tar xvfz prometheus-*.tar.gz

cd prometheus-*

Prometheus のインストールディレクトリ内に、YAML 形式で記述された設定ファイルprometheus.ymlがあります。ファイルの中身は次のようになっています。

# グローバル設定
global:
scrape_interval: 15s # スクレイプ間隔を 15 秒に設定します。デフォルトは 1 分です。
evaluation_interval: 15s # 15 秒ごとにルールを評価します。デフォルトは 1 分です。
# scrape_timeout はグローバルのデフォルト (10 秒) が設定されています。

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"

# 1 つのエンドポイントのみをスクレイピングする構成:
# ここでは Prometheus そのものです。
scrape_configs:
# ジョブ名がラベル `job =` として、この構成からスクレイピングされた全てのタイムシリーズに追加されます。
- job_name: "EC1-CS"

# metrics_path はデフォルトで '/metrics' に設定されます
# scheme はデフォルトで 'http' に設定されます。

static_configs:
- targets: ['localhost:9664','localhost:9100']

remote_write:
- url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces//api/v1/remote_write
sigv4:
region:
queue_config:
max_samples_per_send: 1000
max_shards: 200
capacity: 2500

私たちのユースケースに合わせるために、prometheus.yml ファイルで次の変更を行う必要があります:

job_name を、観測性ダッシュボード上でこのシステムを識別できるような名前に変更してください。例えば、SAP Application Server EC2 インスタンスについては「SAP S41 App Server」、SAP 中央サービス EC2 インスタンスについては「S41 ASCS/ERS」などです。
targets の : 設定を変更します。ホストは Exporter が実行されているホストを、ポートは Exporter がメトリクスを公開しているポートを指定します (例: localhost:9100)。上記のように、複数のターゲットを設定できます。例えば、SAP Application Server EC2 インスタンスの yml ファイルの設定では、SAP Host Exporter と Node Exporter からメトリクスをスクレイピングするために、’localhost:9680′ と ‘localhost:9100’ の 2 つのターゲットエントリがあります。
yml ファイルの最後に remote_write URL セクションを追加します。remote_write URL は、ステップ 1 で AMP 作成時に控えた URL に、AWS リージョン (例: us-east-1) を指定して変更してください。

prometheus.yml ファイルを更新したら、以下のコマンドを実行してエージェントモードで Prometheus を実行します。

./prometheus --config.file =./prometheus.yml --enable-feature = agent &

各 SAP コンポーネントの正しいポートを特定し、すべての EC2 インスタンスでこれらの手順を実行してください。

このタイミングで、データが AMP に送信されており、Amazon Managed Grafana の構成が可能になりました。

Prometheus Agent Mode

エージェントモードでは、リモートライトユースケースに最適化されています。クエリ、アラーティング、ローカルストレージが無効化され、カスタマイズされたタイムシリーズデータベースのライトアヘッドログに置き換えられます。その他の機能(スクレイピングロジック、サービスディスカバリ、関連設定) は同じままです。

エクスポーターを systemd サービスとして有効化する

これらのエクスポーターやエージェントを起動時に自動起動するように設定することをお勧めします。これは systemctl を使って行うことができます。以下が HA クラスターの例です。

systemctl --now enable prometheus-ha_cluster_exporters

他のサービスについても同じように設定できます。systemctl についての詳細は、SUSE のドキュメントを参照してください。

AMG の設定と監視ダッシュボードのセットアップ

AMG は、可視化ツールの人気製品である Grafana のフルマネージドサービスで、Amazon Managed Prometheus と連携することで、メトリクス、ログ、トレースに対するクエリ、可視化、アラートを行えるようになります。

この項では、Amazon Managed Grafana (AMG) の構成方法と SAP S/4HANA の監視ダッシュボードのセットアップ方法について説明します。
この項に記載されている手順は、Amazon Managed Service for Prometheus (AMP) サービスで収集された SAP のメトリクスに対する監視ダッシュボードをセットアップするために必要な AMG サービスの構成手順を示しています。

3.1 Amazon Grafana でワークスペースを作成する

Amazon Managed Grafana において Amazon Managed Prometheus をデータソースとして、新しいワークスペースを作成しましょう。Amazon Managed Grafana におけるワークスペースは、Grafana サーバーの論理的なユニットです。

AWS コンソールから Amazon Grafana サービスを開き、図 10 のように希望のエイリアスでワークスペースを作成します
AWS IAM Identity Center(ID センター) と SAML の間から、好みの認証アクセス方法を選んでください
オプションですが、推奨されるのは、SAP VPC 内のデータソースに接続する場合、ワークスペースから SAP VPC への VPC 接続を選択すること (これにより、パブリックインターネット経由のリクエストを回避できます)
Service Managed と Customer Managed の間から、権限管理方式を選んでください
最後に、図 11 に示されているように、Data Sources のリストから Amazon Managed Prometheus をデータソース名として選択します

図 10: AMG ワークスペースエイリアス

図 11: AMG のデータソース名

数分かかりますが、この段階で Grafana ワークスペースの準備が整いました。

3.2 Amazon Grafana ワークスペースを構成する

AMG でワークスペースの作成が完了したら、次は Amazon Managed Service for Prometheus (AMP) との統合です。ステップには Grafana ワークスペースコンソールでの管理者権限によるユーザー作成、Grafana ワークスペースコンソールでの AMP データソースの構成、Grafana ワークスペースコンソールへの監視用ダッシュボードのインポートが含まれます。

AMG では、Grafana コンソールへのアクセスの認証基盤として、AWS IAM Identity Center と SAML を認証基盤として利用できます。AMG ワークスペースのアクセスと Grafana ワークスペースコンソールの設定には、管理者ユーザーを設定する必要があります。ユーザーは AWS IAM Identity Center または外部の ID プロバイダに設定できます。この記事では、AWS IAM Identity Center にユーザーを設定しました。AWS IAM Identity Center に設定されたユーザーには、 AWSGrafanaAccountAdministrator と AWSSSODirectoryAdministrator のポリシーが必要です (こちらを参照)。オプションのロールを確認し、必要に応じて割り当ててください。ワークスペースへのアクセスの認証方式として SAML を選択した場合は、記載された手順に従ってください。

ユーザーの作成後、Amazon Managed Grafana (AMG) ワークスペースにユーザーを割り当て、Grafana コンソールを設定するユーザーに対して「管理者権限を付与する」アクションを実行します。実行するには、AWS コンソールから AMG を開き、「すべてのワークスペース」をクリックし、新しく作成したワークスペースをクリックします。認証タブ内で、AWS Identity Center でユーザーまたはグループを追加するか、SAML 設定を行います。ユーザーが追加されたら、そのユーザーを選択し、アクションロップダウンから「管理者権限を付与する」を選択します (図 12 参照)。この手順を完了すると、管理者権限を付与したユーザーは、このワークスペースの Grafana コンソールを管理者として利用できるようになります。

図 12: AMG 用の AWS IAM Identity Center ユーザー

Grafana ビューアユーザー

ダッシュボードの作成には Admin ユーザーのみを使用し、ダッシュボードの表示にはセキュリティおよびコスト最適化の観点から「ビューア」ユーザーの使用を推奨します。

Grafana ワークスペースコンソールの URL を取得します。これを行うには、AWS コンソール内の Amazon Grafana サービスを開き、全てのワークスペースをクリックし、新しく作成したワークスペースに関連付けられているワークスペース URL を見つけてください。図 13 のように表示されます。

図 13: Grafana ワークスペース URL の例

前のステップで管理者として構成したユーザー認証情報を使って、ワークスペース URL にアクセスし、AMG ワークスペースコンソールにログインします

Grafana ワークスペースコンソールにログインした後、「アプリ」->「AWS データソース」->「データソース」の順に選択し、Amazon Managed Service for Prometheus の中からステップ 1 で作成した Amazon Managed Prometheus ワークスペースをメトリクス収集用に選択します (図 14 の通り)。

図 14: Grafana ワークスペースのデータソース設定

Amazon Managed Prometheus ワークスペースをデータソースとして正常に追加できると、Administration -> Data sources タブに設定済みのデータソースとして表示されます (図 15 参照)。

図 15: AMG のデータソースとして AMP

3.3 SAP レポートをインポート

Grafana のダッシュボードは JSON 形式のレポートを使って作成できます。独自のレポートを作成するか、Grafana で提供されているレポートをインポートすることができます。このブログでは、インポートオプションを使用しており、使用するレポートは以下の通りです。

Node Exporter を使用した OS レベルのデータ (ID 1860)
ASCS/ERS 上で Pacemaker を実行している HA クラスター (ID 12229)
SAP Application Server (ID 12761)

AMG ワークスペースコンソールにログインし、ダッシュボードタブに移動します。図 16 のように、JSON レポートをアップロードするか、Grafana.com のレポート ID でインポートして、レポートをインポートしてください。

図 16: JSON アップロードまたは Grafana.com のダッシュボード ID を使用してダッシュボードをインポートする

すべてのレポートを追加した後、次のような画面が表示されます:

図 17: OS レベルのメトリクスダッシュボード
図 18: SAP ASCS/ERS HA クラスターダッシュボード
図 19: ノードがダウンしたときのマルチクラスター概要ダッシュボード
図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード
図 21: SAP アプリケーションサーバーディスパッチャーキューダッシュボード

図 17: OS レベルのメトリクスダッシュボード

図 18: SAP ASCS/ERS HA クラスターのダッシュボード

図 19: ノードがダウンしている場合のマルチクラスター概要ダッシュボード

図 20: SAP アプリケーションサーバーのステータスとプロセス概要ダッシュボード

図 21: SAP Application Server ディスパッチャーキューダッシュボード

AMG データソースとマルチクラウドダッシュボード

設定手順と図 22 に示されているように、Amazon CloudWatch、Amazon Athena などの他のデータソースを指定できます。これにより、SAP 以外のシステムだけでなく、ハイブリッドおよびマルチクラウド環境のダッシュボード化が可能になります。

図 22: AMG のデータソース

結論

Prometheus と Grafana は、SAP ランドスケープを監視・可視化するための強力なオープンソースツールです。
AWS での AMP と AMG の利用により、組織はよりよい自動化とセキュリティポスチャを得ることができます。
SAP の可観測性ダッシュボードを構築するための AMP と AMG を使用することで、Prometheus と Grafana のデプロイやインフラストラクチャの管理、定期的なソフトウェアアップデートの実施などの負担なく、一元的に可観測性ダッシュボードを確認できます。

この記事では、Amazon Managed Prometheus と Amazon Managed Grafana を使用して、SAP S/4HANA システムの SAP 監視ダッシュボードをセットアップする方法について説明しました。
また、Grafana の他のデータソースを使用して、非 SAP システムを組み込む方法についても説明しました。
AMG、ダッシュボードの種類、セキュリティ機能の詳細については、AWS ドキュメンテーションを確認してください。

翻訳は Partner SA 松本が担当しました。原文はこちらです。

Amazon Web Services ブログ