लोड के तहत ऑनलाइन स्टोर - वेब क्लस्टर क्वालिटी मेट्रिक्स

लिखित, होस्टिंग में स्थानांतरित और एक बड़े ऑनलाइन स्टोर का शुभारंभ किया। रचनात्मक विचार - कार्यान्वयन के लिए तैयार हैं। हालांकि, आप समाधान की स्थिरता और ग्राहकों की संतुष्टि सुनिश्चित करने के लिए बहुत चिंतित हैं - ग्राहक, यहां तक ​​कि चोटी के भार के मामले में, पेज को लोड करने के लिए सफेद स्क्रीन से पहले 30 सेकंड तक इंतजार नहीं करना चाहिए और "दुर्भाग्य से, सिस्टम अतिभारित है या एक आंतरिक त्रुटि जैसे संदेश प्राप्त होता है। अपने आप को कॉफी डालें और फिर से संपर्क करने का प्रयास करें। ”



हम एक ऑनलाइन स्टोर पर आगंतुकों के लिए उच्च गुणवत्ता की सेवा को प्राप्त करने और बनाए रखने के लिए एक सरल और प्रभावी रणनीति को परिभाषित करेंगे - मुफ्त विश्लेषण और निगरानी उपकरणों का उपयोग करना।
यह लेख बिट्रिक्स-आधारित परियोजनाओं ( वेब-क्लस्टर वाले सहित), और नगनेक्स + अपाचे-php / php-fpm + MySQL पर आधारित अन्य समाधानों के लिए उपयोगी होगा।

लॉग में हिट फिक्सिंग - आप कर सकते हैं और चाहिए

प्रति दिन लाखों हिट्स की इकाइयों की ट्रैफ़िक वाली वेब परियोजनाओं के लिए, सभी ग्राहक कॉलों के लॉगिंग को दोनों पृष्ठों और संसाधनों (छवियों, आदि) से कॉन्फ़िगर करना संभव और आवश्यक है।
यह समझना अत्यंत महत्वपूर्ण है कि सिस्टम प्रत्येक ग्राहक के अनुरोध के बारे में जानकारी संग्रहीत कर सकता है और इस सुविधा को सक्षम कर सकता है - बस (यह एक नियमित उपकरण है)। यदि ऑनलाइन स्टोर एक वेब क्लस्टर पर तैनात है, तो इन उद्देश्यों के लिए समर्पित सर्वर पर रिमोट लॉगिंग को कॉन्फ़िगर करना आसान है, उदाहरण के लिए, syslog-ng।
सभी ग्राहक अनुरोधों को थोड़ा, प्रतिशत से लॉग करके, कॉन्फ़िगरेशन प्रदर्शन को कम कर देता है - हालांकि, आप ग्राहक सेवा की गुणवत्ता पर पूरी जानकारी और नियंत्रण रखते हैं, ऑनलाइन स्टोर की त्रुटियों और जमाव के लगभग सभी मामले दर्ज किए जाते हैं और विकास प्रक्रिया और सिस्टम प्रशासन के आगे के विश्लेषण और समायोजन के लिए उपलब्ध हैं। अन्यथा - आप जोखिम लेते हैं, आँख बंद करके आगे बढ़ते हैं, आप कह सकते हैं, स्थिति को नियंत्रित न करें।
दुर्भाग्य से और ऑपरेशन के दौरान अक्सर यह सुविधा चालू करने के लिए बहुत अधिक आलसी होता है (या इसके बारे में पता नहीं होता है), और परियोजना प्रबंधक ट्विटर से सहकर्मियों या बॉस :-) से लटका वेब समाधान के बारे में सीखता है, लेकिन आप उन कारणों का पता नहीं लगा सकते हैं जहां कहीं भी कोई त्रुटि तथ्य नहीं थे। तय किया और "ट्रेन छोड़ दी।"

जिसे ठीक करने की जरूरत है

सबसे पहले, आपको मानक लॉग प्रारूप nginx, apache, php-fpm को संशोधित करने की आवश्यकता है - और नीचे दिए गए प्रमुख प्रदर्शन संकेतक जोड़ें। प्रत्येक हिट के लिए निम्न डेटा रिकॉर्ड करना महत्वपूर्ण है (मानक डेटा को छोड़कर, जैसे अनुरोध URL, प्रतिक्रिया कोड, आदि):

अनुरोध निष्पादन समय

Nginx के लिए, यह $ request_time है। दो-स्तरीय कॉन्फ़िगरेशन के साथ, nginx + एपाचे या nginx + php-fpm के रूप में अच्छी तरह से nginx लॉग में $ upstream_response_time को ठीक करने के लिए उपयोगी है।

अपाचे के लिए, यह "% डी" है।

Php-fpm के लिए, यह "% {मिली} d" है।

अनुरोध प्रसंस्करण के दौरान पीक मेमोरी का उपयोग

यदि आप php-fpm का उपयोग करते हैं, तो लॉग में "% {बाइट्स} M" रखना उपयोगी है।

HTTP प्रतिक्रिया कोड

आमतौर पर, HTTP प्रतिक्रिया कोड डिफ़ॉल्ट रूप से लॉग में संग्रहीत किया जाता है। इस जानकारी को रखना महत्वपूर्ण है ग्राहक सेवा में त्रुटियां आमतौर पर 40x या 50x की प्रतिक्रिया कोड होती हैं (हम नीचे दिए गए और अधिक विस्तार से प्रतिक्रिया कोड का विश्लेषण करेंगे)।

अलग प्रदर्शन और कॉन्फ़िगरेशन लॉग

कभी-कभी अलग "प्रदर्शन" लॉग बनाने में सुविधाजनक होता है जो "मानक" लॉग के बगल में रहने वाले स्क्रिप्ट और शिखर मेमोरी उपयोग को चलाने के लिए खर्च किए गए समय के बारे में जानकारी संग्रहीत करता है। हम अक्सर निम्नलिखित विकल्पों का उपयोग करते हैं:

nginx:

log_format main '$remote_addr - $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

apache:

LogFormat "%t \"%r\" %>s %b child:%P time-> %D" timing

php-fpm:

access.format = "%R # %{HTTP_HOST}e # %{HTTP_USER_AGENT}e # %t # %m # %r # %Q%q # %s # %f # %{mili}d # %{kilo}M # %{user}C+%{system}C"


ऑफ़लाइन लॉग विश्लेषण

तो, आपने लॉग में ग्राहक के अनुरोधों के बारे में जानकारी दर्ज करने की प्रक्रिया का आयोजन किया है (वेब ​​क्लस्टर के मामले में, लॉग को केंद्रीय रूप से एक अलग मशीन पर एकत्रित किया जाता है, कहते हैं, syslog-ng)। सभी त्रुटियां और पृष्ठ हैंग हो जाते हैं (यहां तक ​​कि क्लाइंट के ब्राउज़र और वेब सर्वर के बीच धीमे चैनल के कारण) लॉग इन किया गया था। अब हमें यह सीखने की जरूरत है कि उनकी व्याख्या कैसे करें और उनकी उपस्थिति के कारणों को समाप्त करें।

आम प्रकार की त्रुटियां

PHP कोड या भाषा के मूल में त्रुटियों की स्थिति में, precompiler (सेगमेंटेशन फ़ॉल्ट) या ऑपरेटिंग सिस्टम में, स्थिति आमतौर पर 500 (आंतरिक सर्वर त्रुटि) दी जाती है। इस मामले में, अधिकांश वेब परियोजनाओं में, आगंतुक को नियमित रखरखाव पर एक पृष्ठ दिखाया जाता है (या कॉन्फ़िगर नहीं होने पर, एक तकनीकी त्रुटि संदेश :-))।
दो-स्तरीय कॉन्फ़िगरेशन में अपाचे या php-fpm ओवरलोड के दौरान: डेटाबेस या कोड में लंबे प्रश्नों के लिए, एक बाहरी सॉकेट एक्सेस किया जा रहा है, या बैकएंड पर श्रमिकों की संख्या (एपाचे / php-fp-fc प्रक्रियाओं की संख्या) वास्तविक लोड के अनुरूप नहीं है - फ्रंटेंड (nginx) को ठीक करेगा उनके लॉग पृष्ठ बैकएंड समय या त्रुटियों 502 खराब गेटवे, 504 गेटवे टाइमआउट से अधिक हो गए। इस मामले में, यदि लोड बैलेंसर का उपयोग नहीं किया जाता है, तो आगंतुक को आमतौर पर नियमित रखरखाव पर एक पृष्ठ दिखाया जाता है। एक बैलेंसर का उपयोग करते समय (उदाहरण के लिए, नेग्नेक्स में अपस्ट्रीम), क्लाइंट को पेज डिलीवरी का समय बस बढ़ जाएगा (जो लॉग में भी दर्ज किया जाएगा)।
यदि PHP स्क्रिप्ट मेमोरी से अधिक है, तो त्रुटि 500 ​​(आंतरिक सर्वर त्रुटि) लॉग की जाएगी।

कभी-कभी, हालांकि, आपको सचेत रूप से एप्लिकेशन से एक त्रुटि कोड देने की आवश्यकता होती है - इस मामले में, आप प्रसंस्करण के दौरान लॉग से इन प्रविष्टियों को केवल बाहर कर सकते हैं।

सामान्य तौर पर, अब हम जानते हैं कि ग्राहक को नियमित रखरखाव के बारे में एक पृष्ठ प्रदर्शित करने के तथ्य और अन्य त्रुटियां और हैंग लॉग में दर्ज किए जाते हैं और महत्वपूर्ण बात यह है कि, त्रुटि का कारण निर्धारित करना आसान हो गया है।

उपयोगी लॉग रिपोर्ट

अब आप विश्लेषण कर सकते हैं कि प्रति दिन हमारे ग्राहकों की सेवा के साथ क्या हुआ। ध्यान दें - नीचे दी गई स्क्रिप्ट लिस्टिंग को लॉग फ़ाइलों के एक विशिष्ट प्रारूप के अनुकूल किया जाता है, इसलिए उन्हें सबसे अधिक संभावना है कि आपको अपनी परियोजना के लिए अनुकूलित करना होगा, जिससे कठिनाइयों का कारण नहीं होना चाहिए।

एचटीटीपी और बैकएंड पर HTTP प्रतिक्रियाओं का हिस्टोग्राम

Total hits: 265532
200 : 264654, 99.67% ***************************************************************************************************
207 : 34, 0.01%
302 : 830, 0.31%
401 : 7, 0.00%
403 : 1, 0.00%
404 : 1, 0.00%
500 : 16, 0.01%

#!/bin/bash

TOTAL=`cat /var/log/nginx.access.log | wc -l`

echo "Total hits:" $TOTAL

cat /var/log/nginx.access.log | awk '{ hits[$14]++; } \
END {for (z in hits) {printf("%6s: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }'\
total="$TOTAL" - | sort -n



एक समान छोटे बैश / awk स्क्रिप्ट को अपाचे / php-fpm लॉग के लिए अनुकूलित किया जा सकता है। हम देखते हैं कि 99% से अधिक हिट सफल रहे (कोड 200), लेकिन 16 त्रुटियां थीं जो डेवलपर्स को (PHP लॉग्स में) से निपटना था और उन्हें ठीक करने के तरीकों की तलाश करना था - आखिरकार, ये नियमित रखरखाव के बारे में 16 पृष्ठ हैं :-)। हमारा लक्ष्य 0 50x प्रतिक्रिया कोड है।

फ्रंट-एंड और बैक-एंड पेज रनटाइम हिस्टोग्राम

Total: 386664
0 ms: 276203, 71.43% ***********************************************************************
100 ms: 81466, 21.07% *********************
200 ms: 13155, 3.40% ***
300 ms: 4282, 1.11% *
400 ms: 2183, 0.56%
500 ms: 1373, 0.36%
600 ms: 968, 0.25%
700 ms: 721, 0.19%
800 ms: 586, 0.15%
900 ms: 470, 0.12%
1000 ms: 398, 0.10%

#!/bin/bash

TOTAL=`cat /var/log/nginx.access.log | wc -l`

echo "Total:" $TOTAL

cat /var/log/nginx.access.log | awk -F'->' '{ $2=$2*1000; zone = int($2/100)*100; hits[zone]++; } \
END {for (z in hits) {printf("%8s ms: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }' \
total="$TOTAL" - | sort -n


हम देखते हैं कि ग्राहक अनुरोधों की भारी संख्या 500 एमएस से कम के समय के साथ दी गई थी। हालांकि, 398 हिट के साथ एक सेकंड से अधिक के लिए, आपको अच्छी तरह से समझने की आवश्यकता है। नेत्रहीन, यह तारांकन (एक तारांकन सेट है यदि मान 1% है) को देखने के लिए सुविधाजनक है और केवल उन्हें ही ध्यान में रखना चाहिए।

पृष्ठ या सेवाएँ कुछ सेकंड तक काम क्यों कर सकते हैं:
- डेटाबेस के लिए कॉल के परिणामों का कैशिंग उपयोग नहीं किया जाता है, या डेटाबेस को कॉल स्वयं अनुकूलित नहीं है।
- एक भारी विश्लेषणात्मक अनुरोध किया जा रहा है, उदाहरण के लिए, एक निश्चित अवधि के लिए एक निश्चित उत्पाद के आदेशों की संख्या। इस मामले में, कोई त्रुटि नहीं है, विश्लेषण से इस तरह के अनुरोध को बाहर करना बेहतर है (उदाहरण के लिए, वे admin.myproject.ru प्रबंधन डोमेन से आ सकते हैं)।
- स्क्रिप्ट कोड एक बाहरी संसाधन को संदर्भित करता है जो जमे हुए है (आरएसएस फ़ीड, बाहरी प्राधिकरण, आदि)।
यहां सामान्य नियम यह है कि ऐसे "जोखिम भरे" बाहरी संसाधनों को या तो एक अलग स्ट्रीम (क्रोन) में या क्लाइंट के ब्राउजर से एसिंक्स के माध्यम से एसिंक्रोनस रूप से प्रतिक्रिया परिणामों को कैशिंग किया जाता है। यानी भले ही कोई बाहरी संसाधन अनुपलब्ध हो - वेब पेज को विज़िटर को एक सेकंड से भी कम समय में (और पृष्ठ के सावधानीपूर्वक लोड किए गए हिस्सों को) डिलीवर करना चाहिए।

बैकएंड स्क्रिप्ट द्वारा मेमोरी उपयोग का हिस्टोग्राम - php-fpm

Total hits: 265562
0 KB: 25, 0.01%
4000 KB: 16, 0.01%
6000 KB: 67094, 25.26% *************************
7000 KB: 123746, 46.60% **********************************************
8000 KB: 61102, 23.01% ***********************
9000 KB: 3453, 1.30% *
10000 KB: 1263, 0.48%
11000 KB: 890, 0.34%
12000 KB: 826, 0.31%
13000 KB: 917, 0.35%
14000 KB: 1129, 0.43%
15000 KB: 1125, 0.42%
16000 KB: 936, 0.35%
17000 KB: 798, 0.30%
18000 KB: 631, 0.24%

#!/bin/bash

TOTAL=`cat /var/log/php.access.log | wc -l`

echo "Total hits:" $TOTAL

cat /var/log/php.access.log | awk -F# '{ zone = int($11/1000)*1000; hits[zone]++; } \
END { for (z in hits) {printf("%8s KB: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }' \
total="$TOTAL" - | sort -n



यह देखा जा सकता है कि अधिकांश वेब सॉल्यूशन स्क्रिप्ट 6-8 एमबी मेमोरी की खपत करते हैं, जो पर्याप्त नहीं है। अक्सर, हालांकि, "थोड़े समय में" विकसित करते समय, स्क्रिप्ट प्राप्त की जाती हैं जो 500MB या कुछ गीगाबाइट मेमोरी का उपभोग करती हैं - जो सर्वर को फ्रीज, स्वैप और सिस्टम को अस्थिर करने का कारण बनता है। उसी समय, ग्राहक नियमित रखरखाव के बारे में पृष्ठों को "पकड़" सकते हैं। 64 एमबी के भीतर, इस हिस्टोग्राम का विश्लेषण करना और पन्नों द्वारा खपत की गई मेमोरी की मात्रा को अनुकूलित करने के लिए डेवलपर्स के लिए टीके लगाना महत्वपूर्ण है। इस प्रकार, धीरे-धीरे, सिस्टम मेमोरी की एक निश्चित रूप से अनुमानित मात्रा का उपभोग करेगा और आप यह सुनिश्चित करेंगे कि यह अचानक "हाइबरनेट" कई दसियों मिनटों तक नहीं होगा।

अधिकतम मूल्य

इस पर आंकड़े प्राप्त करना भी उपयोगी है:
- प्रति दिन सबसे धीमे पृष्ठों में से शीर्ष
- प्रति दिन स्मृति के सबसे भयानक पन्नों में से शीर्ष

#!/bin/bash

echo "Max today slow times in php access logs: "

cat /var/log/php.access.log | awk -F'#' '{ print $10" "$2" "$1" "$6" "$7" "$8}' | sort -nr


PHP स्क्रिप्ट के बारे में अधिक जानकारी जमा देता है
Php-fpm में उन स्क्रिप्ट को लॉग करने का एक बड़ा अवसर है जो N सेकंड से अधिक समय तक चलती हैं और लॉग को बैकट्रैक करती हैं:

Mar 11 03:42:39 ec2-* [11-Mar-2012 03:42:38] [pool www] pid 26452
Mar 11 03:42:39 ec2-* script_filename = /var/www/html/index.php
Mar 11 03:42:39 ec2-* [0x0000000001971ea0] mysql_query() /var/www/html/bitrix/modules/main/classes/mysql/database.php:173
Mar 11 03:42:39 ec2-* [0x00000000019718a0] Query() /var/www/html/bitrix/modules/tasks/classes/general/task.php:1145
Mar 11 03:42:39 ec2-* [0x000000000196d078] __GetAllowedGroups() /var/www/html/bitrix/modules/tasks/classes/general/task.php:797
Mar 11 03:42:39 ec2-* [0x000000000196cb78] GetFilter() /var/www/html/bitrix/modules/tasks/classes/general/task.php:1442
Mar 11 03:42:39 ec2-* [0x0000000001968348] GetRootSubquery() /var/www/html/bitrix/modules/tasks/classes/general/task.php:730
Mar 11 03:42:39 ec2-* [0x0000000001967a08] GetFilter() /var/www/html/bitrix/modules/tasks/classes/general/task.php:1473
Mar 11 03:42:39 ec2-* [0x00000000019677b8] GetCount() /var/www/html/bitrix/modules/tasks/classes/general/task.php:1505
Mar 11 03:42:39 ec2-* [0x0000000001964998] GetCountInt() /var/www/html/bitrix/components/bitrix/tasks.filter/component.php:105


हम अक्सर इस कार्यक्षमता का उपयोग करते हैं, जैसा कि यह कई बार कारणों की खोज करने के लिए समय कम कर देता है।

हम डेवलपर्स पर "लॉक" सिस्टम प्रशासक हैं

ऑनलाइन स्टोर के ग्राहकों के हिट पर प्रमुख आँकड़ों का संग्रह स्थापित करने के बाद, आपको वेब समाधान को अंतिम रूप देने और अनुकूलित करने के लिए एक निरंतर परिचालन व्यवसाय प्रक्रिया बनाने की आवश्यकता है:
- दिन में एक बार, सभी प्रतिभागियों को तकनीकी प्रक्रिया में और आपके पास आंकड़े भेजे जाते हैं
- पहले से सहमत संकेतकों से अधिक होने पर, स्वचालित रूप से वेब प्रोजेक्ट कोड की त्रुटियों / अनुकूलन के लिए खोज और उन्मूलन

लक्ष्य मानदंड के रूप में, आप ले सकते हैं:

- अनुसूचित रखरखाव के बारे में एक पृष्ठ की संख्या को ग्राहकों को दिखाया गया (यानी, त्रुटियों की संख्या 50x) - 0
- सार्वजनिक हिस्से में हिट्स की संख्या, 0.5 सेकंड से अधिक तेज़ - 100%
- व्यवस्थापक क्षेत्र में हिट की संख्या (जहां "भारी" विश्लेषणात्मक नमूने प्रदर्शन किए जा सकते हैं), 10 सेकंड से अधिक तेज - 100%। व्यवस्थापक पैनल में एक हिट का औसत समय 0.5 सेकंड है।
- स्क्रिप्ट द्वारा उपयोग की जाने वाली मेमोरी की अधिकतम मात्रा 128 एमबी से कम है, औसत 32 एमबी है।

परिणाम

एक से दो दिनों के भीतर अत्यधिक लोड वेब समाधान के प्रमुख आंकड़ों के संग्रह और प्रसंस्करण की स्थापना करके, ग्राहक सेवा की गुणवत्ता के लिए लक्ष्य निर्धारित करना और सांख्यिकी वितरण की स्थापना करके, आपने स्थायी परियोजना की गुणवत्ता की निगरानी और सुनिश्चित करने के लिए एक स्थायी व्यवसाय प्रक्रिया बनाई है - जो निश्चित रूप से, सकारात्मक रूप से संतुष्टि को प्रभावित करेगा। ऑनलाइन स्टोर आगंतुकों और रूपांतरण। कंप्यूटिंग शक्ति की कमी, परियोजना की कार्यक्षमता का निरंतर विकास, त्रुटियों आदि के कारण "ग्रीन ज़ोन" से संकेतकों के अल्पकालिक निकास के मामले में। - प्रक्रिया के विकास और संचालन में शामिल सभी सेवाओं को तुरंत इस बारे में पता चल जाएगा और सिस्टम जल्दी से एक स्थिर स्थिति में वापस आ जाएगा :-), भले ही आप छुट्टी पर हों।

पुनश्च

अगले लेख में, हम पिनबा, नैगियोस, ऑक का उपयोग करते हुए एक अत्यधिक भरी हुई वेब परियोजना के प्रमुख संकेतकों के ऑन-लाइन संग्रह और विश्लेषण को व्यवस्थित करने के तरीकों पर गौर करेंगे। कभी-कभी दिन के अंत तक आंकड़ों से यह पता लगाने के लिए कि ग्राहकों ने नियमित रखरखाव पर 50,000 पृष्ठों को देखा बस अस्वीकार्य है :-) और आपको 5-10 मिनट के भीतर तुरंत जवाब देने की आवश्यकता है। फिर भी, इस मामले में भी दैनिक आँकड़े बहुत उपयोगी होंगे। सौभाग्य है