Adobe Experience Manager(AEM)Assets の観点から見た場合、監視の際には、以下のプロセスおよびテクノロジについての観察および報告をおこなう必要があります。
システム CPU
システムメモリ使用量
システムディスク IO および IO 待機時間
システムネットワーク IO
以下のための JMX MBean:
OSGi コンソールヘルスチェック
通常、AEM Assets の監視には、ライブ監視と長期的監視の 2 種類があります。
開発のパフォーマンステストの段階、または高負荷な状態になったときに、環境のパフォーマンス特性を把握するためにライブ監視を実行する必要があります。通常、ライブ監視はいくつかのツールを使用して実行します。以下にお勧めのツールを示します。
ビジュアルVM:Visual VMを使用すると、CPU使用率、Javaメモリ使用量など、Java VMの詳細な情報を表示できます。また、インスタンス上で実行されるコードをサンプリングおよび評価できます。
Top:Top は、CPU、メモリ、IO 使用量などの使用量統計を表示するダッシュボードを開く Linux コマンドです。インスタンスの状況の概要を示します。
Htop:Htop は、インタラクティブなプロセスビューアです。Top が提供する情報に加えて、詳細な CPU およびメモリ使用状況が表示されます。Htopは、yum install htop
またはapt-get install htop
を使用して、ほとんどのLinuxシステムにインストールできます。
Iotop:Iotop は、ディスク IO 使用量の詳細なダッシュボードです。ディスク IO を使用するプロセス、およびそのプロセスによる使用量を示すバーやメーターが表示されます。iotopは、yum install iotop
またはapt-get install iotop
を使って、ほとんどのLinuxシステムにインストールできます。
Iftop:Iftop は、イーサネット/ネットワークの使用量についての詳細情報を表示します。Iftop では、イーサネットを使用するエンティティについての通信チャネルごとの統計情報、および使用されている帯域幅の量が表示されます。iftopは、yum install iftop
やapt-get install iftop
を使って、ほとんどのLinuxシステムにインストールできます。
Java Flight Recorder(JFR):非実稼動環境で自由に使用できる、Oracle の市販ツールです。詳しくは、Java Flight Recorderを使用してCQランタイムの問題を診断する方法を参照してください。
AEM の error.log ファイル:システムでログに記録されたエラーの詳細を AEM の error.log ファイルで調査できます。tail -F quickstart/logs/error.log
コマンドを使用して、調査する必要のあるエラーを識別します。
ワークフローコンソール:ワークフローコンソールを使用して、遅れているワークフローや、停止しているワークフローを監視できます。
通常は、これらのツールを組み合わせて使用し、AEM インスタンスのパフォーマンスについて包括的に把握します。
これらのツールは標準的なツールです。アドビでは直接サポートしません。追加のライセンスは必要ありません。
AEM インスタンスの長期的監視では、ライブで監視されるのと同じ部分の長期にわたる監視をおこないます。また、環境に固有のアラートも定義します。
Splunk(TM)や Elastic Search/Logstash/Kabana(ELK)など、いくつかのログ集約ツールがあります。AEM インスタンスの稼動時間を評価するには、システムに固有のログイベントを理解し、それに基づきアラートを作成することが重要です。開発と運用に関する慣習を十分に理解しておくと、重要なアラートを生成するログ集計プロセスを調整する方法をより深く理解できます。
環境の監視には、以下の監視が含まれます。
それぞれの項目を監視するには、NewRelic(TM)や AppDynamics(TM)などの外部ツールが必要です。これらのツールを使用して、システム固有のアラート(システム利用率が高い、ワークフローのバックアップ、ヘルスチェック失敗、Web サイトへの不正なアクセスなど)を定義できます。アドビでは、特定のツールを推奨することはありません。ご自身に合ったツールを見つけ、説明した項目の監視に利用してください。
内部アプリケーション監視には、JVM などの AEM スタックを構成するアプリケーションコンポーネントの監視、コンテンツリポジトリの監視、およびプラットフォーム上に構築されたカスタムアプリケーションコードによる監視が含まれます。通常、SolarWinds(TM)、HP OpenView(TM)、Hyperic(TM)、Zabbix(TM)などの一般的な多くの監視ソリューションで直接監視できる JMX MBean を通して監視を実行します。JMX への直接接続をサポートしないシステムでは、JMX データを抽出して、それらのシステムがネイティブで理解できる形式で公開するシェルスクリプトを記述できます。
JMX MBean へのリモートアクセスは、デフォルトで無効になっています。JMXによる監視の詳細については、Monitoring and Management Using JMX Technologyを参照してください。
多くの場合、統計情報を効果的に監視するにはベースラインが必要です。ベースラインを作成するには、通常の動作条件の下で一定期間システムを監視し、通常の指標を特定します。
JVM 監視
他の Java ベースのアプリケーションスタックと同様に、AEM は基盤となる Java Virtual Machine から提供されたリソースを利用します。JVM により公開されているプラットフォーム MXBean によって、それらのリソースの多くの状態を監視できます。MXBean について詳しくは、プラットフォーム MBean サーバーおよびプラットフォーム MXBean の使用を参照してください。
JVMの基準パラメーターの一部を以下に示します。
メモリ
MBean: lava.lang:type=Memory
注意:この Bean から提供される情報の単位はバイトです。
スレッド
java.lang:type=Threading
AEM 監視
AEM も、JMX を通して一連の統計情報および操作を公開しています。これにより、システムヘルスの評価をおこない、ユーザーに影響を与える前に問題を特定できます。詳しくは、AEM JMX MBean のドキュメントを参照してください。
AEM で監視できるベースラインパラメーターをいくつか示します。
レプリケーションエージェント
MBean:com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
URL:/system/console/jmx/com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
インスタンス:1 つのオーサーインスタンスおよびすべてのパブリッシュインスタンス(フラッシュエージェント)
アラームしきい値:QueueBlocked
の値が true、または QueueNumEntries
の値がベースラインの 150%を超えた場合。
アラーム定義:システムにブロックされたキューが存在しており、レプリケーションターゲットがダウンしているか、または到達不能であることを示しています。多くの場合、ネットワークまたはインフラストラクチャの問題により過剰なエントリがキューに登録されています。それによってシステムのパフォーマンスに悪影響が生じる可能性があります。
注意:MBeanおよびURLパラメーターの場合は、を、監視 <AGENT_NAME>
する複製エージェントの名前に置き換えます。
セッションカウンター
org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
ヘルスチェック
操作ダッシュボードのヘルスチェックには、監視用の対応する JMX MBean があります。ただし、カスタムのヘルスチェックを記述して、追加のシステム統計情報を公開できます。
監視に役立つ、あらかじめ用意されたヘルスチェックをいくつか示します。
システムチェック
org.apache.sling.healthcheck:name=systemchecks,type=HealthChec
kレプリケーションキュー
org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
応答パフォーマンス
org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
クエリパフォーマンス
org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
アクティブなバンドル
ログエラー
org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
監視中に問題が発生した場合は、以下のトラブルシューティングを実行して、AEM インスタンスでよくある問題を解決できます。
OutOfMemoryError
ログを確認します。 詳しくは、メモリの問題の分析を参照してください。access.log
および error.log
ファイルで、不具合の発生した時刻付近のエントリを調査します。カスタムコードの異常の兆候となるパターンを探します。それらを監視するイベントのリストに追加します。