லோகியிடம் இருந்து பதிவுகளை சேகரிக்கிறது

Badoo இல் நாங்கள் தொடர்ந்து புதிய தொழில்நுட்பங்களைக் கண்காணித்து, அவற்றை எங்கள் கணினியில் பயன்படுத்தலாமா வேண்டாமா என்பதை மதிப்பீடு செய்து வருகிறோம். இந்த ஆய்வுகளில் ஒன்றை சமூகத்துடன் பகிர்ந்து கொள்ள விரும்புகிறோம். இது பதிவு திரட்டல் அமைப்பான லோகிக்கு அர்ப்பணிக்கப்பட்டுள்ளது.

Loki என்பது பதிவுகளை சேமிப்பதற்கும் பார்ப்பதற்கும் ஒரு தீர்வாகும், மேலும் இந்த அடுக்கு அவற்றை பகுப்பாய்வு செய்வதற்கும் ப்ரோமிதியஸுக்கு தரவை அனுப்புவதற்கும் ஒரு நெகிழ்வான அமைப்பை வழங்குகிறது. மே மாதத்தில், மற்றொரு புதுப்பிப்பு வெளியிடப்பட்டது, இது படைப்பாளர்களால் தீவிரமாக விளம்பரப்படுத்தப்படுகிறது. லோகி என்ன செய்ய முடியும், அது என்ன திறன்களை வழங்குகிறது மற்றும் இப்போது நாம் பயன்படுத்தும் அடுக்கான ELK க்கு மாற்றாக அது எந்த அளவிற்கு செயல்பட முடியும் என்பதில் நாங்கள் ஆர்வமாக இருந்தோம்.

லோகி என்றால் என்ன

கிராஃபானா லோகி என்பது ஒரு முழுமையான பதிவு அமைப்புக்கான கூறுகளின் தொகுப்பாகும். மற்ற ஒத்த அமைப்புகளைப் போலல்லாமல், லோகி பதிவு மெட்டாடேட்டாவை மட்டுமே குறியிடும் யோசனையை அடிப்படையாகக் கொண்டது - லேபிள்கள் (ப்ரோமிதியஸில் உள்ளதைப் போலவே), மற்றும் பதிவுகளை தனித்தனி துண்டுகளாக சுருக்கவும்.

முகப்பு பக்கம், மகிழ்ச்சியா

லோகியுடன் நீங்கள் என்ன செய்ய முடியும் என்பதைப் பற்றி நான் பேசுவதற்கு முன், "மெட்டாடேட்டாவை மட்டும் அட்டவணைப்படுத்தும் யோசனை" என்பதன் அர்த்தம் என்ன என்பதை தெளிவுபடுத்த விரும்புகிறேன். nginx பதிவிலிருந்து ஒரு வரியின் உதாரணத்தைப் பயன்படுத்தி, Elasticsearch போன்ற பாரம்பரிய தீர்வுகளில் உள்ள லோகி அணுகுமுறை மற்றும் குறியீட்டு அணுகுமுறையை ஒப்பிடுவோம்:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

பாரம்பரிய அமைப்புகள் முழு வரிசையையும் அலசுகின்றன, இதில் அதிக எண்ணிக்கையிலான தனிப்பட்ட பயனர்_ஐடி மற்றும் உருப்படி_ஐடி மதிப்புகள் உள்ள புலங்கள் அடங்கும், மேலும் எல்லாவற்றையும் பெரிய குறியீடுகளில் சேமிக்கின்றன. இந்த அணுகுமுறையின் நன்மை என்னவென்றால், சிக்கலான வினவல்களை விரைவாக இயக்க முடியும், ஏனெனில் கிட்டத்தட்ட எல்லா தரவும் குறியீட்டில் உள்ளது. ஆனால் இது ஒரு செலவில் வருகிறது, ஏனெனில் குறியீட்டு பெரிதாகிறது, இது நினைவக தேவைகளாக மொழிபெயர்க்கப்படுகிறது. இதன் விளைவாக, முழு-உரைப் பதிவுக் குறியீடு, பதிவுகளின் அளவோடு ஒப்பிடத்தக்கது. அதை விரைவாகத் தேட, குறியீட்டை நினைவகத்தில் ஏற்ற வேண்டும். மேலும் அதிக பதிவுகள், குறியீட்டு வேகமாக வளரும் மற்றும் அதிக நினைவகத்தை நுகரும்.

லோகி அணுகுமுறைக்கு தேவையான தரவு மட்டுமே சரத்திலிருந்து பிரித்தெடுக்கப்பட வேண்டும், அதன் மதிப்புகளின் எண்ணிக்கை சிறியது. இந்த வழியில் நாம் ஒரு சிறிய குறியீட்டைப் பெறுகிறோம், மேலும் அதை நேரம் மற்றும் அட்டவணைப்படுத்தப்பட்ட புலங்கள் மூலம் வடிகட்டுவதன் மூலம் தரவைத் தேடலாம், பின்னர் மீதமுள்ளவற்றை வழக்கமான வெளிப்பாடுகள் அல்லது சப்ஸ்ட்ரிங் தேடல்கள் மூலம் ஸ்கேன் செய்யலாம். செயல்முறை வேகமானதாகத் தெரியவில்லை, ஆனால் லோகி கோரிக்கையை பல பகுதிகளாகப் பிரித்து அவற்றை இணையாக செயல்படுத்துகிறார், குறுகிய காலத்தில் அதிக அளவிலான தரவை செயலாக்குகிறார். அவற்றில் உள்ள துண்டுகள் மற்றும் இணையான கோரிக்கைகளின் எண்ணிக்கை கட்டமைக்கக்கூடியது; எனவே, ஒரு யூனிட் நேரத்திற்கு செயலாக்கக்கூடிய தரவின் அளவு, வழங்கப்பட்ட வளங்களின் அளவைப் பொறுத்து நேரியல் சார்ந்தது.

ஒரு பெரிய ஃபாஸ்ட் இன்டெக்ஸ் மற்றும் ஒரு சிறிய இணையான ப்ரூட்-ஃபோர்ஸ் இன்டெக்ஸ் ஆகியவற்றுக்கு இடையேயான இந்த வர்த்தகம், அமைப்பின் விலையைக் கட்டுப்படுத்த லோகியை அனுமதிக்கிறது. இது உங்கள் தேவைகளுக்கு ஏற்ப நெகிழ்வாக கட்டமைக்கப்பட்டு விரிவாக்கப்படலாம்.

லோகி ஸ்டேக் மூன்று கூறுகளைக் கொண்டுள்ளது: ப்ரோம்டெயில், லோகி, கிராஃபானா. Promtail பதிவுகளை சேகரித்து, அவற்றை செயலாக்கி லோகிக்கு அனுப்புகிறது. லோகி அவர்களை வைத்திருக்கிறார். மற்றும் கிராஃபானா லோகியிடம் தரவைக் கோரலாம் மற்றும் அதைக் காட்டலாம். பொதுவாக, லோகி பதிவுகளை சேமிப்பதற்கும் அவற்றின் மூலம் தேடுவதற்கும் மட்டும் பயன்படுத்தப்படலாம். ப்ரோமிதியஸ் வழியைப் பயன்படுத்தி உள்வரும் தரவைச் செயலாக்குவதற்கும் பகுப்பாய்வு செய்வதற்கும் முழு ஸ்டாக்கும் சிறந்த வாய்ப்புகளை வழங்குகிறது.
நிறுவல் செயல்முறையின் விளக்கத்தைக் காணலாம் இங்கே.

பதிவு தேடல்

நீங்கள் ஒரு சிறப்பு கிராஃபானா இடைமுகத்தில் பதிவுகளைத் தேடலாம் - எக்ஸ்ப்ளோரர். வினவல்கள் LogQL மொழியைப் பயன்படுத்துகின்றன, இது Prometheus இல் பயன்படுத்தப்படும் PromQL ஐப் போலவே உள்ளது. கொள்கையளவில், இது ஒரு விநியோகிக்கப்பட்ட grep என்று கருதலாம்.

தேடல் இடைமுகம் இதுபோல் தெரிகிறது:

வினவல் இரண்டு பகுதிகளைக் கொண்டுள்ளது: தேர்வி மற்றும் வடிகட்டி. தேர்வாளர் என்பது பதிவுகளுக்கு ஒதுக்கப்பட்ட அட்டவணைப்படுத்தப்பட்ட மெட்டாடேட்டா (லேபிள்கள்) மூலம் தேடலாகும், மேலும் வடிகட்டி என்பது ஒரு தேடல் சரம் அல்லது regexp ஆகும், இது தேர்வாளரால் வரையறுக்கப்பட்ட பதிவுகளை வடிகட்டுகிறது. கொடுக்கப்பட்ட எடுத்துக்காட்டில்: சுருள் அடைப்புக்குறிக்குள் - தேர்வாளர், பிறகு எல்லாம் - வடிகட்டி.

{image_name="nginx.promtail.test"} |= "index"

லோகி செயல்படும் விதம் காரணமாக, தேர்வாளர் இல்லாமல் கோரிக்கைகளைச் செய்ய முடியாது, ஆனால் லேபிள்களை தன்னிச்சையாகப் பொதுவானதாக மாற்றலாம்.

தேர்வி என்பது சுருள் பிரேஸ்களில் உள்ள மதிப்பின் முக்கிய மதிப்பு. நீங்கள் தேர்வாளர்களை இணைத்து, =, != ஆபரேட்டர்கள் அல்லது வழக்கமான வெளிப்பாடுகளைப் பயன்படுத்தி வெவ்வேறு தேடல் நிலைமைகளைக் குறிப்பிடலாம்:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

வடிகட்டி என்பது ஒரு உரை அல்லது regexp ஆகும், இது தேர்வாளரால் பெறப்பட்ட அனைத்து தரவையும் வடிகட்டுகிறது.

மெட்ரிக்ஸ் பயன்முறையில் பெறப்பட்ட தரவுகளின் அடிப்படையில் தற்காலிக வரைபடங்களைப் பெறுவது சாத்தியமாகும். எடுத்துக்காட்டாக, குறியீட்டு சரம் கொண்ட ஒரு உள்ளீட்டின் nginx பதிவுகளில் நிகழ்வின் அதிர்வெண்ணைக் கண்டறியலாம்:

அம்சங்களின் முழு விளக்கத்தையும் ஆவணத்தில் காணலாம் LogQL.

பதிவு பாகுபடுத்துதல்

பதிவுகளை சேகரிக்க பல வழிகள் உள்ளன:

• பதிவுகளை சேகரிப்பதற்கான ஸ்டாக்கின் நிலையான அங்கமான Promtail ஐப் பயன்படுத்துதல்.
• பயன்படுத்தி நேரடியாக டோக்கர் கொள்கலனில் இருந்து லோகி டோக்கர் லாக்கிங் டிரைவர்.
• லோகிக்கு தரவை அனுப்பக்கூடிய Fluentd அல்லது Fluent Bit ஐப் பயன்படுத்தவும். ப்ரோம்டெயில் போலல்லாமல், ஏறக்குறைய எந்த வகைப் பதிவிற்கும் ஆயத்தப் பாகுபடுத்திகளைக் கொண்டுள்ளனர் மேலும் மல்டிலைன் பதிவுகளையும் கையாள முடியும்.

பொதுவாக Promtail பாகுபடுத்த பயன்படுத்தப்படுகிறது. இது மூன்று விஷயங்களைச் செய்கிறது:

• தரவு ஆதாரங்களைக் கண்டறியும்.
• அவற்றுடன் லேபிள்களை இணைக்கவும்.
• லோகிக்கு தரவை அனுப்புகிறது.

தற்போது Promtail உள்ளூர் கோப்புகள் மற்றும் systemd ஜர்னலில் இருந்து பதிவுகளைப் படிக்க முடியும். பதிவுகள் சேகரிக்கப்படும் ஒவ்வொரு கணினியிலும் இது நிறுவப்பட வேண்டும்.

Kubernetes உடன் ஒருங்கிணைப்பு உள்ளது: Promtail தானாகவே Kubernetes REST API மூலம் கிளஸ்டரின் நிலையைக் கண்டறிந்து, ஒரு முனை, சேவை அல்லது பாட் ஆகியவற்றிலிருந்து பதிவுகளைச் சேகரித்து, குபெர்னெட்டஸின் (பாட் பெயர், கோப்பு பெயர், முதலியன) மெட்டாடேட்டாவின் அடிப்படையில் லேபிள்களை உடனடியாக இடுகையிடுகிறது.

பைப்லைனைப் பயன்படுத்தி பதிவில் உள்ள தரவின் அடிப்படையில் லேபிள்களையும் தொங்கவிடலாம். பைப்லைன் ப்ரோம்டெயில் நான்கு வகையான நிலைகளைக் கொண்டிருக்கலாம். மேலும் விவரங்கள் - இல் அதிகாரப்பூர்வ ஆவணங்கள், நான் உடனடியாக சில நுணுக்கங்களைக் கவனிக்கிறேன்.

1. பாகுபடுத்தும் நிலைகள். இது RegEx மற்றும் JSON நிலை. இந்த கட்டத்தில், பிரித்தெடுக்கப்பட்ட வரைபடம் என்று அழைக்கப்படும் பதிவுகளிலிருந்து தரவைப் பிரித்தெடுக்கிறோம். பிரித்தெடுக்கப்பட்ட வரைபடத்தில் நமக்குத் தேவையான புலங்களை நகலெடுப்பதன் மூலம் அல்லது வழக்கமான வெளிப்பாடுகள் (RegEx) மூலம் JSON இலிருந்து பிரித்தெடுக்கலாம், அங்கு பெயரிடப்பட்ட குழுக்கள் பிரித்தெடுக்கப்பட்ட வரைபடத்தில் "வரைபடம்" செய்யப்படுகின்றன. பிரித்தெடுக்கப்பட்ட வரைபடம் என்பது ஒரு விசை-மதிப்பு அங்காடியாகும், இதில் விசை என்பது புலத்தின் பெயர், மற்றும் மதிப்பு என்பது பதிவுகளிலிருந்து அதன் மதிப்பு.
2. நிலைகளை மாற்றவும். இந்த கட்டத்தில் இரண்டு விருப்பங்கள் உள்ளன: உருமாற்றம், அங்கு உருமாற்ற விதிகளை அமைக்கிறோம், மற்றும் ஆதாரம் - பிரித்தெடுக்கப்பட்ட வரைபடத்திலிருந்து மாற்றத்திற்கான தரவு ஆதாரம். பிரித்தெடுக்கப்பட்ட வரைபடத்தில் அத்தகைய புலம் இல்லை என்றால், அது உருவாக்கப்படும். இந்த வழியில் பிரித்தெடுக்கப்பட்ட வரைபடத்தின் அடிப்படையில் இல்லாத லேபிள்களை உருவாக்க முடியும். இந்த கட்டத்தில், பிரித்தெடுக்கப்பட்ட வரைபடத்தில் உள்ள தரவை மிகவும் சக்திவாய்ந்த ஒன்றைப் பயன்படுத்தி நாம் கையாளலாம் கோலாங் டெம்ப்ளேட். கூடுதலாக, பிரித்தெடுக்கப்பட்ட வரைபடம் பாகுபடுத்தும் போது முழுமையாக ஏற்றப்பட்டிருப்பதை நாம் நினைவில் கொள்ள வேண்டும், இது சாத்தியமாக்குகிறது, எடுத்துக்காட்டாக, அதில் உள்ள மதிப்பைச் சரிபார்க்க: “{{if .tag}டேக் மதிப்பு உள்ளது{end}}”. டெம்ப்ளேட் நிபந்தனைகள், லூப்கள் மற்றும் ரீப்ளேஸ் மற்றும் டிரிம் போன்ற சில சரம் செயல்பாடுகளை ஆதரிக்கிறது.
3. செயல் நிலைகள். இந்த கட்டத்தில், பிரித்தெடுக்கப்பட்டதைக் கொண்டு நீங்கள் ஏதாவது செய்யலாம்:
   • பிரித்தெடுக்கப்பட்ட தரவிலிருந்து ஒரு லேபிளை உருவாக்கவும், அது லோகியால் குறியிடப்படும்.
   • பதிவில் இருந்து நிகழ்வு நேரத்தை மாற்றவும் அல்லது அமைக்கவும்.
   • லோகிக்குச் செல்லும் தரவை (பதிவு உரை) மாற்றவும்.
   • அளவீடுகளை உருவாக்கவும்.
4. வடிகட்டுதல் நிலைகள். மேட்ச் ஸ்டேஜ், இதில் நாம் தேவையில்லாத உள்ளீடுகளை /dev/null அனுப்பலாம் அல்லது மேலும் செயலாக்கத்திற்கு அனுப்பலாம்.

சாதாரண nginx பதிவுகளை செயலாக்குவதற்கான உதாரணத்தைப் பயன்படுத்தி, Promtail ஐப் பயன்படுத்தி பதிவுகளை எவ்வாறு அலசலாம் என்பதைக் காண்பிப்பேன்.

சோதனைக்கு, மாற்றியமைக்கப்பட்ட nginx jwilder/nginx-proxy:alpine படத்தையும், HTTP வழியாக nginx-proxy என வினவக்கூடிய சிறிய டீமானையும் எடுத்துக்கொள்வோம். டீமான் பல முனைப்புள்ளிகளைக் கொண்டுள்ளது, அதற்கு வெவ்வேறு அளவுகளில், வெவ்வேறு HTTP நிலைகள் மற்றும் வெவ்வேறு தாமதங்களுடன் பதில்களை அளிக்க முடியும்.

நாங்கள் டோக்கர் கொள்கலன்களில் இருந்து பதிவுகளை சேகரிப்போம், அவை பாதையில் /var/lib/docker/containers/ / -json.log

docker-compose.yml இல் நாங்கள் Promtail ஐ அமைத்து, கட்டமைப்பிற்கான பாதையைக் குறிப்பிடுகிறோம்:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

பதிவுகளுக்கான பாதையை promtail.yml இல் சேர்க்கவும் (கட்டமைப்பில் "டாக்கர்" விருப்பம் உள்ளது, அது ஒரு வரியில் அதையே செய்கிறது, ஆனால் அது அவ்வளவு தெளிவாக இருக்காது):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

இந்த கட்டமைப்பு இயக்கப்பட்டால், லோகி அனைத்து கொள்கலன்களிலிருந்தும் பதிவுகளைப் பெறும். இதைத் தவிர்க்க, docker-compose.yml இல் சோதனை nginx இன் அமைப்புகளை மாற்றுகிறோம் - குறிச்சொல் புலத்தில் உள்நுழைவைச் சேர்க்கவும்:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

promtail.yml ஐத் திருத்துதல் மற்றும் பைப்லைனை அமைத்தல். உள்ளீட்டில் பின்வரும் வகை பதிவுகள் உள்ளன:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

குழாய் நிலைகள்:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

உள்வரும் JSON இலிருந்து ஸ்ட்ரீம், attrs, attrs.tag (அவை இருந்தால்) புலங்களைப் பிரித்தெடுத்து, பிரித்தெடுக்கப்பட்ட வரைபடத்தில் வைக்கிறோம்.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

பிரித்தெடுக்கப்பட்ட வரைபடத்தில் குறிச்சொல் புலத்தை வைக்க முடிந்தால், regexp ஐப் பயன்படுத்தி படம் மற்றும் கொள்கலனின் பெயர்களைப் பிரித்தெடுக்கிறோம்.

 - labels:
     image_name:
     container_name:

நாங்கள் லேபிள்களை ஒதுக்குகிறோம். பிரித்தெடுக்கப்பட்ட தரவுகளில் படத்தின்_பெயர் மற்றும் கொள்கலன்_பெயர் விசைகள் காணப்பட்டால், அவற்றின் மதிப்புகள் தொடர்புடைய லேபிள்களுக்கு ஒதுக்கப்படும்.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

லேபிள்கள் image_name மற்றும் container_name செட் இல்லாத அனைத்து பதிவுகளையும் நிராகரிக்கிறோம்.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

image_name nginx.promtail.test உள்ள அனைத்து பதிவுகளுக்கும், மூலப் பதிவிலிருந்து பதிவு புலத்தைப் பிரித்தெடுத்து, பிரித்தெடுக்கப்பட்ட வரைபடத்தில் வரிசை விசையுடன் வைக்கவும்.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

வழக்கமான வெளிப்பாடுகளுடன் உள்ளீட்டு சரத்தை அழித்து, nginx மெய்நிகர் ஹோஸ்ட் மற்றும் nginx பதிவு வரியை வெளியே இழுப்போம்.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

வழக்கமான வெளிப்பாடுகளுடன் nginx பதிவை அலசவும்.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

கோரிக்கை_url ஐ அலசவும். regexp உதவியுடன், கோரிக்கையின் நோக்கத்தை நாங்கள் தீர்மானிக்கிறோம்: புள்ளிவிவரங்கள், புகைப்படங்கள், API க்கு மற்றும் பிரித்தெடுக்கப்பட்ட வரைபடத்தில் தொடர்புடைய விசையை அமைக்கவும்.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

டெம்ப்ளேட்டில் நிபந்தனை ஆபரேட்டர்களைப் பயன்படுத்தி, பிரித்தெடுக்கப்பட்ட வரைபடத்தில் நிறுவப்பட்ட புலங்களைச் சரிபார்த்து, கோரிக்கை_வகை புலத்திற்கு தேவையான மதிப்புகளை அமைக்கிறோம்: புகைப்படம், நிலையான, API. தோல்வியுற்றால் மற்றவற்றை ஒதுக்கவும். இப்போது request_type கோரிக்கை வகையைக் கொண்டுள்ளது.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

பிரித்தெடுக்கப்பட்ட வரைபடத்தில் எங்களால் நிர்வகிக்க முடிந்தவற்றின் அடிப்படையில் api_request, virtual_host, request_type மற்றும் நிலை (HTTP நிலை) ஆகிய லேபிள்களை அமைத்துள்ளோம்.

       - output:
           source: nginx_log_row

வெளியீட்டை மாற்றவும். இப்போது பிரித்தெடுக்கப்பட்ட வரைபடத்திலிருந்து சுத்தம் செய்யப்பட்ட nginx பதிவு லோகிக்கு செல்கிறது.

மேலே உள்ள கட்டமைப்பை இயக்கிய பிறகு, ஒவ்வொரு உள்ளீடும் பதிவிலிருந்து தரவின் அடிப்படையில் லேபிளிடப்பட்டிருப்பதைக் காணலாம்.

நினைவில் கொள்ள வேண்டிய ஒன்று என்னவென்றால், அதிக எண்ணிக்கையிலான மதிப்புகள் (கார்டினாலிட்டி) கொண்ட லேபிள்களை மீட்டெடுப்பது லோகியின் வேகத்தை கணிசமாகக் குறைக்கும். அதாவது, நீங்கள் குறியீட்டில் பயனர்_ஐடியை வைக்கக்கூடாது. கட்டுரையில் இதைப் பற்றி மேலும் வாசிக்க "Loki இல் உள்ள லேபிள்கள் எவ்வாறு பதிவு வினவல்களை விரைவாகவும் எளிதாகவும் செய்யலாம்". ஆனால் குறியீடுகள் இல்லாமல் user_id மூலம் தேட முடியாது என்று இது அர்த்தப்படுத்துவதில்லை. தேடும் போது நீங்கள் வடிப்பான்களைப் பயன்படுத்த வேண்டும் (தரவை "கிராப்"), மேலும் இங்குள்ள அட்டவணை ஸ்ட்ரீம் அடையாளங்காட்டியாகச் செயல்படுகிறது.

பதிவு காட்சிப்படுத்தல்

LogQL ஐப் பயன்படுத்தி Grafana விளக்கப்படங்களுக்கான தரவு ஆதாரமாக Loki செயல்பட முடியும். பின்வரும் அம்சங்கள் ஆதரிக்கப்படுகின்றன:

• விகிதம் - வினாடிக்கு பதிவுகளின் எண்ணிக்கை;
• காலப்போக்கில் எண்ணிக்கை - கொடுக்கப்பட்ட வரம்பில் உள்ள பதிவுகளின் எண்ணிக்கை.

கூட்டுச் செயல்பாடுகள் Sum, Avg மற்றும் பிற உள்ளன. நீங்கள் மிகவும் சிக்கலான வரைபடங்களை உருவாக்கலாம், எடுத்துக்காட்டாக, HTTP பிழைகளின் எண்ணிக்கையின் வரைபடம்:

லோகியின் இயல்புநிலை தரவு மூலமானது, ப்ரோமிதியஸ் தரவு மூலத்தை விட சற்று குறைவாகவே செயல்படுகிறது (உதாரணமாக, நீங்கள் புராணத்தை மாற்ற முடியாது), ஆனால் லோகியை ப்ரோமிதியஸ் வகை மூலமாக இணைக்க முடியும். இது ஆவணப்படுத்தப்பட்ட நடத்தையா என்று எனக்குத் தெரியவில்லை, ஆனால் டெவலப்பர்களின் பதிலைக் கொண்டு மதிப்பிடுகிறேன் "லோகியை ப்ரோமிதியஸ் தரவுமூலமாக எவ்வாறு கட்டமைப்பது? · வெளியீடு #1222 · கிராஃபனா/லோகி”, எடுத்துக்காட்டாக, இது முற்றிலும் சட்டபூர்வமானது மற்றும் லோகி PromQL உடன் முழுமையாக இணக்கமானது.

ப்ரோமிதியஸ் வகையுடன் லோகியை தரவு மூலமாகச் சேர்த்து URL /loki ஐச் சேர்க்கவும்:

நாங்கள் ப்ரோமிதியஸின் அளவீடுகளுடன் பணிபுரிவது போல் நீங்கள் வரைபடங்களை உருவாக்கலாம்:

செயல்பாட்டில் உள்ள முரண்பாடு தற்காலிகமானது மற்றும் டெவலப்பர்கள் எதிர்காலத்தில் அதை சரிசெய்வார்கள் என்று நான் நினைக்கிறேன்.

அளவீடுகள்

பதிவுகளிலிருந்து எண் அளவீடுகளைப் பிரித்தெடுத்து அவற்றை ப்ரோமிதியஸுக்கு அனுப்பும் திறனை லோகி வழங்குகிறது. எடுத்துக்காட்டாக, nginx பதிவில் ஒரு பதிலுக்கான பைட்டுகளின் எண்ணிக்கையும், நிலையான பதிவு வடிவமைப்பின் ஒரு குறிப்பிட்ட மாற்றத்துடன், பதிலளிக்கும் வினாடிகளில் நேரத்தையும் கொண்டுள்ளது. இந்தத் தரவைப் பிரித்தெடுத்து ப்ரோமிதியஸுக்கு அனுப்பலாம்.

promtail.yml இல் மற்றொரு பகுதியைச் சேர்க்கவும்:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

பிரித்தெடுக்கப்பட்ட வரைபடத்திலிருந்து தரவின் அடிப்படையில் அளவீடுகளை வரையறுக்கவும் புதுப்பிக்கவும் விருப்பம் உங்களை அனுமதிக்கிறது. இந்த அளவீடுகள் லோகிக்கு அனுப்பப்படவில்லை - அவை Promtail /metrics endpoint இல் தோன்றும். இந்த கட்டத்தில் பெறப்பட்ட தரவைப் பெறுவதற்கு Prometheus கட்டமைக்கப்பட வேண்டும். மேலே உள்ள எடுத்துக்காட்டில், request_type=“api”க்கு நாம் ஒரு ஹிஸ்டோகிராம் மெட்ரிக்கை சேகரிக்கிறோம். இந்த வகை அளவீடுகள் மூலம் சதவீதங்களைப் பெறுவது வசதியானது. நிலையான மற்றும் புகைப்படத்திற்கு, சராசரியைக் கணக்கிட பைட்டுகளின் கூட்டுத்தொகையையும் பைட்டுகளைப் பெற்ற வரிசைகளின் எண்ணிக்கையையும் சேகரிக்கிறோம்.

அளவீடுகள் பற்றி மேலும் படிக்கவும் இங்கே.

Promtail இல் ஒரு போர்ட்டைத் திறக்கவும்:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

promtail_custom முன்னொட்டுடன் கூடிய அளவீடுகள் தோன்றியிருப்பதை உறுதிசெய்கிறோம்:

ப்ரோமிதியஸை அமைத்தல். வேலை விளம்பரத்தை சேர்க்கவும்:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

மற்றும் ஒரு வரைபடத்தை வரையவும்:

இந்த வழியில் நீங்கள் நான்கு மெதுவான வினவல்களைக் கண்டறியலாம். இந்த அளவீடுகளுக்கான கண்காணிப்பையும் நீங்கள் உள்ளமைக்கலாம்.

அளவிடுதல்

லோகி ஒற்றை பைனரி முறை மற்றும் துண்டாக்கப்பட்ட (கிடைமட்டமாக அளவிடக்கூடிய பயன்முறை) இரண்டிலும் இருக்கலாம். இரண்டாவது வழக்கில், இது மேகக்கணியில் தரவைச் சேமிக்க முடியும், மேலும் துகள்கள் மற்றும் குறியீட்டு தனித்தனியாக சேமிக்கப்படும். பதிப்பு 1.5 இல், ஒரே இடத்தில் சேமிக்கும் திறன் செயல்படுத்தப்படுகிறது, ஆனால் அதை உற்பத்தியில் பயன்படுத்த இன்னும் பரிந்துரைக்கப்படவில்லை.

துகள்களை S3-இணக்கமான சேமிப்பகத்தில் சேமிக்கலாம், மேலும் கிடைமட்டமாக அளவிடக்கூடிய தரவுத்தளங்கள் குறியீடுகளைச் சேமிக்கப் பயன்படுத்தலாம்: கசாண்ட்ரா, பிக்டேபிள் அல்லது டைனமோடிபி. லோகியின் பிற பகுதிகள் - விநியோகஸ்தர்கள் (எழுதுவதற்கு) மற்றும் க்வெரியர் (கேள்விகளுக்கு) - நிலையற்றவை மற்றும் கிடைமட்டமாக அளவிடப்படுகின்றன.

DevOpsDays வான்கூவர் 2019 மாநாட்டில், பங்கேற்பாளர்களில் ஒருவரான Callum Styan லோகியுடன் தனது திட்டத்தில் மொத்த அளவின் 1% க்கும் குறைவான குறியீட்டைக் கொண்ட பெட்டாபைட் பதிவுகள் இருப்பதாக அறிவித்தார்: "லோகி எவ்வாறு அளவீடுகள் மற்றும் பதிவுகளை தொடர்புபடுத்துகிறார் - மேலும் உங்கள் பணத்தை சேமிக்கிறது".

லோகி மற்றும் ELK இன் ஒப்பீடு

குறியீட்டு அளவு

இதன் விளைவாக வரும் குறியீட்டு அளவைச் சோதிக்க, மேலே உள்ள பைப்லைன் கட்டமைக்கப்பட்ட nginx கொள்கலனில் இருந்து பதிவுகளை எடுத்தேன். பதிவு கோப்பில் 406 கோடுகள் 624 MB மொத்த அளவு கொண்டவை. ஒரு மணி நேரத்திற்குள் பதிவுகள் உருவாக்கப்பட்டன, ஒரு வினாடிக்கு சுமார் 109 பதிவுகள்.

பதிவிலிருந்து இரண்டு வரிகளின் உதாரணம்:

ELK ஆல் அட்டவணைப்படுத்தப்பட்டபோது, ​​இது 30,3 MB இன் குறியீட்டு அளவைக் கொடுத்தது:

லோகியைப் பொறுத்தவரை, இது சுமார் 128 KB குறியீட்டையும், 3,8 MB தரவையும் துண்டாகக் கொடுத்தது. பதிவு செயற்கையாக உருவாக்கப்பட்டது மற்றும் பலதரப்பட்ட தரவுகளைக் கொண்டிருக்கவில்லை என்பது குறிப்பிடத்தக்கது. அசல் டோக்கர் JSON பதிவின் தரவுகளுடன் ஒரு எளிய ஜிஜிப் 95,4% சுருக்கத்தை அளித்தது, மேலும் சுத்தம் செய்யப்பட்ட nginx பதிவு மட்டுமே லோகிக்கு அனுப்பப்பட்டது, 4 MB வரை சுருக்கப்பட்டது புரிந்துகொள்ளத்தக்கது. லோகி லேபிள்களுக்கான தனிப்பட்ட மதிப்புகளின் மொத்த எண்ணிக்கை 35 ஆகும், இது குறியீட்டின் சிறிய அளவை விளக்குகிறது. ELKக்கு, பதிவும் அழிக்கப்பட்டது. எனவே, லோகி அசல் தரவை 96% ஆகவும், ELK ஐ 70% ஆகவும் சுருக்கினார்.

நினைவக நுகர்வு

ப்ரோமிதியஸ் மற்றும் ELK இன் முழு அடுக்கையும் ஒப்பிட்டுப் பார்த்தால், லோகி பல மடங்கு குறைவாக "சாப்பிடுகிறார்". Go சேவையானது Java சேவையை விட குறைவாகவே பயன்படுத்துகிறது என்பது தெளிவாகிறது, மேலும் Heap Elasticsearch JVM இன் அளவையும் லோகிக்கு ஒதுக்கப்பட்ட நினைவகத்தையும் ஒப்பிடுவது தவறானது, இருப்பினும் லோகி மிகவும் குறைவான நினைவகத்தைப் பயன்படுத்துகிறார் என்பது குறிப்பிடத்தக்கது. அதன் CPU நன்மை அவ்வளவு தெளிவாக இல்லை, ஆனால் அதுவும் உள்ளது.

வேகம்

லோகி பதிவுகளை வேகமாக "விழுங்குகிறது". வேகம் பல காரணிகளைப் பொறுத்தது - எந்த வகையான பதிவுகள், அவற்றை எவ்வளவு அதிநவீனமாக அலசுகிறோம், நெட்வொர்க், வட்டு போன்றவை - ஆனால் இது நிச்சயமாக ELK ஐ விட அதிகமாக உள்ளது (எனது சோதனையில் - சுமார் இரண்டு முறை). லோகி குறியீட்டில் மிகக் குறைவான தரவை வைப்பதன் மூலம் இது விளக்கப்படுகிறது, அதன்படி, அட்டவணைப்படுத்தலில் குறைந்த நேரத்தை செலவிடுகிறது. இந்த வழக்கில், தேடல் வேகத்துடன் நிலைமை தலைகீழாக மாறுகிறது: சில ஜிகாபைட்களை விட பெரிய தரவை லோகி குறிப்பிடத்தக்க வகையில் குறைக்கிறது, அதே நேரத்தில் ELK க்கு, தேடல் வேகம் தரவு அளவைப் பொறுத்தது அல்ல.

பதிவு தேடல்

பதிவு தேடல் திறன்களின் அடிப்படையில் லோகி ELK ஐ விட கணிசமாக தாழ்ந்தவர். வழக்கமான வெளிப்பாடுகள் கொண்ட Grep ஒரு வலுவான விஷயம், ஆனால் இது வயது வந்தோருக்கான தரவுத்தளத்தை விட தாழ்வானது. வரம்பு வினவல்கள் இல்லாமை, லேபிள்களால் மட்டுமே திரட்டுதல், லேபிள்கள் இல்லாமல் தேட இயலாமை - இவை அனைத்தும் லோகியில் ஆர்வமுள்ள தகவல்களைத் தேடுவதில் நம்மை கட்டுப்படுத்துகிறது. லோகியைப் பயன்படுத்தி எதையும் கண்டுபிடிக்க முடியாது என்பதை இது குறிக்கவில்லை, ஆனால் இது பதிவுகளுடன் பணிபுரியும் ஓட்டத்தை வரையறுக்கிறது, நீங்கள் முதலில் ப்ரோமிதியஸ் விளக்கப்படங்களில் சிக்கலைக் கண்டறிந்து, இந்த லேபிள்களைப் பயன்படுத்தி பதிவுகளில் என்ன நடந்தது என்பதைப் பார்க்கவும்.

இடைமுகம்

முதலில், இது அழகாக இருக்கிறது (மன்னிக்கவும், எதிர்க்க முடியவில்லை). கிராஃபானா ஒரு அழகான இடைமுகத்தைக் கொண்டுள்ளது, ஆனால் கிபானா மிகவும் செயல்பாட்டுடன் உள்ளது.

லோகி நன்மை தீமைகள்

பிளஸ்களில், லோகி முறையே ப்ரோமிதியஸுடன் ஒருங்கிணைக்கிறார் என்பதைக் கவனத்தில் கொள்ளலாம், நாங்கள் அளவீடுகளைப் பெறுகிறோம் மற்றும் பெட்டிக்கு வெளியே எச்சரிக்கை செய்கிறோம். பதிவுகளை சேகரித்து அவற்றை குபெர்னெட்டஸ் பாட்களுடன் சேமித்து வைப்பதற்கு இது வசதியானது, ஏனெனில் இது ப்ரோமிதியஸிடமிருந்து பெறப்பட்ட சேவை கண்டுபிடிப்பு மற்றும் தானாக லேபிள்களை இணைக்கிறது.

குறைபாடுகளில் - மோசமான ஆவணங்கள். ப்ரோம்டெயிலின் அம்சங்கள் மற்றும் திறன்கள் போன்ற சில விஷயங்களை, குறியீட்டைப் படிக்கும் செயல்முறையில் மட்டுமே நான் கண்டுபிடித்தேன், திறந்த மூலத்தின் நன்மை. மற்றொரு குறைபாடு பலவீனமான பாகுபடுத்தும் திறன் ஆகும். எடுத்துக்காட்டாக, லோகி பல வரி பதிவுகளை அலச முடியாது. மேலும், லோகி ஒரு ஒப்பீட்டளவில் இளம் தொழில்நுட்பம் (1.0 நவம்பர் 2019 இல் வெளியிடப்பட்டது) என்பதும் குறைபாடுகளில் அடங்கும்.

முடிவுக்கு

லோகி என்பது 100% சுவாரஸ்யமான தொழில்நுட்பமாகும், இது சிறிய மற்றும் நடுத்தர திட்டங்களுக்கு ஏற்றது, இது பதிவு திரட்டல், பதிவு தேடல், கண்காணிப்பு மற்றும் பதிவுகளின் பகுப்பாய்வு போன்ற பல சிக்கல்களைத் தீர்க்க உங்களை அனுமதிக்கிறது.

நாங்கள் படூவில் லோகியைப் பயன்படுத்த மாட்டோம், ஏனென்றால் எங்களிடம் ELK ஸ்டாக் உள்ளது, அது எங்களுக்கு ஏற்றது மற்றும் பல ஆண்டுகளாக பல்வேறு தனிப்பயன் தீர்வுகளால் வளர்ந்துள்ளது. எங்களைப் பொறுத்தவரை, தடுமாற்றம் பதிவுகள் மூலம் தேடுகிறது. ஒரு நாளைக்கு கிட்டத்தட்ட 100 ஜிபி பதிவுகள் இருப்பதால், எல்லாவற்றையும் கண்டுபிடித்து இன்னும் கொஞ்சம் விரைவாகச் செய்வது எங்களுக்கு முக்கியம். பட்டியலிடுவதற்கும் கண்காணிப்பதற்கும், எங்கள் தேவைகளுக்கு ஏற்றவாறும், ஒன்றோடொன்று ஒருங்கிணைக்கப்பட்டும் பிற தீர்வுகளைப் பயன்படுத்துகிறோம். லோகி ஸ்டேக் உறுதியான பலன்களைக் கொண்டுள்ளது, ஆனால் அது ஏற்கனவே நம்மிடம் இருப்பதை விட அதிகமாகத் தராது, மேலும் அதன் பலன்கள் நிச்சயமாக இடம்பெயர்வுச் செலவை விட அதிகமாக இருக்காது.

லோகியைப் பயன்படுத்த முடியாது என்பது ஆராய்ச்சிக்குப் பிறகு தெளிவாகத் தெரிந்தாலும், இந்த இடுகை உங்களுக்குத் தேர்ந்தெடுக்க உதவும் என்று நம்புகிறோம்.

கட்டுரையில் பயன்படுத்தப்பட்ட குறியீட்டைக் கொண்ட களஞ்சியம் அமைந்துள்ளது இங்கே.

ஆதாரம்: www.habr.com