Loki నుండి లాగ్‌లను సేకరిస్తోంది

Badoo వద్ద, మేము కొత్త సాంకేతికతలను నిరంతరం పర్యవేక్షిస్తాము మరియు అవి మా సిస్టమ్‌లో ఉపయోగించడం విలువైనదేనా అని మూల్యాంకనం చేస్తాము. మేము ఈ అధ్యయనాలలో ఒకదాన్ని సంఘంతో పంచుకోవాలనుకుంటున్నాము. ఇది లాగ్ అగ్రిగేషన్ సిస్టమ్ అయిన Lokiకి అంకితం చేయబడింది.

Loki అనేది లాగ్‌లను నిల్వ చేయడానికి మరియు వీక్షించడానికి ఒక పరిష్కారం, మరియు ఈ స్టాక్ వాటిని విశ్లేషించడానికి మరియు ప్రోమేతియస్‌కి డేటాను పంపడానికి అనువైన వ్యవస్థను కూడా అందిస్తుంది. మేలో, మరొక నవీకరణ విడుదల చేయబడింది, ఇది సృష్టికర్తలచే చురుకుగా ప్రచారం చేయబడింది. Loki ఏమి చేయగలదు, అది ఎలాంటి సామర్థ్యాలను అందిస్తుంది మరియు మేము ఇప్పుడు ఉపయోగిస్తున్న స్టాక్ అయిన ELKకి ప్రత్యామ్నాయంగా ఏ మేరకు పని చేస్తుందనే దానిపై మాకు ఆసక్తి ఉంది.

లోకీ అంటే ఏమిటి

గ్రాఫానా లోకి అనేది లాగ్‌లతో పని చేయడానికి పూర్తి సిస్టమ్ కోసం భాగాల సమితి. ఇతర సారూప్య వ్యవస్థల వలె కాకుండా, Loki లాగ్ మెటాడేటా - లేబుల్‌లను (ప్రోమేతియస్‌లో వలె) మాత్రమే ఇండెక్స్ చేయడం మరియు లాగ్‌లను వేరు వేరు భాగాలుగా కుదించడం అనే ఆలోచనపై ఆధారపడి ఉంటుంది.

హోమ్ పేజీ, గ్యాలరీలు

లోకీతో మీరు ఏమి చేయగలరో తెలుసుకునే ముందు, "మెటాడేటాను మాత్రమే ఇండెక్సింగ్ చేసే ఆలోచన" అంటే ఏమిటో నేను స్పష్టం చేయాలనుకుంటున్నాను. nginx లాగ్ నుండి లైన్ యొక్క ఉదాహరణను ఉపయోగించి, Loki విధానాన్ని మరియు ఎలాస్టిక్‌సెర్చ్ వంటి సాంప్రదాయిక పరిష్కారాలలో ఇండెక్సింగ్ విధానాన్ని పోల్చి చూద్దాం:

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"

సాంప్రదాయ సిస్టమ్‌లు పెద్ద సంఖ్యలో ప్రత్యేకమైన user_id మరియు item_id విలువలతో కూడిన ఫీల్డ్‌లతో సహా మొత్తం అడ్డు వరుసను అన్వయిస్తాయి మరియు ప్రతిదీ పెద్ద సూచికలలో నిల్వ చేస్తాయి. ఈ విధానం యొక్క ప్రయోజనం ఏమిటంటే, దాదాపు మొత్తం డేటా ఇండెక్స్‌లో ఉన్నందున మీరు సంక్లిష్ట ప్రశ్నలను త్వరగా అమలు చేయవచ్చు. కానీ ఇండెక్స్ పెద్దదిగా మారడం వలన ఇది ఖర్చుతో కూడుకున్నది, ఇది మెమరీ అవసరాలుగా అనువదిస్తుంది. ఫలితంగా, పూర్తి-వచన లాగ్ సూచిక లాగ్‌ల పరిమాణంతో పోల్చబడుతుంది. దాని ద్వారా త్వరగా శోధించడానికి, సూచిక తప్పనిసరిగా మెమరీలోకి లోడ్ చేయబడాలి. మరియు ఎక్కువ లాగ్‌లు, ఇండెక్స్ వేగంగా పెరుగుతుంది మరియు ఎక్కువ మెమరీని వినియోగిస్తుంది.

Loki విధానం స్ట్రింగ్ నుండి అవసరమైన డేటాను మాత్రమే సంగ్రహించడం అవసరం, దాని విలువల సంఖ్య తక్కువగా ఉంటుంది. ఈ విధంగా మేము ఒక చిన్న సూచికను పొందుతాము మరియు డేటాను సమయం మరియు ఇండెక్స్ చేయబడిన ఫీల్డ్‌ల ద్వారా ఫిల్టర్ చేయడం ద్వారా శోధించవచ్చు, ఆపై మిగిలిన వాటిని సాధారణ వ్యక్తీకరణలు లేదా సబ్‌స్ట్రింగ్ శోధనతో స్కాన్ చేయవచ్చు. ప్రక్రియ వేగవంతమైనదిగా అనిపించదు, కానీ Loki అభ్యర్థనను అనేక భాగాలుగా విభజించి, వాటిని సమాంతరంగా అమలు చేస్తుంది, తక్కువ సమయంలో పెద్ద మొత్తంలో డేటాను ప్రాసెస్ చేస్తుంది. వాటిలోని ముక్కలు మరియు సమాంతర అభ్యర్థనల సంఖ్య కాన్ఫిగర్ చేయబడుతుంది; అందువల్ల, యూనిట్ సమయానికి ప్రాసెస్ చేయగల డేటా మొత్తం అందించబడిన వనరుల మొత్తంపై సరళంగా ఆధారపడి ఉంటుంది.

పెద్ద, వేగవంతమైన సూచిక మరియు చిన్న, సమాంతర బ్రూట్-ఫోర్స్ ఇండెక్స్ మధ్య ఈ ట్రేడ్-ఆఫ్ సిస్టమ్ యొక్క ధరను నియంత్రించడానికి Loki అనుమతిస్తుంది. ఇది అవసరాలకు అనుగుణంగా సరళంగా కాన్ఫిగర్ చేయబడుతుంది మరియు విస్తరించబడుతుంది.

Loki స్టాక్ మూడు భాగాలను కలిగి ఉంటుంది: Promtail, Loki, Grafana. Promtail లాగ్‌లను సేకరిస్తుంది, వాటిని ప్రాసెస్ చేస్తుంది మరియు వాటిని Lokiకి పంపుతుంది. లోకీ వాటిని ఉంచుతుంది. మరియు Grafana Loki నుండి డేటాను అభ్యర్థించవచ్చు మరియు దానిని ప్రదర్శించవచ్చు. సాధారణంగా, Loki లాగ్‌లను నిల్వ చేయడానికి మరియు వాటి ద్వారా శోధించడానికి మాత్రమే ఉపయోగించబడుతుంది. ప్రోమేతియస్ మార్గాన్ని ఉపయోగించి ఇన్‌కమింగ్ డేటాను ప్రాసెస్ చేయడానికి మరియు విశ్లేషించడానికి మొత్తం స్టాక్ గొప్ప అవకాశాలను అందిస్తుంది.
సంస్థాపనా ప్రక్రియ యొక్క వివరణను కనుగొనవచ్చు ఇక్కడ.

లాగ్‌ల ద్వారా శోధించండి

మీరు ప్రత్యేక గ్రాఫానా ఇంటర్‌ఫేస్ - ఎక్స్‌ప్లోరర్‌లో లాగ్‌లను శోధించవచ్చు. ప్రశ్నలు LogQL భాషను ఉపయోగిస్తాయి, ఇది Prometheusలో ఉపయోగించిన PromQLకి చాలా పోలి ఉంటుంది. సూత్రప్రాయంగా, ఇది పంపిణీ చేయబడిన grepగా భావించవచ్చు.

శోధన ఇంటర్ఫేస్ ఇలా కనిపిస్తుంది:

అభ్యర్థన రెండు భాగాలను కలిగి ఉంటుంది: సెలెక్టర్ మరియు ఫిల్టర్. సెలెక్టర్ అనేది లాగ్‌లకు కేటాయించబడిన ఇండెక్స్డ్ మెటాడేటా (లేబుల్‌లు) ఉపయోగించి శోధన, మరియు ఫిల్టర్ అనేది సెలెక్టర్ నిర్వచించిన రికార్డ్‌లను ఫిల్టర్ చేసే శోధన స్ట్రింగ్ లేదా రీజెక్స్‌ప్. ఇచ్చిన ఉదాహరణలో: కర్లీ బ్రేస్‌లలో సెలెక్టర్ ఉంది, తర్వాత ప్రతిదీ ఫిల్టర్.

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

Loki పని చేసే విధానం కారణంగా, మీరు సెలెక్టర్ లేకుండా ప్రశ్నలను చేయలేరు, కానీ లేబుల్‌లను మీకు నచ్చినట్లుగా సాధారణీకరించవచ్చు.

సెలెక్టర్ అనేది కర్లీ బ్రేస్‌లలో కీ-విలువ విలువ. మీరు సెలెక్టర్లను కలపవచ్చు మరియు ఆపరేటర్లు =, != లేదా సాధారణ వ్యక్తీకరణలను ఉపయోగించి విభిన్న శోధన పరిస్థితులను పేర్కొనవచ్చు:

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

ఫిల్టర్ అనేది టెక్స్ట్ లేదా regexp, ఇది సెలెక్టర్ ద్వారా అందుకున్న మొత్తం డేటాను ఫిల్టర్ చేస్తుంది.

మెట్రిక్స్ మోడ్‌లో స్వీకరించిన డేటా ఆధారంగా తాత్కాలిక గ్రాఫ్‌లను పొందడం సాధ్యమవుతుంది. ఉదాహరణకు, nginx లాగ్‌లలో స్ట్రింగ్ ఇండెక్స్ ఉన్న ఎంట్రీ ఎంత తరచుగా కనిపిస్తుందో మీరు కనుగొనవచ్చు:

సామర్థ్యాల పూర్తి వివరణను డాక్యుమెంటేషన్‌లో చూడవచ్చు LogQL.

లాగ్ పార్సింగ్

లాగ్లను సేకరించడానికి అనేక మార్గాలు ఉన్నాయి:

• లాగ్‌లను సేకరించడం కోసం స్టాక్ యొక్క ప్రామాణిక భాగం అయిన ప్రోమ్‌టైల్‌ని ఉపయోగించడం.
• ఉపయోగించి నేరుగా డాకర్ కంటైనర్ నుండి లోకి డాకర్ లాగింగ్ డ్రైవర్.
• Fluentd లేదా Fluent Bitని ఉపయోగించండి, ఇది Lokiకి డేటాను పంపగలదు. ప్రోమ్‌టైల్ వలె కాకుండా, వారు దాదాపు ఏ రకమైన లాగ్‌కైనా రెడీమేడ్ పార్సర్‌లను కలిగి ఉన్నారు మరియు మల్టీలైన్ లాగ్‌లను కూడా నిర్వహించగలరు.

సాధారణంగా Promtail పార్సింగ్ కోసం ఉపయోగించబడుతుంది. ఇది మూడు పనులను చేస్తుంది:

• డేటా మూలాలను కనుగొంటుంది.
• వాటికి లేబుల్‌లను జత చేస్తుంది.
• లోకి డేటాను పంపుతుంది.

ప్రస్తుతం Promtail స్థానిక ఫైల్‌ల నుండి మరియు systemd జర్నల్ నుండి లాగ్‌లను చదవగలదు. లాగ్‌లు సేకరించిన ప్రతి మెషీన్‌లో ఇది తప్పనిసరిగా ఇన్‌స్టాల్ చేయబడాలి.

Kubernetes తో ఏకీకరణ ఉంది: Promtail స్వయంచాలకంగా, Kubernetes REST API ద్వారా, క్లస్టర్ యొక్క స్థితిని గుర్తిస్తుంది మరియు నోడ్, సేవ లేదా పాడ్ నుండి లాగ్‌లను సేకరిస్తుంది, వెంటనే Kubernetes నుండి మెటాడేటా ఆధారంగా లేబుల్‌లను పోస్ట్ చేస్తుంది (పాడ్ పేరు, ఫైల్ పేరు మొదలైనవి) .

మీరు పైప్‌లైన్ ఉపయోగించి లాగ్ నుండి డేటా ఆధారంగా లేబుల్‌లను కూడా వేలాడదీయవచ్చు. పైప్‌లైన్ ప్రోమ్‌టైల్ నాలుగు రకాల దశలను కలిగి ఉంటుంది. మరిన్ని వివరాలు లో అధికారిక డాక్యుమెంటేషన్, నేను వెంటనే కొన్ని సూక్ష్మ నైపుణ్యాలను గమనిస్తాను.

1. పార్సింగ్ దశలు. ఇది RegEx మరియు JSON దశ. ఈ దశలో, మేము లాగ్‌ల నుండి డేటాను ఎక్స్‌ట్రాక్ట్ చేసిన మ్యాప్‌లోకి సంగ్రహిస్తాము. మనకు అవసరమైన ఫీల్డ్‌లను సంగ్రహించిన మ్యాప్‌లోకి కాపీ చేయడం ద్వారా లేదా సాధారణ వ్యక్తీకరణల ద్వారా (RegEx) JSON నుండి సంగ్రహించవచ్చు, ఇక్కడ పేరున్న సమూహాలు సంగ్రహించబడిన మ్యాప్‌లోకి “మ్యాప్” చేయబడతాయి. సంగ్రహించబడిన మ్యాప్ అనేది కీ-విలువ స్టోర్, ఇక్కడ కీ అనేది ఫీల్డ్ పేరు మరియు విలువ లాగ్‌ల నుండి దాని విలువ.
2. పరివర్తన దశలు. ఈ దశలో రెండు ఎంపికలు ఉన్నాయి: రూపాంతరం, ఇక్కడ మేము పరివర్తన నియమాలను సెట్ చేస్తాము మరియు మూలం - సేకరించిన మ్యాప్ నుండి రూపాంతరం కోసం డేటా మూలం. సంగ్రహించిన మ్యాప్‌లో అటువంటి ఫీల్డ్ లేనట్లయితే, అది సృష్టించబడుతుంది. ఈ విధంగా సంగ్రహించిన మ్యాప్ ఆధారంగా లేని లేబుల్‌లను సృష్టించడం సాధ్యమవుతుంది. ఈ దశలో మనం సంగ్రహించిన మ్యాప్‌లోని డేటాను చాలా శక్తివంతంగా ఉపయోగించి మార్చవచ్చు గోలాంగ్ టెంప్లేట్. అదనంగా, సంగ్రహించబడిన మ్యాప్ పార్సింగ్ సమయంలో పూర్తిగా లోడ్ చేయబడిందని మనం గుర్తుంచుకోవాలి, ఉదాహరణకు, దానిలోని విలువను తనిఖీ చేయడం సాధ్యమవుతుంది: “{{if .tag}ట్యాగ్ విలువ ఉనికిలో ఉంది{end}}”. టెంప్లేట్ షరతులు, లూప్‌లు మరియు రీప్లేస్ మరియు ట్రిమ్ వంటి కొన్ని స్ట్రింగ్ ఫంక్షన్‌లకు మద్దతు ఇస్తుంది.
3. చర్య దశలు. ఈ సమయంలో మీరు సంగ్రహించిన కంటెంట్‌తో ఏదైనా చేయవచ్చు:
   • సంగ్రహించిన డేటా నుండి లేబుల్‌ను సృష్టించండి, ఇది Loki ద్వారా సూచిక చేయబడుతుంది.
   • లాగ్ నుండి ఈవెంట్ సమయాన్ని మార్చండి లేదా సెట్ చేయండి.
   • Lokiకి వెళ్లే డేటాను (లాగ్ టెక్స్ట్) మార్చండి.
   • కొలమానాలను సృష్టించండి.
4. వడపోత దశలు. మ్యాచ్ దశ, ఇక్కడ మనం /dev/null అవసరం లేని ఎంట్రీలను పంపవచ్చు లేదా తదుపరి ప్రాసెసింగ్ కోసం ఫార్వార్డ్ చేయవచ్చు.

సాధారణ nginx లాగ్‌లను ప్రాసెస్ చేసే ఉదాహరణను ఉపయోగించి, మీరు Promtail ఉపయోగించి లాగ్‌లను ఎలా అన్వయించవచ్చో నేను చూపిస్తాను.

పరీక్ష కోసం, nginx-proxyగా మార్చబడిన nginx ఇమేజ్ jwilder/nginx-proxy:alpine మరియు HTTP ద్వారా అడగగలిగే చిన్న డెమోన్‌ని తీసుకుందాం. డెమోన్ అనేక ముగింపు బిందువులను కలిగి ఉంది, దానికి వివిధ HTTP స్థితిగతులు మరియు విభిన్న జాప్యాలతో విభిన్న పరిమాణాల ప్రతిస్పందనలను అందించగలదు.

మేము డాకర్ కంటైనర్‌ల నుండి లాగ్‌లను సేకరిస్తాము, వీటిని /var/lib/docker/containers//-json.log మార్గంలో కనుగొనవచ్చు.

docker-compose.ymlలో మేము ప్రోమ్‌టైల్‌ను కాన్ఫిగర్ చేస్తాము మరియు కాన్ఫిగరేషన్‌కు మార్గాన్ని నిర్దేశిస్తాము:

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

ఈ కాన్ఫిగరేషన్ ప్రారంభించబడినప్పుడు, అన్ని కంటైనర్‌ల నుండి లాగ్‌లు Lokiకి పంపబడతాయి. దీన్ని నివారించడానికి, మేము 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:

మేము లేబుల్‌లను కేటాయిస్తాము. సంగ్రహించిన డేటాలో image_name మరియు container_name కీలు కనిపిస్తే, వాటి విలువలు సంబంధిత లేబుల్‌లకు కేటాయించబడతాయి.

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

ఇమేజ్_పేరు మరియు కంటైనర్_నేమ్ లేబుల్‌లను ఇన్‌స్టాల్ చేయని అన్ని లాగ్‌లను మేము విస్మరిస్తాము.

  - 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>[^/?.]+).*$

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}}"

టెంప్లేట్‌లో షరతులతో కూడిన ఆపరేటర్‌లను ఉపయోగించి, మేము సంగ్రహించిన మ్యాప్‌లో ఇన్‌స్టాల్ చేసిన ఫీల్డ్‌లను తనిఖీ చేస్తాము మరియు request_type ఫీల్డ్‌కు అవసరమైన విలువలను సెట్ చేస్తాము: ఫోటో, స్టాటిక్, 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కి వెళుతుంది.

పై కాన్ఫిగరేషన్‌ని అమలు చేసిన తర్వాత, లాగ్ నుండి డేటా ఆధారంగా ప్రతి ఎంట్రీకి లేబుల్‌లు కేటాయించబడిందని మీరు చూడవచ్చు.

గుర్తుంచుకోవలసిన విషయం ఏమిటంటే, పెద్ద సంఖ్యలో విలువలతో (కార్డినాలిటీ) లేబుల్‌లను తిరిగి పొందడం వలన లోకీని గణనీయంగా తగ్గించవచ్చు. అంటే, మీరు ఇండెక్స్‌లో యూజర్_ఐడిని ఉంచకూడదు. వ్యాసంలో దీని గురించి మరింత చదవండి "Lokiలోని లేబుల్‌లు లాగ్ ప్రశ్నలను ఎలా వేగంగా మరియు సులభంగా చేయగలవు" కానీ మీరు సూచికలు లేకుండా user_id ద్వారా శోధించలేరని దీని అర్థం కాదు. శోధిస్తున్నప్పుడు మీరు ఫిల్టర్‌లను ఉపయోగించాలి (డేటాను "గ్రాబ్" చేయండి), మరియు ఇక్కడ ఉన్న సూచిక స్ట్రీమ్ ఐడెంటిఫైయర్‌గా పనిచేస్తుంది.

లాగ్‌ల విజువలైజేషన్

Loki LogQLని ఉపయోగించి గ్రాఫానా గ్రాఫ్‌ల కోసం డేటా సోర్స్‌గా పని చేస్తుంది. కింది లక్షణాలు మద్దతిస్తాయి:

• రేటు - సెకనుకు రికార్డుల సంఖ్య;
• కాలక్రమేణా లెక్కించండి — పేర్కొన్న పరిధిలోని రికార్డుల సంఖ్య.

సమ్, సగటు మరియు ఇతర సంకలన విధులు కూడా ఉన్నాయి. మీరు చాలా క్లిష్టమైన గ్రాఫ్‌లను రూపొందించవచ్చు, ఉదాహరణకు HTTP లోపాల సంఖ్య యొక్క గ్రాఫ్:

ప్రోమేతియస్ డేటా సోర్స్‌తో పోల్చితే ప్రామాణిక డేటా సోర్స్ Loki ఫంక్షనాలిటీలో కొంత తగ్గింది (ఉదాహరణకు, మీరు లెజెండ్‌ని మార్చలేరు), కానీ Loki ప్రోమేతియస్ రకంతో సోర్స్‌గా కనెక్ట్ చేయబడుతుంది. ఇది డాక్యుమెంట్ చేయబడిన ప్రవర్తన కాదా అని నాకు ఖచ్చితంగా తెలియదు, కానీ డెవలపర్‌ల ప్రతిస్పందనను బట్టి అంచనా వేస్తాను “లోకీని ప్రోమేతియస్ డేటాసోర్స్‌గా ఎలా కాన్ఫిగర్ చేయాలి? · సంచిక #1222 · గ్రాఫానా/లోకీ”, ఉదాహరణకు, పూర్తిగా చట్టబద్ధమైనది మరియు Loki PromQLతో పూర్తిగా అనుకూలంగా ఉంటుంది.

Prometheus రకంతో Lokiని డేటా సోర్స్‌గా జోడించండి మరియు URL /lokiని జోడించండి:

మరియు మేము ప్రోమేతియస్ నుండి కొలమానాలతో పని చేస్తున్నట్లుగా గ్రాఫ్‌లను తయారు చేయవచ్చు:

కార్యాచరణలో వ్యత్యాసం తాత్కాలికమేనని మరియు డెవలపర్‌లు భవిష్యత్తులో దీన్ని సరిచేస్తారని నేను భావిస్తున్నాను.

కొలమానాలు

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

సంగ్రహించిన మ్యాప్ నుండి డేటా ఆధారంగా కొలమానాలను నిర్వచించడానికి మరియు నవీకరించడానికి ఎంపిక మిమ్మల్ని అనుమతిస్తుంది. ఈ కొలమానాలు Lokiకి పంపబడవు - అవి ప్రోమ్‌టైల్ /మెట్రిక్స్ ఎండ్‌పాయింట్‌లో కనిపిస్తాయి. ఈ దశలో అందుకున్న డేటాను స్వీకరించడానికి ప్రోమేథియస్ తప్పనిసరిగా కాన్ఫిగర్ చేయబడాలి. పై ఉదాహరణలో, request_type=“api” కోసం మేము హిస్టోగ్రాం మెట్రిక్‌ని సేకరిస్తాము. ఈ రకమైన మెట్రిక్‌లతో పర్సంటైల్‌లను పొందడం సౌకర్యంగా ఉంటుంది. స్టాటిక్ మరియు ఫోటో కోసం, మేము సగటును లెక్కించడానికి బైట్‌ల మొత్తాన్ని మరియు బైట్‌లను అందుకున్న అడ్డు వరుసల సంఖ్యను సేకరిస్తాము.

కొలమానాల గురించి మరింత చదవండి ఇక్కడ.

ప్రోమ్‌టైల్‌లో పోర్ట్‌ను తెరవండి:

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']

మరియు మేము ఒక గ్రాఫ్ గీస్తాము:

ఈ విధంగా మీరు నాలుగు నెమ్మదిగా ప్రశ్నలను కనుగొనవచ్చు. మీరు ఈ కొలమానాల కోసం పర్యవేక్షణను కూడా సెటప్ చేయవచ్చు.

స్కేలింగ్

Loki సింగిల్ బైనరీ మోడ్‌లో లేదా షార్డ్ మోడ్‌లో (అడ్డంగా-స్కేలబుల్ మోడ్)లో ఉండవచ్చు. రెండవ సందర్భంలో, ఇది క్లౌడ్‌కు డేటాను సేవ్ చేయగలదు మరియు భాగాలు మరియు ఇండెక్స్ విడిగా నిల్వ చేయబడతాయి. వెర్షన్ 1.5 ఒకే చోట నిల్వ చేసే సామర్థ్యాన్ని పరిచయం చేస్తుంది, అయితే ఉత్పత్తిలో దీన్ని ఉపయోగించడానికి ఇంకా సిఫార్సు చేయబడలేదు.

భాగాలు S3-అనుకూల నిల్వలో నిల్వ చేయబడతాయి మరియు సూచికలను నిల్వ చేయడానికి అడ్డంగా స్కేలబుల్ డేటాబేస్‌లను ఉపయోగించవచ్చు: Cassandra, BigTable లేదా DynamoDB. Loki యొక్క ఇతర భాగాలు - డిస్ట్రిబ్యూటర్‌లు (వ్రాయడం కోసం) మరియు క్వెరియర్ (ప్రశ్నల కోసం) - స్థితి లేనివి మరియు అడ్డంగా కూడా స్కేల్ చేయబడతాయి.

DevOpsDays వాంకోవర్ 2019 కాన్ఫరెన్స్‌లో, పాల్గొనేవారిలో ఒకరైన కల్లమ్ స్టియాన్, Lokiతో తన ప్రాజెక్ట్ మొత్తం పరిమాణంలో 1% కంటే తక్కువ ఇండెక్స్‌తో పెటాబైట్‌ల లాగ్‌లను కలిగి ఉందని ప్రకటించారు: "Loki కొలమానాలు మరియు లాగ్‌లను ఎలా సహసంబంధం చేస్తుంది — మరియు మీ డబ్బును ఆదా చేస్తుంది".

Loki మరియు ELK పోలిక

సూచిక పరిమాణం

ఫలిత సూచిక పరిమాణాన్ని పరీక్షించడానికి, పైన పైప్‌లైన్ కాన్ఫిగర్ చేయబడిన nginx కంటైనర్ నుండి నేను లాగ్‌లను తీసుకున్నాను. లాగ్ ఫైల్ మొత్తం 406 MB వాల్యూమ్‌తో 624 లైన్‌లను కలిగి ఉంది. లాగ్‌లు ఒక గంటలోపు ఉత్పత్తి చేయబడ్డాయి, సెకనుకు దాదాపు 109 ఎంట్రీలు.

లాగ్ నుండి రెండు లైన్ల ఉదాహరణ:

ELK ద్వారా ఇండెక్స్ చేసినప్పుడు, ఇది 30,3 MB సూచిక పరిమాణాన్ని ఇచ్చింది:

Loki విషయానికొస్తే, దీని ఫలితంగా సుమారుగా 128 KB సూచిక మరియు దాదాపు 3,8 MB డేటా భాగాలుగా ఉన్నాయి. లాగ్ కృత్రిమంగా రూపొందించబడిందని మరియు పెద్ద సంఖ్యలో డేటాను కలిగి లేదని గమనించాలి. డేటాతో కూడిన ఒరిజినల్ డాకర్ JSON లాగ్‌పై సాధారణ gzip 95,4% కుదింపును అందించింది మరియు క్లీన్ చేసిన nginx లాగ్ మాత్రమే Lokiకి పంపబడిందనే వాస్తవాన్ని పరిగణనలోకి తీసుకుంటే, 4 MB వరకు కుదింపు అర్థమవుతుంది. Loki లేబుల్‌ల కోసం మొత్తం ప్రత్యేక విలువల సంఖ్య 35, ఇది సూచిక యొక్క చిన్న పరిమాణాన్ని వివరిస్తుంది. ELK కోసం లాగ్ కూడా క్లియర్ చేయబడింది. ఆ విధంగా, Loki అసలు డేటాను 96% మరియు ELKని 70% కుదించారు.

మెమరీ వినియోగం

మేము మొత్తం ప్రోమేతియస్ మరియు ELK స్టాక్‌ను పోల్చినట్లయితే, అప్పుడు Loki అనేక రెట్లు తక్కువగా "తింటుంది". Go సర్వీస్ జావా సేవ కంటే తక్కువ వినియోగిస్తుందని స్పష్టంగా తెలుస్తుంది మరియు JVM హీప్ ఎలాస్టిక్‌సెర్చ్ పరిమాణాన్ని మరియు Loki కోసం కేటాయించిన మెమరీని పోల్చడం తప్పు, అయితే Loki చాలా తక్కువ మెమరీని ఉపయోగిస్తుందనేది గమనించదగ్గ విషయం. దీని CPU ప్రయోజనం అంత స్పష్టంగా లేదు, కానీ అది కూడా ఉంది.

వేగం

Loki లాగ్‌లను వేగంగా "మ్రింగివేస్తుంది". వేగం అనేక అంశాలపై ఆధారపడి ఉంటుంది - ఎలాంటి లాగ్‌లు, వాటిని అన్వయించడంలో మనం ఎంత అధునాతనంగా ఉన్నాం, నెట్‌వర్క్, డిస్క్ మొదలైనవి - అయితే ఇది ఖచ్చితంగా ELK కంటే ఎక్కువగా ఉంటుంది (నా పరీక్షలో - దాదాపు రెండు రెట్లు ఎక్కువ). Loki ఇండెక్స్‌లో చాలా తక్కువ డేటాను ఉంచుతుంది మరియు తదనుగుణంగా, ఇండెక్సింగ్‌లో తక్కువ సమయాన్ని వెచ్చిస్తుంది అనే వాస్తవం ద్వారా ఇది వివరించబడింది. శోధన వేగంతో, పరిస్థితి విరుద్ధంగా ఉంటుంది: Loki అనేక గిగాబైట్‌ల కంటే పెద్ద డేటాపై గణనీయంగా నెమ్మదిస్తుంది, అయితే ELK శోధన వేగం డేటా పరిమాణంపై ఆధారపడి ఉండదు.

లాగ్‌ల ద్వారా శోధించండి

లాగ్ శోధన సామర్థ్యాల పరంగా Loki ELK కంటే చాలా తక్కువ స్థాయిలో ఉంది. సాధారణ వ్యక్తీకరణలతో Grep శక్తివంతమైనది, కానీ ఇది పరిణతి చెందిన డేటాబేస్ కంటే తక్కువ. శ్రేణి ప్రశ్నలు లేకపోవడం, లేబుల్‌ల ద్వారా మాత్రమే అగ్రిగేషన్ చేయడం, లేబుల్‌లు లేకుండా శోధించడంలో అసమర్థత - ఇవన్నీ Lokiలో ఆసక్తి ఉన్న సమాచారం కోసం శోధించడంలో మమ్మల్ని పరిమితం చేస్తాయి. Lokiని ఉపయోగించి ఏదీ కనుగొనబడదని దీని అర్థం కాదు, కానీ మీరు మొదట ప్రోమేతియస్ చార్ట్‌లలో సమస్యను కనుగొన్నప్పుడు లాగ్‌లతో పని చేసే విధానాన్ని ఇది నిర్వచిస్తుంది, ఆపై లాగ్‌లలో ఏమి జరిగిందో వెతకడానికి ఈ లేబుల్‌లను ఉపయోగించండి.

ఇంటర్ఫేస్

అన్నింటిలో మొదటిది, ఇది అందంగా ఉంది (క్షమించండి, అడ్డుకోలేకపోయింది). గ్రాఫానా చక్కగా కనిపించే ఇంటర్‌ఫేస్‌ను కలిగి ఉంది, కానీ కిబానా మరింత ఫీచర్ రిచ్‌గా ఉంది.

Loki యొక్క లాభాలు మరియు నష్టాలు

లోకీ ప్రోమేథియస్‌తో అనుసంధానం కావడం ఒక ప్రయోజనాల్లో ఒకటి, కాబట్టి మేము కొలమానాలు మరియు అలర్ట్‌లను పొందుతాము. ఇది ప్రోమేతియస్ నుండి వారసత్వంగా పొందిన సేవా ఆవిష్కరణను కలిగి ఉన్నందున మరియు స్వయంచాలకంగా లేబుల్‌లను జోడించడం వలన లాగ్‌లను సేకరించి, వాటిని కుబెర్నెటెస్ పాడ్‌ల నుండి నిల్వ చేయడానికి సౌకర్యవంతంగా ఉంటుంది.

ప్రతికూలత బలహీనమైన డాక్యుమెంటేషన్. కొన్ని విషయాలు, ఉదాహరణకు, ప్రోమ్‌టైల్ యొక్క లక్షణాలు మరియు సామర్థ్యాలు, నేను కోడ్‌ను అధ్యయనం చేసే ప్రక్రియలో మాత్రమే కనుగొన్నాను, అదృష్టవశాత్తూ ఇది ఓపెన్ సోర్స్. మరొక ప్రతికూలత బలహీనమైన పార్సింగ్ సామర్థ్యాలు. ఉదాహరణకు, Loki బహుళ లైన్ లాగ్‌లను అన్వయించదు. మరో ప్రతికూలత ఏమిటంటే, Loki సాపేక్షంగా యువ సాంకేతికత (విడుదల 1.0 నవంబర్ 2019లో జరిగింది).

తీర్మానం

Loki అనేది చిన్న మరియు మధ్య తరహా ప్రాజెక్ట్‌లకు అనువైన 100% ఆసక్తికరమైన సాంకేతికత, లాగ్ అగ్రిగేషన్, లాగ్ శోధన, పర్యవేక్షణ మరియు లాగ్ విశ్లేషణ వంటి అనేక సమస్యలను పరిష్కరించడానికి మిమ్మల్ని అనుమతిస్తుంది.

మేము Badooలో Lokiని ఉపయోగించము ఎందుకంటే మాకు సరిపోయే ELK స్టాక్ ఉంది మరియు ఇది సంవత్సరాలుగా వివిధ అనుకూల పరిష్కారాలతో నిండి ఉంది. మాకు, stumbling block లాగ్ల ద్వారా శోధిస్తోంది. రోజుకు దాదాపు 100 GB లాగ్‌లతో, ప్రతిదీ కనుగొనడం మరియు కొంచెం ఎక్కువ చేయడం మరియు త్వరగా చేయడం మాకు ముఖ్యం. చార్టింగ్ మరియు పర్యవేక్షణ కోసం, మేము మా అవసరాలకు అనుగుణంగా మరియు ఒకదానితో ఒకటి అనుసంధానించబడిన ఇతర పరిష్కారాలను ఉపయోగిస్తాము. Loki స్టాక్ ప్రత్యక్ష ప్రయోజనాలను కలిగి ఉంది, కానీ ఇది మనకు ఇప్పటికే ఉన్నదాని కంటే ఎక్కువ ఇవ్వదు మరియు దాని ప్రయోజనాలు ఖచ్చితంగా వలస ఖర్చు కంటే ఎక్కువగా ఉండవు.

మరియు పరిశోధన తర్వాత మేము Lokiని ఉపయోగించలేమని స్పష్టమైనప్పటికీ, మీ ఎంపికలో ఈ పోస్ట్ మీకు సహాయపడుతుందని మేము ఆశిస్తున్నాము.

వ్యాసంలో ఉపయోగించిన కోడ్‌తో రిపోజిటరీ ఉంది ఇక్కడ.

మూలం: www.habr.com