[Osaka/Yokohama] Looking for infrastructure/server side engineers!

[Osaka/Yokohama] Looking for infrastructure/server side engineers!

[For 25 graduates] We have started recruiting for AI x virtual interview!

[For 25 graduates] We have started recruiting for AI x virtual interview!

[Deployed by over 500 companies] AWS construction, operation, maintenance, and monitoring services

[Deployed by over 500 companies] AWS construction, operation, maintenance, and monitoring services

[Successor to CentOS] AlmaLinux OS server construction/migration service

[Successor to CentOS] AlmaLinux OS server construction/migration service

[For WordPress only] Cloud server “Web Speed”

[For WordPress only] Cloud server “Web Speed”

[Cheap] Website security automatic diagnosis “Quick Scanner”

[Cheap] Website security automatic diagnosis “Quick Scanner”

[Low cost] Wasabi object storage construction and operation service

[Low cost] Wasabi object storage construction and operation service

[Reservation system development] EDISONE customization development service

[Reservation system development] EDISONE customization development service

[Registration of 100 URLs is 0 yen] Website monitoring service “Appmill”

[Registration of 100 URLs is 0 yen] Website monitoring service “Appmill”

[Suitable for local companies in China] China cloud / server construction, operation and maintenance

[Suitable for local companies in China] China cloud / server construction, operation and maintenance

[YouTube] Beyond official channel “Biyomaru Channel”

[YouTube] Beyond official channel “Biyomaru Channel”

【nginx】アクセスログの見方・設定・場所等を解説

皆様こんにちは。
寝たくない時に眠くなり、寝たい時に眠れない日々を過ごすシステムソリューション部所属のなかです。

今回は、Webサーバーの運用・保守といえば、確実に普段から触れる「アクセスログ」についてです。

その中で近年、世界的なシェア率ではついに Apache を越えた、nginx のアクセスログの見方・設定・場所等について解説したいと思います。

テスト環境

  • Linux 環境
    OS:AlmaLinux release 9. 2(VirtualBox 7.0.12 環境)
    ミドルウェア:nginx(1:1.20.1-14.el9_2.1.alma.1) ,HTTP(80)
  • ブラウザ
    Chrome:120.0.6099.217(Official Build)(64ビット)

テストページ

  • ドメイン:example.com
    ※ localhost 環境のため、hosts 書き換えでアクセス
  • HTML:index.html(トップページ用) , FAQ.html(FAQページ)

nginx のアクセスログの場所とログ例

デフォルト時のアクセスログの場所は「/var/log/nginx/access.log」となります。
まずアクセスログを軽く確認したい場合は、負荷の軽い less コマンドで開くのがオススメです。

less /var/log/nginx/access.log

1️⃣ URL:example.com (index.html) アクセス時のログ

192.168.33.1 - - [17/Jan/2024:08:47:50 +0000] "GET / HTTP/1.1" 200 37 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"

2️⃣ index.html(ページ内リンク)→ FAQ.html アクセズ時のログ

192.168.33.1 - - [17/Jan/2024:08:50:33 +0000] "GET /FAQ.html HTTP/1.1" 200 34 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"

ローカル環境に example.com で受け付けるサイトを建てて、ブラウザからアクセスした際のログを一部抜粋してみました。

example.com のトップページ(index.html)と、そこからFAQページ(FAQ.html)にアクセスした際に出力されるログです。

最初のIPアドレスと時刻は分かりやすいですが、以降が分かりにくいかなと思いますので、設定項目と比較して解説していきます。

ログフォーマット(ログ書式)の設定について

nignx の基本設定ファイルは、「/etc/nginx/nginx.conf」です。

この中で「log_format」ディレクティブ(設定)でアクセスログのフォーマット(書式)が定義されています。
※ アクセスログの出力先も定義されています。

less /etc/nginx/nginx.conf
~一部抜粋~
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

「log_format main 」という部分は、「main」という名前でフォーマット名を定義します。
その後にどの内容を出力するかのフォーマット(書式)、【 nginxの変数 + 表示を整えるためのハイフン・鉤括弧 等 】が並んでいる形です。

ログフォーマット 解説 / アクセスログ2️⃣との比較表

ログフォーマット 内容 アクセスログ2️⃣値 備考欄
$remote_addr 接続したIPアドレス 192.168.33.1 直接リクエストしたIPのため、
LB経由時はLBのIPが記録される。
- 区切り用ハイフン -
$remote_user Basic認証用に指定されたユーザー名 -(空白) Basic認証が使われるのは
開発中・メンテ中の事が多いため
基本的に空。
[$time_local] [処理完了時のローカル時刻+Timezone] [17/Jan/2024:08:27:22
+0000]
"+0000" の部分は時差
"+0000" はUTC(標準時)
"+0900" だとJST(日本時間)。
"$request" "リクエスト内容"
(メソッド, 要求パス, HTTPバージョン)
"GET /FAQ.html
HTTP/1.1"
"HTTP/1.1" で "FAQ.html" を"GET"(表示)
要求が来たことを意味します。
$status  "ステータスコード" 200 (成功)
$body_bytes_sent "クライアントに送信したバイト数" 34(byte) FAQ.html 等 メインデータ
(ボディ)部分のバイト数
"$http_referer" "リファラ"
(アクセス元URL)
"http://example.com/"
※トップページ
トップページ⇨FAQへのアクセス
"-"(空白)時は、
直接URL指定でのアクセス
"$http_user_agent" "ユーザーエージェント"
(ブラウザ・OS情報)
"Mozilla/5.0
(Windows NT 10.0;Win64;x64)
AppleWebKit/537.36
(KHTML, like Gecko)
Chrome/120.0.0.0 Safari/537.36"
Windows(OS)上、
Chrome系ブラウザからのアクセス
と読み取れます。
"$http_x_forwarded_for" "X-Forwarded-For"
(送信元IP
"-" ProxyやLB経由時、
その前の送信元IPアドレスが表示される。

得られる情報は多い

上記表をもっと簡潔にまとめると、下記の形になります。

  • IP : 192.168.33.1
  • ユーザー名 : 無(=認証していない)
  • アクセス時間 : UTC(日本時間だと+9時間)の2024年1月17日の08時27分22秒
  • アクセス先 : FAQのサイトページ(FAQ.html)
  • 接続状態 : 成功(200)
  • データ量 : 4B(バイト)
  • アクセス元 : トップページから(http://example.com)
  • 環境 : WindowsOSでChrome系ブラウザを使用(と宣言している)
  • LB や Proxyを経由しているか : 経由していない(空のため)

このような感じで、アクセスログからはかなり多くの情報を得ることができます。
これらを各種集計する事でアクセス傾向や、悪意あるアクセスかどうかの調査も行う事が可能となります。

デフォルトのログフォーマットでも大変便利なので是非活用していきましょう。

用語説明

Basic認証(Basic Authentication)

予め定めたユーザー名・パスワード名の入力を求める簡易的な認証機能です。
あくまで最低限の簡易的な物なので、構築時や緊急メンテナンス時など、一時的な用途で利用されます。

特にHTTP(80)通信だと、認証情報も平文(非暗号化)で送信されるのでセキュリティ的には弱い状態です。
一時的にでも利用する際には、サイトがHTTPS(443)通信のみとなっている状態が望ましいです。

リファラ(Referer)

アクセスされたページのリンクをもった直前のURLを指します。

Google の検索からトップページを開けば、Google の URL がログに記録され、サイトのトップページから FAQ を開けば、トップページの URL がログに記録される仕組みです。

この用語は本来、英単語「referrer」(意味:参照元)のスペルミスなのですが、仕様策定の際にスペルミス状態で決定したため、現在もそのまま使われている面白い歴史がある物です。

HTTPステータスコード(HTTP status codes)

HTTP(S)が通信を行った際に、処理結果を教えてくれるコードです。
全部を記載すると長くなるので割愛しますが、3桁目の数字が重要です。

  • 2xx :成功 レスポンス
  • 3xx :リダイレクト レスポンス
  • 4xx :クライアントエラー レスポンス
  • 5xx :サーバーエラー レスポンス

上記のように、3桁目の数字で概ね状態がわかります。

よく見る代表的なのは、200(成功),302(一時的なリダイレクト),404(存在しない場所へのアクセス不可),
503(サーバーが処理出来ない状態)といったコードです。

ユーザーエージェント(User-Agent)

用語としてのユーザーエージェントは、「Webサイトとの通信に使われているソフトウェア」を指すものです。

一般的にWebサイトへのアクセスはブラウザを使いますので、転じて「ユーザーが使用しているブラウザ(と合わせてOS等の情報)情報」として扱われています。

X-Forwarded-For

LB や Proxy が通信を行う場合に、送信元のIPを記載する項目(ヘッダー)です。

LB や Proxyといった クライアント(ユーザー)とWebサーバーの間に通信が挟まる場合は、Webサーバー側には LB や Proxy のIPは記録されますが、その前にいる送信元のクライアントのIPがわかりません。

そのため、LB や Proxy といった経由する通信時には、送信元IPを X-Forwarded-For の項目(ヘッダー)で保存するのが事実上の標準となっています。

余談:ログフォーマットで「main」と名前を定義する事について

なぜ名前を定義するのか?ということについてですが、「ログを出力する設定の際に、使用するログフォーマットは名前で指定する仕様のため」です。

less /etc/nginx/nginx.conf 
~一部抜粋~
access_log /var/log/nginx/access.log main;

「access_log」 ディレクティブ という、ログの出力先を指定する設定(ディレクティブ)で利用します。定義する項目と利用する項目が違うので、名前付けが必要になるわけです。

つまり定義は複数設定できます。

たとえば、不要な情報を減らして簡略したログフォーマットを「easy」という名前で定義したり、逆に詳細な情報が欲しい場合にログの項目(変数)を増やした物を「detailed」として定義できます。

なのでドメインや環境ごとに定義の使い分けをする事が出来ます。

access_log ディレクティブでフォーマット名を指定しないとどうなるか

もしかすると「フォーマット名の指定がない環境です」という方もいらっしゃるかもしれません。

この場合ですが、シンタックス(構文)チェックや動作上問題ありません。

この access_log ディレクティブでフォーマット名が指定されていない場合は、conf には書かれていませんが事前に組み込まれている「combined」 定義がデフォルト設定として使われます。

log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

上記の定義が利用されることはnginxの公式ドキュメントに記載されています。

内容としては、conf にデフォルトで書かれている「main」 とはフォーマットが微妙に違い、末尾に 「$http_x_forwarded_for」 が指定されていない物になります。

ちなみに、これは Apache でのデフォルト定義名 「combined」と同じ名前かつ出力される内容も同じ形の定義です。

最後に

Apache のログは普段よく触る事が多く、情報も数多く存在しています。

それに比べるとnginxの方は触る機会が少ないので、「なら情報をまとめた方が便利かな」と思い記事を書いてみました。

筆者個人としては Apache のログフォーマット指定よりわかりやすくて好きですね。

この記事を読んだ方に多少でも役に立つ知識となれれば幸いです。
ここまで読んで頂きありがとうございました。

参考資料

Module ngx_http_log_module
https://nginx.org/en/docs/http/ngx_http_log_module.html

Module ngx_http_core_module
https://nginx.org/en/docs/http/ngx_http_core_module.html

The 'Basic' HTTP Authentication Scheme
https://datatracker.ietf.org/doc/html/rfc7617

Referer
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Referer

HTTP レスポンスステータスコード
https://developer.mozilla.org/ja/docs/Web/HTTP/Status

User agent (ユーザーエージェント)
https://developer.mozilla.org/ja/docs/Glossary/User_agent

X-Forwarded-For
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-For

この記事がお役に立てば【 いいね 】のご協力をお願いいたします!
8
読み込み中...
8 票, 平均: 1.00 / 18
3,651
X facebook はてなブックマーク pocket
[2024.6.30 CentOS support ended] CentOS server migration solution

[2024.6.30 CentOS support ended] CentOS server migration solution

[For 25 graduates] We have started recruiting for AI x virtual interview!

[For 25 graduates] We have started recruiting for AI x virtual interview!

[Osaka/Yokohama] Actively recruiting infrastructure engineers and server side engineers!

[Osaka/Yokohama] Actively recruiting infrastructure engineers and server side engineers!

The person who wrote this article

About the author

Naka Tomo

Beyond mid-career in 2022 Belongs to
the System Solutions Department
LPIC-3 I have a 304 and AWS SAA I only
have three choices for regular drinks: milk, cola, and black tea.