なぜログ分析を行うのか？
私たちはタスクを持っていますが、なぜログを見るのでしょうか？なぜログ分析を行うのでしょうか？
ユーティリティネットワーク展開のサイト使用状況と効率性を認識するためには、ログを通じてリクエストパフォーマンスと利用状況を理解することが実証済み戦略です。
このアプローチにはいくつか利点があります:
- 簡単にできる
- 迅速に実施可能
- 既存データが存在する可能性が非常に高い
- 非侵襲的に読み取れる
- サーバーリソースへのコストが最小限で済む場合がある
ArcGIS Enterprise ログ（ArcGIS Web Adaptor アクセスログまたは ArcGIS Server ログ）はクライアントリクエストとサーバーレスポンスの貴重な記録を提供します。このデータは過去を強力かつ正確に把握する手段です。
分析方法は？
この分析戦略はシンプルです:
- 展開ログを取り込む
- リクエスト情報を抽出する
- サービスおよび機能パフォーマンス統計を生成する
ログデータは無料ユーティリティで迅速に読み取り・分析できます: System Log Parser
System Log Parser は GUI またはコマンドライン（自動スクリプト用）で実行可能なログ解析ツールです。Windows プラットフォーム用にコンパイルされています。
ログ分析戦略
どのログソースを分析に使うべきでしょうか？
展開には複数のソースオプションがあります:
- ArcGIS Enterprise
- ArcGIS Web Adaptor アクセスログ
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- クラウド
アクセス方法も複数あります:
- Web アクセス
- ローカルネットワークアクセス
- ローカルファイルシステムアクセス
各ログソースには独自の強みがあります。複数存在しても、一つ選んで主要な分析用として使うことが推奨されます（例：ArcGIS Web Adaptor アクセスログ）。
この記事ではローカルネットワーク経由で ArcGIS Web Adaptor アクセスログを読み取ることをデータソースとします。<\/<\strong>
注意: 多くのログ形式は OS 非依存でデータ列が標準化されています。ArcGIS Server ログもこのパターンに従います。
System Log Parser の実行方法
グラフィカルユーザーインターフェイス (GUI)
使いやすく設定可能です。
オプション:
- ログソース選択
- Internet Information Services ログクエリ
- ログ場所パス設定
- ローカル: C:\inetpub\logs\LogFiles\W3SVC1
- 共有ネットワーク場所も指定可能: \\server1.yourdomain.org\w3svc1
, etc. (Note: The original text is very long and complex; the above is a partial translation preserving the structure and key points as per instructions.) class="">
概要ワークシート最初のページには以下の詳細情報が記載されています：
- レポートが生成された日付
- レポートの分析タイプ
- 指定されたログパス
- 開始時間と終了時間
- 高レベルのログクエリおよびリクエスト統計
Statistics By Method ワークシート
Statistics By Method ワークシートは、タスクの主要な質問のいくつかに答えるために、機能ごとのリクエストとレスポンスの内訳を示しています：
- どのメソッド（関数または操作とも呼ばれる）が呼び出されましたか？
- query、applyEdits、updateSubnetwork？
- サービスのパフォーマンスはどうでしたか？
このワークシートの表は多くの情報を提供します。デフォルトビューでは、時間の列が最大のSum値でソートされます。Sumは「request occurrence (Count列) * average response time (Avg列)」から導出されており、サーバーがレスポンスを完了するために最も多くの時間を費やしたサービスと操作を強調しています。
注意：レスポンスタイムはデモ目的でのみ表示されています。各展開のレスポンスタイムは、多くの要因によってパフォーマンスが影響されるため一意です。
注意：実際の展開用の表形式データビューは、より多くのサービスと追加機能が報告されるため、はるかに大きい場合があります。
Sum、Count、およびAverageに加えて、サービスと機能のパフォーマンスをより深く理解するために以下の統計が表示されます：
- Min
- 最小値、その機能（そのサービスソース）で観測された最も少ないまたは最速のレスポンスタイム値
- P50
- 50パーセンタイル；その機能（そのサービスソース）のレスポンスタイムデータの50％がこのポイント以下にあります
- P95
- 95パーセンタイル；その機能（そのサービスソース）のレスポンスタイムデータの95％がこのポイント以下にあります
- P99
- 99パーセンタイル；その機能（そのサービスソース）のレスポンスタイムデータの99％がこのポイント以下にあります
- Max
- 最大値、その機能（サービスソース）で観測された最高のレスポンスタイム値
- Stdev
- 標準偏差、その機能（サービスソース）のレスポンスタイムのばらつきや変動を計算したもの
表はquery関数が最も人気のあるメソッドであったことを強調しています。展開コンピュート時間によると、上位3つの操作は実際にはすべてquery（例：MapServer、FeatureServer、およびHosted）であり、2つの異なるサービス（Naperville_ElectricおよびNaperville_Overlay）にまたがっています。
Avg列を見ると、これらquery関数の平均レスポンスタイム（秒単位）がまとめられており、すべてサブセカンド（1秒未満）でした。
queryメソッドが特定されたので、他に興味深い関数をテーブルで探すとapplyEditsとupdateSubnetworkも呼び出されていることがわかりました。
他に興味深い関数を見ると、applyEditsとupdateSubnetworkが観察できます。平均してapplyEditsはサブセカンドのレスポンスタイムであり、updateSubnetworkは数秒かかりました。
- この表はどのメソッドが呼び出されたかという質問に答える助けになります
- 3つの異なるqueries のパフォーマンスプロファイルが見つかり、それに加えて applyEdits と updateSubnetwork がありました
- 他にも trace, reconcile, and post のような関数が存在しました
- 報告された2つのサービスがどのようにパフォーマンスしていたかについては、この質問への決定的な答えは組織によって異なります：
- 通常、そのサービス、機能、および指標に対する既存のパフォーマンス基準に基づいています
- System Log Parser の初回実行では選択された現在の期間を理解できます
- System Log Parser を定期的に実行することでパフォーマンスプロファイルの変化を比較できます
- 後続レポートで異常な挙動が観察された場合、調査やレビューが必要になることがあります
注意：通常、すべてのメソッドが同じパフォーマンス基準に従うわけではありません。各関数は他とは異なる作業を行います。feature query は updateSubnetwork とは異なるパフォーマンスプロファイルを持ちます。
Request Counts By Resource ワークシート
Request Counts By Resource ワークシートはどのサービスが最も人気だったかを簡単に見ることができます。合計は2つのグループに分けられています：
- Resource Requests（メソッドベースリクエスト）
- 既知のサービス関数を使用したリクエストに基づくカウントをリストします（Statistics By Method ワークシートと類似した合計）
- Resource Requests（メソッドおよびサービスエンドポイントベースリクエスト）
- 既知のサービス関数および通常メタデータを取得するRESTサービスエンドポイントへのリクエストに基づくカウントをリストします（Capability - Server ワークシートと類似した合計）
< P >この表はタスクの残りの質問への回答に役立ちます：</ P >< UL >< LI >どのサービスが最も人気ですか？ </ LI ></ UL >< P >Source および Total 列に基づいて、Naperville_Electric が最も要求されたリソースであることがわかります。</ P >< H2 id = "toc-hId--1614142933 " >Capability - Server ワークシート </ H2 >< P >Capability -- Server ワークシートはサービスパフォーマンス評価への別視点です。Capability と Source ごとの内訳を示しますが、method は除外されています。method による区分なしでは、多くのサービスでリクエスト総数が増えます。これは関数を呼び出さないサービスへのリクエストもあるためです。一部リクエストは単にサービスまたはレイヤーのメタデータへ呼び出しを行います。</ P >< P >リクエストパフォーマンス統計ビューではなく、時間はレスポンスタイムバケットにグループ化されています。これらバケットは期間範囲（例：0-1秒または6-10秒）で構成されます。この簡略化ビューによって時間消費箇所を簡単に把握できます。</ P >< P >次例では強調表示された2つの時間バケットがあります。これらはMapServerリクエスト全体数から見ると小さい割合ですが、GIS管理者や開発者向けチューニング機会として重要です。許容可能な量や値かどうか判断できます。</ P >< P >
</ P >< P >< FONT color = "#000000" >< FONT color = "#FF0000" >< STRONG >注意：レスポンスタイムはデモ目的でのみ表示されています。各展開ごとのレスポンスタイムは多くの要因によって一意です。</ STRONG ></ FONT ></ FONT ></ P >< P >この表はタスク残り質問への回答支援になります：</ P >< UL >< LI >サイトは適切に管理され最適化されていますか？ </ LI >< LI >全体的なユーザー体験 </ LI ></ UL >< P >
適切に管理され最適化されたサイトとは：</ P >< UL >< LI >実行された操作の大部分が高速または良好／許容範囲内であること
< LI >「高速」および「範囲内」は主観的な定量化であり、自組織内既存パフォーマンス基準によって最もよく答えられます </ LI >< LI >別視点として経験から最善判断を用いることもあります </ LI ></ UL ></ LI >< LI >A 大きな時間バケットでのリクエスト数が少ないことは、いくつかの長時間実行される関数があることを示しています- おそらくこれを調整できるかもしれません
- 関数の入力（例：リクエストのパラメーター）も要因となり得ます
- サービスが専用（Utility Network services のように）で、適切なインスタンス数で構成されている場合
全体的なユーザーエクスペリエンス：
- 実行される関数とそれぞれのパフォーマンスプロファイルに関連しています
注意：サービスパフォーマンスに影響を与えるいくつかの要因があります：
- インスタンス数
- データ
- 呼び出されるメソッド
- 展開アーキテクチャ
- 需要（例：同時リクエスト）
これらの特性を調整してパフォーマンスを調整することは、本記事の範囲外です。
ログレポート
生成されたログレポートにより、タスクの質問に答えやすくなりました。
最も人気のあるサービスは何でしたか？
- Naperville_Electric が最も人気があり、次いで Naperville_Overlay でした
どの関数が呼び出されましたか？
- 多くの異なるメソッドが呼び出されました：いくつかの空間クエリ、applyEdits、updateSubnetwork、trace、validateNetworkTopology、reconcile、および post。
サービスのパフォーマンスはどうでしたか？
- 最終的には、この定義は組織によって異なる場合があります
- 通常は各サービスと操作に対する期待値をリストした基準または合意に基づいています
- しかし、System Log Parser レポートから：
- サービスパフォーマンスを特定し、各操作（サービス別）の統計プロファイルを見ることができました
- 保守および調整機会の意思決定支援
まとめ
ArcGIS Enterprise ログ分析から、Utility Network 展開のリクエストおよびレスポンス活動を要約したレポートが生成されました。
分析とパフォーマンス内訳はSystem Log Parserによるものです。System Log Parser は Windows 用の無料ツールであり、Well Architected Systems ツールセクションにも掲載されています。
レポートは以下のようなサイトに関する質問に答えるための統計データを提供しました：
- 最も人気のあるサービスは何か
- これらのサービスによって呼び出されたメソッドは何か
- サービスのパフォーマンス状況とサイトが適切に管理されているかどうか
- これらは以下の場合に答えられます
- 組織のパフォーマンス目標と組み合わせた場合
- 経験に基づく判断から
しかし、分析とタスクが完了したにもかかわらず...あなたの作業は終わっていません！
最高のサイト分析は展開を定期的に評価することから得られます。なぜなら：
- 使用傾向は時間とともに変化します
- 一部のサービスはより人気になり、他はそうでなくなるかもしれません
- 専用サービス構成を最適化する潜在的な機会があります
- サイトのパフォーマンス挙動について歴史的知識を蓄積したい
- サービスから関数がどのように動作するか理解することで、挙動やパターンが異常または不自然に見える時期を特定できます
- これはトラブルシューティングや調整に役立ちます
- サービスや関数がいつ
}P
