گزارش‌گیری (Logging) متمرکز در توزیع نهایی وب اپلیکیشن ها – راهنمای جامع

در آخرین بخش از سلسله مطالب راهنمای توزیع نهایی اپلیکیشن‌های وب به معرفی مفهوم گزارش‌گیری متمرکز می‌پردازیم. گزارش‌گیری متمرکز روشی عالی برای گردآوری و بصری‌سازی گزارش (log) ها از سرورهای مختلف محسوب می‌شود. به طور کلی راه‌اندازی یک سیستم گزارش‌گیری عالی به اندازه داشتن یک سیستم پشتیبان‌گیری و نظارتی اهمیت ندارد؛ اما زمانی که تلاش می‌کنید تا روندهای رخ داده در اپلیکیشن یا مشکلات پیش آمده را شناسایی کنید، بسیار مفید خواهد بود.

در این راهنما یک استک ELK که اختصاری برای Elasticsearch, Logstash, و Kibana است، راه‌اندازی می‌کنیم که سرورها را طوری پیکربندی می‌کند که اپلیکیشن ما لاگ‌های خود را به سرور گزارش‌گیری ارسال می‌کند. همچنین فیلترهای Logstash را تنظیم می‌کنیم که به تجزیه و سازماندهی لاگ‌ها می‌پردازند و امکان جستجو و فیلتر کردن ساده آن‌ها را فراهم می‌سازند. همچنین از بصری‌سازی‌های کیبانا کمک خواهیم گرفت.

پیش‌نیازها

اگر می‌خواهید از طریق نام دامنه به داشبورد گزارش‌گیری دسترسی داشته باشید باید یک رکورد A زیردامنه خود مانند logging.example.com ایجاد کنید که به آدرس IP عمومی سرور گزارش‌گیری اشاره می‌کند. همچنین می‌توانید از طریق آدرس IP عمومی نیز به این داشبورد دسترسی داشته باشید. اما توصیه می‌شود که وب‌سرور را طوری تنظیم کنید که از HTTPS استفاده کند و دسترسی به آن را با استفاده از یک VPN محدود سازید.

نصب ELK روی سرور logging

ELK را بر اساس راهنمای «نصب مجموعه ELK شامل Elasticsearch، Logstash و Kibana روی سرور اوبونتو» نصب کنید. اگر از یک DNS خصوصی برای resolve کردن نام‌ها استفاده می‌کنید مطمئن شوید که از گزینه 2 در بخش ایجاد گواهی‌های SSL استفاده می‌کنید. آن راهنما را تا بخش راه‌اندازی فوروارد کننده Logstash دنبال کنید.

راه‌اندازی فوروارد کننده Logstash روی کلاینت‌ها

روی سرورهای کلاینت خودمان که db1، app1، app2 و lb1 هستند با استفاده از بخش «راه‌اندازی فوروارد کننده Logstash» در راهنمای «نصب ELK» فوروارد کننده Logstash، و ارسال‌کننده log را نصب می‌کنیم.

زمانی که این کار انجام یافت می‌توانید از طریق آدرس شبکه عمومی سرور logging وارد Kibana شوید و گزارش‌های سیستمی (syslog) هر سرور را مشاهده کنید.

شناسایی گزارش‌هایی که باید گردآوری شوند

بسته به این که دقیقاً از چه نوع اپلیکیشن و چه نوع پیکربندی استفاده می‌کنید، ممکن است لازم باشد گزارش‌های مختلفی را در استک ELK خود گردآوری کنید. در مورد مثال ارائه شده در این راهنما، ما باید گزارش‌های زیر را گردآوری کنیم:

• گزارش‌های کوئری کُند MySQL (سرور db1)
• گزارش‌های دسترسی و خطای Apache (سرورهای app1 و app2)
• گزارش‌های HAProxy (سرور lb1)

دلیل این که ما این گزارش‌ها را انتخاب کردیم این است که هنگام عیب‌یابی یا تلاش برای شناسایی روندهای اپلیکیشن، اطلاعات مفیدی در اختیار ما قرار می‌دهند. البته سرورهای شما ممکن است گزارش‌های دیگری داشته باشند که لازم بدانید آن‌ها را گردآوری کنید؛ لذا این راهنما را صرفاً به عنوان یک نقطه شروع بنگرید.

راه‌اندازی گزارش‌های MySQL

گزارش‌های کوئری‌های کند MySQL معمولاً در مسیر var/log/mysql/mysql-slow/ قرار دارند. این فایل حاوی گزارش‌های کوئری‌هایی است که آن قدر طول کشیده‌اند که می‌توان آن‌ها را در دسته‌بندی «کوئری‌های کُند» قرار داد. شناسایی این کوئری‌ها برای بهینه‌سازی یا عیب‌یابی اپلیکیشن کاملاً ضروری است.

فیلم آموزش پایگاه داده MySQL مای اس کیو ال در فرادرس

کلیک کنید

فعال‌سازی گزارش کوئری کند MysQL

گزارش کوئری کند به طور پیش‌فرض فعال نیست و از این رو باید طوری MySQL را پیکربندی کنیم که این نوع از کوئری‌ها را گزارش دهد. بدین منظور فایل پیکربندی MySQL را باز کنید:

sudo vi /etc/mysql/my.cnf

خط کامنت شده «logslowqueries» را بابید و آن را به صوت زیر از حالت کامنت خارج کنید:

log_slow_queries = /var/log/mysql/mysql-slow.log

فایل را ذخیره ساخته و خارج شوید. اینک باید MySQL را ری‌استارت کنیم تا تغییرات اِعمال شوند.

sudo service mysql restart

اکنون MySQL کوئری‌هایی که اجرای آن‌ها مدت زیادی طول کشیده است در این فایل log خاص که در پیکربندی اشاره کردیم ذخیره می‌کند.

ارسال فایل‌های گزارش MySQL

ما باید فوروارد کننده Logstash را طوری پیکربندی کنیم که فایل log کوئری‌های کند MySQL را به سرور گزارش‌گیری ارسال کند. در سرور پایگاه داده به نام db1، فایل پیکربندی فوروارد کننده Logstash را باز کنید:

sudo vi /etc/logstash-forwarder.conf

در ادامه در بخش «files» زیر مدخل‌های موجود، برای ارسال گزارش‌های کوئری کند MySQL مقدار «mysql -slow» را وارد کنید:

,
   {
      "paths": [
         "/var/log/mysql/mysql-slow.log"
      ],
    "fields": { "type": "mysql-slow" }
   }

فایل را ذخیره ساخته و ببندید. بدین ترتیب فوروارد کننده Logstash طوری پیکربندی می‌شود که گزارش‌های کوئری‌های کند MySQL را به سرور گزارش‌گیری مرکزی ارسال کند و نوع آن‌ها را به صورت «mysql-slow» علامت‌گذاری کند که برای فیلتر کردن بعدی مناسب است. فوروارد کننده Logstash را ری‌استارت کنید تا آماده ارسال گزارش‌ها شود:

sudo service logstash-forwarder restart

گزارش کوئری‌های کند MySQL در یک قالب چندخطی است (یعنی هر مدخل می‌تواند در چند خط قرار داشته باشد) و از این رو باید codec چندخطی Logstash را فعال کنیم تا بتواند این نوع از log را پردازش کند. در سرور ELK که آن را سرور logging نیز می‌نامیم، فایل پیکربندی که در آن ورودی Lumberjack تعریف شده است را باز کنید:

sudo vi /etc/logstash/conf.d/01-lumberjack-input.conf

در تعریف ورودی lumberjack، خطوط زیر را اضافه کنید:

   codec => multiline {
      pattern => "^# User@Host:"
      negate => true
      what => previous
   }

فایل را ذخیره کرده و خارج شوید. بدین ترتیب Logstash هنگامی که با گزارش‌هایی که حاوی الگوهای خاصی هستند مواجه می‌شود از پردازنده گزارش چندخطی استفاده می‌کند. در ادامه فیلتر Logstash را برای گزارش‌های MySQL فیلتر می‌کنیم.

فیلتر Log برای MySQL

در سرور ELK یک فایل جدید برای افزودن فیلترهای گزارش MySQL به Logstash باز کنید. ما آن را 11-mysql.conf می‌نامیم، بنابراین به دنبال پیکربندی ورودی Logstash در فایل 01-lumberjack-input.conf می‌گردد:

sudo vi /etc/logstash/conf.d/11-mysql.conf

تعریف فیلتر زیر را اضافه کنید:

filter {
  # Capture user, optional host and optional ip fields
  # sample log file lines:
  if [type] == "mysql-slow" {
    grok {
      match => [ "message", "^# User@Host: %{USER:user}(?:\[[^\]]+\])?\s+@\s+%{HOST:host}?\s+\[%{IP:ip}?\]" ]
    }
    # Capture query time, lock time, rows returned and rows examined
    grok {
      match => [ "message", "^# Query_time: %{NUMBER:duration:float}\s+Lock_time: %{NUMBER:lock_wait:float} Rows_sent: %{NUMBER:results:int} \s*Rows_examined: %{NUMBER:scanned:int}"]
    }
    # Capture the time the query happened
    grok {
      match => [ "message", "^SET timestamp=%{NUMBER:timestamp};" ]
    }
    # Extract the time based on the time of the query and not the time the item got logged
    date {
      match => [ "timestamp", "UNIX" ]
    }
    # Drop the captured timestamp field since it has been moved to the time of the event
    mutate {
      remove_field => "timestamp"
    }
  }
}

فایل را ذخیره کرده و خارج شوید. بدین ترتیب مطمئن می‌شویم که Logstash، گزارش‌هایی از نوع mysql-slow را با الگوهای خاص Grok در دایرکتیوهای match فیلتر می‌کند. گزارش‌های نوع apache-access نیز به وسیله الگوی Grok ارائه شده از سوی Logstash تجزیه می‌شوند که با قالب ابتدایی گزارش‌های آپاچی همخوانی دارد؛ در حالی که گزارش‌های از نوع apache-error به وسیله فیلتر Grok تجزیه می‌شوند که برای مطابقت با قالب گزارش پیش‌فرض خطای آپاچی نوشته شده است.

برای این که این فلیترها را عملاً مورد استفاده قرار دهیم، باید Logstash را ری‌استارت کنیم:

sudo service logstash restart

در این زمان باید مطمئن شویم که Logstash به طور به درستی اجرا می‌شود، چون خطاهای پیکربندی موجب از کار افتادن آن می‌شوند.

همچنین باید مطمئن شویم که Kibana نیز می‌تواند گزارش‌های Apache فلیترشده را مشاهده می‌کند.

گزارش‌های آپاچی

گزارش‌های آپاچی معمولاً در مسیر var/log/apache2/ در فایل‌های access.log و error.log قرار دارند. گردآوری این گزارش‌ها به شما امکان می‌دهد که ببینید کدام آدرس‌های IP به سرورهای شما دسترسی دارند و چه چیزی درخواست می‌کنند و این که کدام سیستم‌های عامل و کدام مرورگرهای وب از وب‌سایت شما استفاده می‌کنند. همچنین هر پیام خطایی که وجود داشته باشد گزارش می‌شود.

ارسال فایل‌های گزارش آپاچی

ما باید فوروارد کننده Logstash را طوری پیکربندی کنیم که گزارش‌های دسترسی و خطای آپاچی را به سرور گزارش‌گیری ما ارسال کند. در سرورهای اپلیکیشن به نام‌های app1 و app2 فایل پیکربندی فوروارد کننده Logstash را باز کنید:

sudo vi /etc/logstash-forwarder.conf

بخشی که در ادامه آمده است را در بخش «files» زیر مدخل‌های موجود وارد کنید تا گزارش‌های آپاچی با انواع مناسب به سرور گزارش‌گیری ارسال شود:

,
    {
      "paths": [
        "/var/log/apache2/access.log"
       ],
      "fields": { "type": "apache-access" }
    },
    {
      "paths": [
        "/var/log/apache2/error.log"
       ],
      "fields": { "type": "apache-error" }
    }

فایل را ذخیره کرده و خارج شوید. بدین ترتیب فوروارد کنده Logstash را طوری پیکربندی کرده‌ایم که گزارش‌های دسترسی و خطای آپاچی را با انتساب انواع مناسب که برای فیلتر کردن گزارش‌ها استفاده می‌شود، به سرور مرکزی گزارش‌گیری ارسال کند.

اینک Logstash Forwarder را ری‌استارت کنید تا ارسال گزارش‌ها آغاز شود:

sudo service logstash-forwarder restart

اکنون همه گزارش‌های آپاچی، یک آدرس IP کلاینت خواهند داشت که با آدرس خصوصی IP سرور HAProxy برابر است، زیرا پراکسی معکوس HAProxy تنها روش دسترس به اپلیکیشن از سمت اینترنت است. برای تغییر این وضعیت و نمایش آدرس IP واقعی کاربری که به وب‌سایت دسترسی می یاد باید قالب گزارش پیش‌فرض HAProxy را تغییر دهیم تا از هدرهای X-Forwarded-For که HAProxy ارسال می‌کند استفاده کند. بدین منظور فایل پیکربندی آپاچی را باز کنید:

sudo vi /etc/apache2/apache2.conf

خطی که شبیه زیر است را پیدا کنید:

[Label apache2.conf — Original "combined" LogFormat]

LogFormat "%h%l%u%t \"%r\" %>s%O \"%{Referer}i\" \"%{User-Agent}i\"" combined

مقدار %h را با %{X-Forwarded-For}i جایگزین کنید تا به صورت زیر درآید:

[Label apache2.conf — Updated "combined" LogFormat]

LogFormat "%{X-Forwarded-For}i%l%u%t \"%r\" %>s%O \"%{Referer}i\" \"%{User-Agent}i\"" combined

فایل را ذخیره کرده و خارج شوید. بدین ترتیب فایل گزارش دسترسی آپاچی طوری پیکربندی می‌شود که به جای آدرس IP خصوصی سرور HAProxy، شامل آدرس IP منبع کاربران واقعی باشد. آپاچی را ری‌استارت کنید تا تغییرات پیاده‌سازی شوند:

sudo service apache2 restart

اینک آماده هستیم که فیلترهای گزارش آپاچی را به Logstash اضافه کنیم:

فلیترهای گزارش آپاچی

روی سرور ELK یک فایل جدید اضافه کنید تا فیلترهای گزارش‌های آپاچی را به Logsatsh اضافه کنید. ما این فایل را 12-apache.conf می‌نامیم و کاری می‌کنیم که به دنبال فایل پیکربندی ورودی Logstash (فایل 01-lumberjack-input.conf) بیاید:

sudo vi /etc/logstash/conf.d/12-apache.conf

خطوط تعریف زیرا را اضافه کنید:

filter {
  if [type] == "apache-access" {
    grok {
      match => { "message" => "%{COMBINEDAPACHELOG}" }
    }
  }
}
filter {
  if [type] == "apache-error" {
    grok {
      match => { "message" => "\[(?<timestamp>%{DAY:day} %{MONTH:month} %{MONTHDAY} %{TIME} %{YEAR})\] \[%{DATA:severity}\] \[pid %{NUMBER:pid}\] \[client %{IPORHOST:clientip}:%{POSINT:clientport}] %{GREEDYDATA:error_message}" }
    }
  }
}

فایل را ذخیره ساخته و ببندید. بدین ترتیب Logstash طوری پیکربندی می‌شود که گزارش‌های از نوع apache-access و apache-error را با الگوهای Grok خاصی که در دایرکتیوهای match متناظر نوشته شده است، فیلتر کند. گزارش‌های از نوع apache-access به وسیله الگوی Grok ارائه شده از سوی Logstash فیلتر می‌شوند که با قالب پیام گزارش پیش‌فرض آپاچی مطابقت دارد؛ در حالی که گزارش‌های از نوع apache-error به وسیله یک فیلتر Grok فیلتر می‌شوند که با استفاده از قالب پیش‌فرض گزارش‌های آپاچی نگارش یافته‌اند. برای این که این فیلترها کار کنند باید Logstash را ری‌استارت کنید:

sudo service logstash restart

در این زمان باید مطمئن شویم که Logstash به طور درستی کار می‌کند، چون خطاهای پیکربندی می‌توانند باعث از کارافتادن آن شوند. همچنین باید تأیید کنیم که Kibana می‌تواند گزارش‌های فیلتر شده آپاچی را مشاهده کند.

گزارش‌های HAProxy

گزارش‌های HAProxy به طور معمول در مسیر /var/log/haproxy.log قرار دارند. گردآوری این گزارش‌ها به ما اجازه می‌دهد که آدرس IP افرادی که به سرور توزیع بار مراجعه می‌کنند، مواردی که درخواست می‌کنند، این که کدام سرور اپلیکیشن درخواست آن‌ها را ارائه می‌کند و همچنین جزییاتی در مورد نوع اتصال آن‌ها را ببینیم.

ارسال فایل‌های گزارش HAProxy

ابتدا باید فوروارد کننده Logstash را طوری پیکربندی کنیم که گزارش‌های HAProxy را ارسال کند. در سرور HAProxy به نام lb1 فال پیکربندی فوروارد کننده Logstash را باز کنید:

sudo vi /etc/logstash-forwarder.conf

موارد زیر را به بخش «files» زیر مدخل‌های موجود اضافه کنید تا گزارش‌های HAProxy با نوع «haproxy-log» به سرور گزارش‌گیری ارسال شوند:

,
    {
      "paths": [
        "/var/log/haproxy.log"
       ],
      "fields": { "type": "haproxy-log" }
    }

فایل را ذخیره کرده و ببندید. بدین ترتیب فوروارد کننده Logstash طوری پیکربندی می‌شود که گزارش‌های HAProxy را ارسال کند و آن‌ها را به صورت «haproxy-log» علامت‌گذاری کند که باعث می‌شود این گزارش‌ها در موارد مناسب فیلتر شوند.

sudo service logstash-forwarder restart

فیلتر کردن گزارش HAProxy

روی سرور ELK یعنی سرور logging یک فایل جدید باز کنید تا موارد مورد نیاز برای فیلتر کردن گزارش‌های HAProxy را به Logstash اضافه کنیم. ما از فایلی به نام 13-haproxy.conf استفاده می‌کنیم به صورتی که در پیکربندی ورودی Logstash (فایل 01-lumberjack-input.conf) خوانده می‌شود:

sudo vi /etc/logstash/conf.d/13-haproxy.conf

تعاریف فیلتر زیر را اضافه کنید:

filter {
  if [type] == "haproxy-log" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} %{SYSLOGPROG}: %{IPORHOST:clientip}:%{POSINT:clientport} \[%{MONTHDAY}[./-]%{MONTH}[./-]%{YEAR}:%{TIME}\] %{NOTSPACE:frontend_name} %{NOTSPACE:backend_name}/%{NOTSPACE:server_name} %{INT:time_request}/%{INT:time_queue}/%{INT:time_backend_connect}/%{INT:time_backend_response}/%{NOTSPACE:time_duration} %{INT:http_status_code} %{NOTSPACE:bytes_read} %{DATA:captured_request_cookie} %{DATA:captured_response_cookie} %{NOTSPACE:termination_state} %{INT:actconn}/%{INT:feconn}/%{INT:beconn}/%{INT:srvconn}/%{NOTSPACE:retries} %{INT:srv_queue}/%{INT:backend_queue} "(%{WORD:http_verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version})|<BADREQ>|(%{WORD:http_verb} (%{URIPROTO:http_proto}://))" }
    }
  }
}

فایل را ذخیره ساخته و خارج شوید. بدین ترتیب Logstash طوری پیکربندی می‌شود که گزارش‌های از نوع haproxy-log را با الگوهای خاص Grok در دایرکتیو match متناظرش فیلتر کند. گزارش‌های از نوع haproxy-log به وسیله الگوی Grok خاص ارائه شده از سوی Logstash تجزیه می‌شوند که با قالب خاص گزارش پیش‌فرض HAProxy مطابقت دارد. برای این که این فیلترها عملیاتی شوند باید Logstash را ری‌استارت کنیم:

sudo service logstash restart

در این زمان باید مطمئن شویم که Logstash به طور صحیحی اجرا می‌شود، زیرا خطاهای پیکربندی می‌توانند آن را از کار بیندازند.

راه‌اندازی بصری‌سازی‌های Kibana

اینک که موفق شده‌ایم همه گزارش‌های لازم را در یک مکان مرکزی گردآوری کنیم می‌توانیم شروع به استفاده از Kibana برای بصری‌سازی آن‌ها بکنیم. بدین منظور می‌توانید از راهنمای «بصری‌سازی موقعیت با GeoIP و ELK» استفاده کنید.

سخن پایانی

با به پایان بردن این بخش از راهنما شما در واقع موفق شده‌اید سلسله مطالب راهنمای توزیع نهایی وب اپلیکیشن‌ها را کامل کنید. اگر همه بخش‌های این راهنما را دنبال کرده باشید، اینک می‌توانید مجموعه‌ای را که در بخش نخست این راهنما اشاره کردیم راه‌اندازی کنید.

این بدان معنی است که شما اینک یک اپلیکیشن دارید که اجزای آن را در سرورهای مختلف تجزیه کرده‌اید و به وسیله اجزای پشتیبان‌گیری، نظارت و گزارش‌گیری متمرکز از آن پشتیبانی می‌کنید. در این مرحله باید اپلیکیشن خود را به طور کامل تست کنید و مطمئن شود که همه اجزا مطابق انتظار عمل می‌کنند.

اگر این مطلب برایتان مفید بوده است، آموزش‌هایی که در ادامه آمده‌اند نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه‌نویسی
• آموزش پیاده سازی سیستم Logging در فریمورک لاراول (Laravel)
• مجموعه آموزش‌های ابزارها و راهکارهای مدیریت وبسایت‌ها
• تنظیم سرورهای محیط توزیع نهایی (Production) برای وب اپلیکیشن — راهنمای مقدماتی
• سرور پشتیبان برای یک وب اپلیکیشن — راهنمای جامع
• پشتیبان‌گیری و بازیابی فایل‌ها در سیستم‌عامل لینوکس
• آموزش استیمول سافت | کامل، رایگان و پروژه محور — به زبان ساده

==