セルフホスティング型Adobe Commerceのテレメトリとツールの監視

監視ツールを使用すると、すべてを常に監視するために誰かを支払わなくても、変更を検出できます。 ほとんどのツールでは、ハード ドライブの空き容量が不足するなど、しきい値に達した場合にアラートや通知を追加できます。 負荷テストの結果など、追跡および計算が必要な出力を提供するツールもあります。 どのツールにも目的があり、一貫して使用すれば、アプリケーションの管理に役立ちます。 すべてのツールには無料のオプションがありますが、サービスの支払いを覚えておくと、より迅速で信頼性の高いサポートが保証され、投資の価値がある場合があります。 New Relicは、より多くの機能とパワーを解き放つ無料版と有料版を提供するツールの一例です。 他にも DataDog やDynatraceなどがあります。 あなたのための良いオプションを見つけて、それを一貫して使用してください。

インフラストラクチャの監視

このコンテキストでは、インフラストラクチャという用語はかなり大まかに使用されています。 このトピックでは、サイトの動作に使用されるサーバー、プロセス、またはデバイスを意味します。 例：

しきい値を調査して、効果的なアラートを作成します。 ハードドライブの容量などの重要な項目に割り当てないでください。 状況が悪化するにつれて様々なグループに通知するために、いくつかの設定を行います。 例えば、ハードドライブがいっぱいになったときの一連のルールがあります。

チームに通知する方法は多数あります。信頼性が高く、多くのアラートが殺到しないように選択してください。 重要な場合は、アラートを予約することが重要です。そうしないと、過剰になるリスクが生じ、アラートを無視し始めます。

New Relic、DataDog、Dynatraceなどのほとんどのツールには、従うべき優れたテンプレートが多数あります。 時間をかけて、アプリケーションに最適な優れたアイデアを見つけましょう。 クラウドインフラストラクチャー上のAdobe Commerceを使用すると、プロジェクトがプロビジョニングされる際にアラートとトリガーが設定されます。 これにより、Adobeの実稼動サポートチームは、アップタイムと高可用性のモニタリングにツールを活用できるようになります。

ダッシュボードを使用すると、サイトの頻繁な、または重要な側面にすばやくアクセスできます。 ダッシュボードの項目は、ページビュー、ホストあたりの CPU 使用率、すべてのサーバーのリスト、ページの読み込み時間、トランザクション時間のほか、過去数日間の合成監視テストの結果からも構成できます。 これらのダッシュボードは、問題が発生した場合に迅速なトリアージを行ったり、異なるユーザーエクスペリエンスに対して異なるダッシュボードを設定したりできるように構築する必要があります。 複数のダッシュボードを設計して、アプリケーションの監視をリアルタイムで確認できることを願っています。 特にプロジェクトの所有者やマネージャーからサイトの運用方法を尋ねられた場合、それは非常に満足です、そしてあなたは時間ではなく数秒で答えを見つけることができます。

ログの集約とローテーション

ログファイルは、実行に時間がかかりすぎる場合に、リクエストまたは MySQL ログを処理するアプリケーションサーバーで見つかります。 ログの難しい点は、ログが相互に分離していて、すべてを見つけることができるので、各ログから情報を解析するのは面倒なことがあります。 この問題は何年も前に、と呼ばれる技術を使用して解決されました ログの集約. これにより、すべてのログの場所からログファイルが取得され、一元化された場所にプッシュされます。 移動した情報は、ソフトウェアによって読み取られ、情報の検索、フィルタリングおよびレビューを行うことができます。 このプロセスを正しく行うためには注意が必要です。 多くの選択肢がありますが、運が良ければ、New Relicなどのログファイルをモニタリングツールで読み取って集計できます。 優れたツールを見つけることで、将来、計り知れないほどの時間を節約できます。 サイトの実行と運用に必要な処理をすべて行うサーバーが 1 つしかない場合を除き、ログの集約は不可欠です。 これは、DDoS 攻撃を受けている場合や、正当なトラフィックスパイクが発生している場合、または特定のリクエストが失敗する理由を調査する場合に特に役立ちます。

ログのもう 1 つの重要な要素は、ローテーションが確実におこなわれるようにすることです。 これは、歴史的には次のものに関係します run-away logs これにより、誤ってハードドライブがいっぱいになり、サイトがダウンする可能性があります。 ログファイルが特定のサイズ（1 GB など）に達した場合に、バージョンのログローテーションが発生することがあります。 などのサーバーレベルのツールがあります logrotate 自動的に削除できます。 例えば、1 GB を超えると過度に大きなログファイルを削除したり、90 日を超えるログファイルを削除したりできます。 ログポリシーを定義するので、リソースの制限事項を理解することが重要です。

マルウェア スキャン

Adobe Commerceを専門とする多くの Web サイトホスティング会社は、既知の悪用とマルウェアのライブラリを持っています。 自動またはリクエストに応じてスキャンを提供する必要があります。 これらが有効な場合、それらは反動的であり、新しいマルウェアが検出された場合にのみ機能します。 コードとデータベースを調べて、既知のマルウェアを探すことができるプロアクティブなツールを用意することをお勧めします。 次のようなオプションを使用できます MageReport, サンセック、または Magento マルウェア スキャナ. 外部からリモートスキャンを実行することも、サーバに設定された後にプロアクティブに更新/スキャン/監視することもできます。 Sansec などの提供されるソリューションを選択すると、ライブラリがインストールされ、何千ものサイトを監視するので、ライブラリが常に更新されるので、これらは優れたオプションになります。 新しいマルウェアが検出されると、監視しているすべてのプロジェクトが情報のメリットを享受し、検出された場合はアラートが表示されるようになります。

考慮すべきいくつかの無料バージョンがありますが、マルウェアの場合は、実際に有料のソリューションを検討する必要があります。 これは、サイトが数分間と数か月間の間で感染する程度の違いがあります。 サイトで悪用すると非常に頭痛が生じますが、これはサービスの料金を支払うことを検討する必要がある領域の 1 つです。

Site-Wide Analysis Tool のAdobe

Site-Wide Analysis Tool は、プロアクティブなセルフサービスツールで、Adobe Commerce インストールのセキュリティと操作性を確保するための詳細なシステムインサイトおよびレコメンデーションが含まれている中央リポジトリです。 24 時間 365 日、パフォーマンスの監視、レポート、アドバイスをリアルタイムで行うことで、潜在的な問題を特定し、サイトの正常性、安全性、アプリケーションの設定をより明確に把握します。 これにより、解決時間が短縮され、サイトの安定性とパフォーマンスが向上します。

Site-Wide Analysis Tool のRecommendations ページには、サイトで検出された問題に対処するためのベストプラクティスに基づく推奨事項が一覧表示されます。 レコメンデーションは、PO が重要かつ P4 が低い P4 に対する優先度 PO で並べ替えられます。 結果には、説明、推奨事項、サイトへの影響、根本原因、シナリオ/前提条件、予想される結果、使用するツールが含まれます。

サイトのパフォーマンスを向上させるためのベストプラクティスについて説明します。 優先度に従ってリストされたレコメンデーションを追跡し、実装します。

プロジェクトにインストールする方法については、次を参照してください。 Site-Wide Analysis Tool インストールガイド.

SSL 監視

プロジェクトで忘れられる項目の 1 つに、SSL 証明書があります。 年に一度しか注意が必要ないので、忘れるのはとても簡単です。 セキュリティ証明書の有効期限が切れると、最新のブラウザーで警告が表示されたり、サイトでのページの表示が拒否されたりする場合があります。 このような問題が発生した場合、お客様はメールの送信またはサポートへの電話を開始でき、問題が解決されるまで操作できない場合があります。 毎分カウントされるので、有効期限を認識しておくことが前もって来ており、更新されていることを確認することが、サイトを立ち上げて実行し続けるために最も重要です。 SSL 監視を実行する方法は多数あります。 Pingdom、Keychest、Sucuri などの無料または低コストのツールを使用して、サイトに合成監視ツールを使用することを検討し、SSL 証明書の有効期限アラートを提供するサービスを購読することもできます。 これらのシンプルなツールにより、サイト証明書が有効になり、顧客のダウンタイムのリスクを軽減できます。

自動テスト

機能テストや単体テストなどの自動テストを実行すると、多くの場合、新しく導入されたコードの問題を検出できます。 Adobe Commerceと単体テストは通常、カバレッジが 50% 未満なので、これらのテストではすべてをカバーできない場合があります。 記述やテストを避けるべきであるという意味ではありません。 これらのツールは、コミットされるすべてがデフォルトの悪影響や、開発チームが作成するカスタムテストに影響を与えないという、別のレイヤーの安全とセキュリティを追加するために用意されています。 各デプロイメントでこれらのテストを実行すると、重大な問題が早期に発見され、実稼動環境への移行が許可されなくなります。

負荷テストは、正しく行うことが難しい場合があります。 複雑さの多くは、フロントエンドの使用方法と実装方法に起因します。 サイトにヘッドレスフロントエンドがある場合は、GraphQL API と REST API の読み込みテストが必要になることもあります。 負荷テストを行う方法は、お客様と DevOps チーム次第です。 できるだけ早く実行する各負荷テストが、プロジェクトのステータスへのインサイトを提供することを認識しておく必要があります。 また、負荷テストの結果に大幅な変更があるかどうかを確認するための、今後のテストに関するベンチマークも提供します。 そうでない場合は、それが否定的であれば、最新のコード変更を確認し、パフォーマンスに影響を与えるセクションを探して改善する良い機会となります。

Adobe Commerceには、単体テストの実行方法を理解するのに役立つ優れたガイダンスがあります。次を参照してください。 PHP 単体テスト が含まれる アプリケーションテストガイド （Adobe Developerのドキュメントサイト内）。

機能テストについて詳しくは、こちらを参照してください。 機能テストフレームワークの概要.

自己ホスティングリソース