Loki માંથી લોગ એકત્રિત કરી રહ્યા છીએ

અમે Badoo પર સતત નવી ટેક્નોલોજીઓ પર નજર રાખીએ છીએ અને અમારી સિસ્ટમમાં તેનો ઉપયોગ કરવો કે નહીં તેનું મૂલ્યાંકન કરીએ છીએ. અમે આમાંથી એક અભ્યાસ સમુદાય સાથે શેર કરવા માંગીએ છીએ. તે લોકીને સમર્પિત છે, લોગ એકત્રીકરણ સિસ્ટમ.

લોકી એ લૉગ્સ સ્ટોર કરવા અને જોવા માટેનો ઉકેલ છે, અને આ સ્ટેક તેનું વિશ્લેષણ કરવા અને પ્રોમિથિયસને ડેટા મોકલવા માટે એક લવચીક સિસ્ટમ પણ પ્રદાન કરે છે. મે મહિનામાં, બીજું અપડેટ બહાર પાડવામાં આવ્યું હતું, જે સર્જકો દ્વારા સક્રિયપણે પ્રમોટ કરવામાં આવે છે. લોકી શું કરી શકે છે, તે કઈ સુવિધાઓ પ્રદાન કરે છે અને તે ELK ના વિકલ્પ તરીકે કેટલી હદ સુધી કાર્ય કરી શકે છે, તે સ્ટેક કે જેનો અમે અત્યારે ઉપયોગ કરીએ છીએ તેમાં અમને રસ હતો.

લોકી શું છે

ગ્રાફના લોકી એ સંપૂર્ણ લોગીંગ સિસ્ટમ માટે ઘટકોનો સમૂહ છે. અન્ય સમાન સિસ્ટમોથી વિપરીત, લોકી ફક્ત લોગ મેટાડેટા - લેબલ્સ (જેમ કે પ્રોમિથિયસની જેમ) ને અનુક્રમિત કરવાના વિચાર પર આધારિત છે, અને લોગને અલગ-અલગ હિસ્સામાં સાથે સાથે સંકુચિત કરવા પર આધારિત છે.

મુખ્ય પૃષ્ઠ, GitHub

તમે લોકી સાથે શું કરી શકો તે અંગે હું જાણું તે પહેલાં, હું "ફક્ત મેટાડેટાને અનુક્રમિત કરવાના વિચાર" નો અર્થ શું છે તે સ્પષ્ટ કરવા માંગુ છું. ચાલો 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"

પરંપરાગત સિસ્ટમો સમગ્ર પંક્તિને પાર્સ કરે છે, જેમાં ઘણા અનન્ય user_id અને item_id મૂલ્યો સાથે ફીલ્ડનો સમાવેશ થાય છે અને દરેક વસ્તુને મોટા ઇન્ડેક્સમાં સંગ્રહિત કરે છે. આ અભિગમનો ફાયદો એ છે કે તમે જટિલ પ્રશ્નો ઝડપથી ચલાવી શકો છો, કારણ કે લગભગ તમામ ડેટા અનુક્રમણિકામાં છે. પરંતુ તમારે આ માટે ચૂકવણી કરવી પડશે જેમાં અનુક્રમણિકા મોટી બને છે, જે મેમરી આવશ્યકતાઓમાં અનુવાદ કરે છે. પરિણામે, લૉગ્સનું પૂર્ણ-ટેક્સ્ટ ઇન્ડેક્સ લૉગ્સ સાથે કદમાં તુલનાત્મક છે. તેના દ્વારા ઝડપથી શોધવા માટે, ઇન્ડેક્સને મેમરીમાં લોડ કરવું આવશ્યક છે. અને વધુ લૉગ્સ, ઝડપથી ઇન્ડેક્સ વધે છે અને વધુ મેમરી તે વાપરે છે.

લોકી અભિગમ માટે જરૂરી છે કે સ્ટ્રિંગમાંથી માત્ર જરૂરી ડેટા જ કાઢવામાં આવે, જેનાં મૂલ્યોની સંખ્યા ઓછી છે. આ રીતે આપણે એક નાનો ઇન્ડેક્સ મેળવીએ છીએ અને ડેટાને સમય અને અનુક્રમિત ફીલ્ડ દ્વારા ફિલ્ટર કરીને અને પછી રેગ્યુલર એક્સપ્રેશન્સ અથવા સબસ્ટ્રિંગ સર્ચ વડે બાકીનાને સ્કેન કરીને શોધી શકીએ છીએ. પ્રક્રિયા સૌથી ઝડપી લાગતી નથી, પરંતુ લોકી વિનંતીને કેટલાક ભાગોમાં વિભાજિત કરે છે અને તેને સમાંતર રીતે ચલાવે છે, ટૂંકા સમયમાં મોટી માત્રામાં ડેટાની પ્રક્રિયા કરે છે. તેમાંના શાર્ડ્સ અને સમાંતર વિનંતીઓની સંખ્યા રૂપરેખાંકિત છે; આમ, સમયના એકમ દીઠ પ્રક્રિયા કરી શકાય તેવા ડેટાની માત્રા પૂરી પાડવામાં આવેલ સંસાધનોની માત્રા પર રેખીય રીતે આધાર રાખે છે.

મોટા ફાસ્ટ ઇન્ડેક્સ અને નાના સમાંતર બ્રુટ-ફોર્સ ઇન્ડેક્સ વચ્ચેનો આ ટ્રેડ-ઓફ લોકીને સિસ્ટમની કિંમતને નિયંત્રિત કરવાની મંજૂરી આપે છે. તે તમારી જરૂરિયાતો અનુસાર લવચીક રીતે ગોઠવી શકાય છે અને વિસ્તૃત કરી શકાય છે.

લોકી સ્ટેકમાં ત્રણ ઘટકોનો સમાવેશ થાય છે: પ્રોમટેલ, લોકી, ગ્રાફના. પ્રોમટેલ લોગ એકત્રિત કરે છે, તેની પ્રક્રિયા કરે છે અને લોકીને મોકલે છે. લોકી તેમને રાખે છે. અને Grafana Loki પાસેથી ડેટાની વિનંતી કરી શકે છે અને તેને બતાવી શકે છે. સામાન્ય રીતે, લોકીનો ઉપયોગ ફક્ત લૉગ્સ સ્ટોર કરવા અને તેના દ્વારા શોધવા માટે જ થઈ શકે છે. સમગ્ર સ્ટેક પ્રોમિથિયસ માર્ગનો ઉપયોગ કરીને ઇનકમિંગ ડેટાની પ્રક્રિયા અને વિશ્લેષણ માટે ઉત્તમ તકો પૂરી પાડે છે.
ઇન્સ્ટોલેશન પ્રક્રિયાનું વર્ણન મળી શકે છે અહીં.

લોગ શોધ

તમે ખાસ ઈન્ટરફેસ Grafana — Explorer માં લોગ શોધી શકો છો. પ્રશ્નો LogQL ભાષાનો ઉપયોગ કરે છે, જે પ્રોમિથિયસ દ્વારા ઉપયોગમાં લેવાતી PromQL જેવી જ છે. સૈદ્ધાંતિક રીતે, તે વિતરિત grep તરીકે વિચારી શકાય છે.

શોધ ઈન્ટરફેસ આના જેવો દેખાય છે:

ક્વેરી પોતે બે ભાગો ધરાવે છે: પસંદગીકાર અને ફિલ્ટર. પસંદગીકાર એ અનુક્રમિત મેટાડેટા (લેબલ્સ) દ્વારા શોધ છે જે લોગને સોંપવામાં આવે છે, અને ફિલ્ટર એ શોધ સ્ટ્રિંગ અથવા રેગએક્સ છે જે પસંદગીકાર દ્વારા નિર્ધારિત રેકોર્ડ્સને ફિલ્ટર કરે છે. આપેલ ઉદાહરણમાં: સર્પાકાર કૌંસમાં - પસંદગીકાર, બધું પછી - ફિલ્ટર.

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

લોકી જે રીતે કાર્ય કરે છે તેના કારણે, તમે પસંદગીકાર વિના વિનંતીઓ કરી શકતા નથી, પરંતુ લેબલોને મનસ્વી રીતે સામાન્ય બનાવી શકાય છે.

પસંદગીકાર એ સર્પાકાર કૌંસમાં મૂલ્યનું મુખ્ય મૂલ્ય છે. તમે પસંદગીકારોને જોડી શકો છો અને =, != ઓપરેટર્સ અથવા રેગ્યુલર એક્સપ્રેશનનો ઉપયોગ કરીને વિવિધ શોધ શરતોનો ઉલ્લેખ કરી શકો છો:

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

ફિલ્ટર એ એક ટેક્સ્ટ અથવા regexp છે જે પસંદગીકાર દ્વારા પ્રાપ્ત થયેલ તમામ ડેટાને ફિલ્ટર કરશે.

મેટ્રિક્સ મોડમાં પ્રાપ્ત ડેટાના આધારે એડ-હૉક ગ્રાફ મેળવવાનું શક્ય છે. ઉદાહરણ તરીકે, તમે ઇન્ડેક્સ સ્ટ્રિંગ ધરાવતી એન્ટ્રીના nginx લોગમાં ઘટનાની આવર્તન શોધી શકો છો:

લક્ષણોનું સંપૂર્ણ વર્ણન દસ્તાવેજીકરણમાં મળી શકે છે લોગક્યુએલ.

લોગ પાર્સિંગ

લોગ એકત્રિત કરવાની ઘણી રીતો છે:

• પ્રોમટેલનો ઉપયોગ કરીને, લોગ એકત્રિત કરવા માટે સ્ટેકનો પ્રમાણભૂત ઘટક.
• સીધા ડોકર કન્ટેનરનો ઉપયોગ કરીને લોકી ડોકર લોગીંગ ડ્રાઈવર.
• Fluentd અથવા Fluent Bit નો ઉપયોગ કરો જે લોકીને ડેટા મોકલી શકે. પ્રોમટેલથી વિપરીત, તેમની પાસે લગભગ કોઈપણ પ્રકારના લોગ માટે તૈયાર પાર્સર છે અને તે મલ્ટિલાઈન લોગને પણ હેન્ડલ કરી શકે છે.

સામાન્ય રીતે પ્રોમટેલનો ઉપયોગ પદચ્છેદન માટે થાય છે. તે ત્રણ વસ્તુઓ કરે છે:

• ડેટા સ્ત્રોતો શોધે છે.
• તેમની સાથે લેબલ્સ જોડો.
• લોકીને ડેટા મોકલે છે.

હાલમાં Promtail સ્થાનિક ફાઇલો અને systemd જર્નલમાંથી લોગ વાંચી શકે છે. તે દરેક મશીન પર ઇન્સ્ટોલ કરવું આવશ્યક છે જેમાંથી લોગ એકત્રિત કરવામાં આવે છે.

કુબરનેટ્સ સાથે એકીકરણ છે: પ્રોમટેલ કુબરનેટ્સ REST API દ્વારા ક્લસ્ટરની સ્થિતિને આપમેળે શોધી કાઢે છે અને નોડ, સેવા અથવા પોડમાંથી લોગ એકત્રિત કરે છે, કુબરનેટ્સ (પોડ નામ, ફાઇલ નામ, વગેરે) ના મેટાડેટા પર આધારિત તરત જ લેબલ્સ પોસ્ટ કરે છે.

તમે પાઈપલાઈનનો ઉપયોગ કરીને લોગના ડેટાના આધારે લેબલ પણ હેંગ કરી શકો છો. પાઇપલાઇન પ્રોમટેલમાં ચાર પ્રકારના તબક્કાઓ હોઈ શકે છે. વધુ વિગતો - માં સત્તાવાર દસ્તાવેજીકરણ, હું તરત જ કેટલીક ઘોંઘાટની નોંધ લઈશ.

1. તબક્કાઓનું વિશ્લેષણ. આ RegEx અને JSON નું સ્ટેજ છે. આ તબક્કે, અમે કહેવાતા એક્સટ્રેક્ટેડ નકશામાં લોગમાંથી ડેટા કાઢીએ છીએ. તમે JSON માંથી એક્સટ્રેક્ટેડ નકશામાં અથવા રેગ્યુલર એક્સપ્રેશન્સ (RegEx) દ્વારા, જ્યાં નામવાળા જૂથોને એક્સટ્રેક્ટેડ નકશામાં "મેપ" કરવામાં આવે છે તે ફીલ્ડ્સની કૉપિ કરીને ફક્ત JSON માંથી એક્સટ્રેક્ટ કરી શકો છો. એક્સટ્રેક્ટેડ મેપ એ કી-વેલ્યુ સ્ટોરેજ છે, જ્યાં કી એ ફીલ્ડનું નામ છે, અને મૂલ્ય એ લોગમાંથી તેનું મૂલ્ય છે.
2. તબક્કાઓ પરિવર્તન. આ તબક્કામાં બે વિકલ્પો છે: ટ્રાન્સફોર્મ, જ્યાં અમે ટ્રાન્સફોર્મેશનના નિયમો સેટ કરીએ છીએ, અને સ્ત્રોત - એક્સટ્રેક્ટેડ નકશામાંથી ટ્રાન્સફોર્મેશન માટેનો ડેટા સ્ત્રોત. જો એક્સટ્રેક્ટેડ નકશામાં આવી કોઈ ફીલ્ડ નથી, તો તે બનાવવામાં આવશે. આ રીતે લેબલ્સ બનાવવાનું શક્ય છે જે એક્સ્ટ્રેક્ટેડ નકશા પર આધારિત નથી. આ તબક્કે આપણે એક્સ્ટ્રેક્ટેડ મેપમાંના ડેટાને એકદમ પાવરફુલનો ઉપયોગ કરીને હેરફેર કરી શકીએ છીએ ગોલાંગ નમૂનો. વધુમાં, આપણે યાદ રાખવું જોઈએ કે પાર્સિંગ દરમિયાન એક્સ્ટ્રેક્ટ કરેલ નકશો સંપૂર્ણ રીતે લોડ થયેલ છે, જે તેને શક્ય બનાવે છે, ઉદાહરણ તરીકે, તેમાં મૂલ્ય તપાસવું: “{{if .tag}ટેગ મૂલ્ય અસ્તિત્વમાં છે{end}}””. ટેમ્પલેટ શરતો, લૂપ્સ અને કેટલાક સ્ટ્રિંગ ફંક્શનને સપોર્ટ કરે છે જેમ કે બદલો અને ટ્રીમ.
3. ક્રિયાના તબક્કા. આ તબક્કે, તમે અર્ક સાથે કંઈક કરી શકો છો:
   • એક્સટ્રેક્ટ કરેલા ડેટામાંથી એક લેબલ બનાવો, જે લોકી દ્વારા અનુક્રમિત કરવામાં આવશે.
   • લોગમાંથી ઇવેન્ટનો સમય બદલો અથવા સેટ કરો.
   • ડેટા (લોગ ટેક્સ્ટ) બદલો જે લોકીમાં જશે.
   • મેટ્રિક્સ બનાવો.
4. ફિલ્ટરિંગ તબક્કાઓ. મેચ સ્ટેજ, જ્યાં અમે કાં તો એવા રેકોર્ડ મોકલી શકીએ છીએ કે જેને અમારે /dev/null કરવાની જરૂર નથી અથવા આગળની પ્રક્રિયા માટે મોકલી શકીએ છીએ.

સામાન્ય nginx લોગ પર પ્રક્રિયા કરવાના ઉદાહરણનો ઉપયોગ કરીને, હું બતાવીશ કે તમે Promtail નો ઉપયોગ કરીને કેવી રીતે લોગનું પાર્સ કરી શકો છો.

પરીક્ષણ માટે, ચાલો એક સંશોધિત nginx jwilder/nginx-proxy:alpine ઇમેજ અને એક નાનો ડિમન લઈએ જે nginx-proxy તરીકે HTTP દ્વારા ક્વેરી કરી શકે છે. ડિમન પાસે ઘણા અંતિમ બિંદુઓ છે, જેના પર તે વિવિધ કદના પ્રતિભાવો આપી શકે છે, વિવિધ 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>[^/?.]+).*$

ચાલો 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 લોગ લોકીમાં જાય છે.

ઉપરોક્ત રૂપરેખા ચલાવ્યા પછી, તમે જોઈ શકો છો કે દરેક એન્ટ્રી લોગના ડેટાના આધારે લેબલ થયેલ છે.

ધ્યાનમાં રાખવાની એક વાત એ છે કે મોટી સંખ્યામાં મૂલ્યો (કાર્ડિનેલિટી) સાથેના લેબલ્સ પુનઃપ્રાપ્ત કરવાથી લોકીને નોંધપાત્ર રીતે ધીમું થઈ શકે છે. એટલે કે, તમારે ઇન્ડેક્સમાં, ઉદાહરણ તરીકે, user_id મૂકવો જોઈએ નહીં. લેખમાં આ વિશે વધુ વાંચો “લોકીમાંના લેબલ્સ લોગ ક્વેરીઝને ઝડપી અને સરળ કેવી રીતે બનાવી શકે છે" પરંતુ આનો અર્થ એ નથી કે તમે ઇન્ડેક્સ વિના user_id દ્વારા શોધી શકતા નથી. શોધ કરતી વખતે ફિલ્ટર્સનો ઉપયોગ કરવો જરૂરી છે (ડેટા અનુસાર "ગ્રેબ"), અને અહીં અનુક્રમણિકા સ્ટ્રીમ ઓળખકર્તા તરીકે કાર્ય કરે છે.

લોગ વિઝ્યુલાઇઝેશન

LogQL નો ઉપયોગ કરીને ગ્રાફના ગ્રાફ માટે લોકી ડેટા સ્ત્રોત તરીકે કાર્ય કરી શકે છે. નીચેની સુવિધાઓ સપોર્ટેડ છે:

• દર - સેકન્ડ દીઠ રેકોર્ડ્સની સંખ્યા;
• સમય પર ગણતરી કરો - આપેલ શ્રેણીમાં રેકોર્ડ્સની સંખ્યા.

સમ, સરેરાશ અને અન્ય એકંદર કાર્યો પણ છે. તમે તદ્દન જટિલ ગ્રાફ બનાવી શકો છો, ઉદાહરણ તરીકે, HTTP ભૂલોની સંખ્યાનો ગ્રાફ:

લોકીનો ડિફોલ્ટ ડેટા સ્ત્રોત પ્રોમિથિયસ ડેટા સ્ત્રોત કરતાં થોડો ઓછો કાર્યાત્મક છે (ઉદાહરણ તરીકે, તમે દંતકથા બદલી શકતા નથી), પરંતુ લોકીને પ્રોમિથિયસ પ્રકારના સ્ત્રોત તરીકે કનેક્ટ કરી શકાય છે. મને ખાતરી નથી કે આ વર્તન દસ્તાવેજીકૃત છે કે કેમ, પરંતુ વિકાસકર્તાઓના પ્રતિસાદ દ્વારા નક્કી કરવામાં આવે છે “લોકીને પ્રોમિથિયસ ડેટાસોર્સ તરીકે કેવી રીતે ગોઠવવું? · અંક #1222 · ગ્રાફના/લોકી”, ઉદાહરણ તરીકે, સંપૂર્ણપણે કાનૂની છે, અને Loki PromQL સાથે સંપૂર્ણપણે સુસંગત છે.

Prometheus પ્રકાર સાથે લોકીને ડેટા સ્ત્રોત તરીકે ઉમેરો અને 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

વિકલ્પ તમને એક્સટ્રેક્ટેડ નકશામાંથી ડેટાના આધારે મેટ્રિક્સને વ્યાખ્યાયિત અને અપડેટ કરવાની મંજૂરી આપે છે. આ મેટ્રિક્સ લોકીને મોકલવામાં આવતા નથી - તે પ્રોમટેલ/મેટ્રિક્સ એન્ડપોઇન્ટમાં દેખાય છે. પ્રોમિથિયસને આ તબક્કામાંથી ડેટા પ્રાપ્ત કરવા માટે રૂપરેખાંકિત કરવું આવશ્યક છે. ઉપરના ઉદાહરણમાં, 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']

અને ગ્રાફ દોરો:

આ રીતે તમે શોધી શકો છો, ઉદાહરણ તરીકે, ચાર સૌથી ધીમી વિનંતીઓ. તમે આ મેટ્રિક્સ માટે મોનિટરિંગ પણ ગોઠવી શકો છો.

સ્કેલિંગ

લોકી સિંગલ બાઈનરી મોડ અને શાર્ડેડ (હોરીઝોન્ટલી-સ્કેલેબલ મોડ) બંનેમાં હોઈ શકે છે. બીજા કિસ્સામાં, તે ક્લાઉડમાં ડેટા સાચવી શકે છે, અને હિસ્સા અને અનુક્રમણિકા અલગથી સંગ્રહિત થાય છે. સંસ્કરણ 1.5 માં, એક જગ્યાએ સ્ટોર કરવાની ક્ષમતા લાગુ કરવામાં આવી છે, પરંતુ ઉત્પાદનમાં તેનો ઉપયોગ કરવાની હજુ સુધી ભલામણ કરવામાં આવી નથી.

હિસ્સાને S3-સુસંગત સ્ટોરેજમાં સંગ્રહિત કરી શકાય છે, ઇન્ડેક્સ સ્ટોર કરવા માટે, આડા સ્કેલેબલ ડેટાબેસેસનો ઉપયોગ કરો: Cassandra, BigTable અથવા DynamoDB. લોકીના અન્ય ભાગો - ડિસ્ટ્રીબ્યુટર્સ (લેખન માટે) અને ક્વેરીઅર (ક્વેરી માટે) - સ્ટેટલેસ છે અને આડા સ્કેલ પણ છે.

DevOpsDays Vancouver 2019 કોન્ફરન્સમાં, એક સહભાગી Callum Styan એ જાહેરાત કરી કે લોકી સાથે તેના પ્રોજેક્ટમાં કુલ કદના 1% કરતા ઓછા ઇન્ડેક્સ સાથે પેટાબાઇટ્સ લોગ છે: “લોકી મેટ્રિક્સ અને લૉગ્સને કેવી રીતે સંબંધિત કરે છે — અને તમારા પૈસા બચાવે છે".

લોકી અને ELK ની સરખામણી

ઇન્ડેક્સનું કદ

પરિણામી અનુક્રમણિકાના કદને ચકાસવા માટે, મેં nginx કન્ટેનરમાંથી લોગ લીધા જેના માટે ઉપરની પાઇપલાઇન ગોઠવેલી હતી. લોગ ફાઇલમાં 406 MB ના કુલ વોલ્યુમ સાથે 624 રેખાઓ છે. લૉગ્સ એક કલાકમાં જનરેટ થયા હતા, લગભગ 109 રેકોર્ડ પ્રતિ સેકન્ડ.

લોગમાંથી બે લીટીઓનું ઉદાહરણ:

જ્યારે ELK દ્વારા અનુક્રમિત કરવામાં આવે છે, ત્યારે તે 30,3 MB નું ઇન્ડેક્સ કદ આપે છે:

લોકીના કિસ્સામાં, આનાથી લગભગ 128 KB ઇન્ડેક્સ અને લગભગ 3,8 MB ડેટા હિસ્સામાં મળે છે. તે નોંધવું યોગ્ય છે કે લોગ કૃત્રિમ રીતે જનરેટ કરવામાં આવ્યો હતો અને તેમાં વિવિધ પ્રકારના ડેટા દર્શાવવામાં આવ્યા ન હતા. ડેટા સાથેના મૂળ ડોકર JSON લોગ પર એક સરળ gzip એ 95,4% નું કમ્પ્રેશન આપ્યું હતું, અને આપેલ છે કે માત્ર સાફ કરેલ nginx લોગ જ લોકીને મોકલવામાં આવ્યો હતો, 4 MB સુધીનું સંકોચન સમજી શકાય તેવું છે. લોકી લેબલ્સ માટે અનન્ય મૂલ્યોની કુલ સંખ્યા 35 હતી, જે અનુક્રમણિકાના નાના કદને સમજાવે છે. ELK માટે, લોગ પણ સાફ કરવામાં આવ્યો હતો. આમ, લોકીએ મૂળ ડેટાને 96% અને ELK ને 70% સંકુચિત કર્યો.

મેમરી વપરાશ

જો આપણે પ્રોમિથિયસ અને ELK ના સમગ્ર સ્ટેકની તુલના કરીએ, તો લોકી ઘણી વખત ઓછું "ખાય છે". તે સ્પષ્ટ છે કે ગો સેવા Java સેવા કરતા ઓછો વપરાશ કરે છે, અને Heap Elasticsearch JVM ના કદ અને લોકી માટે ફાળવેલ મેમરીની સરખામણી કરવી અયોગ્ય છે, પરંતુ તેમ છતાં, એ નોંધવું યોગ્ય છે કે લોકી ઘણી ઓછી મેમરી વાપરે છે. તેનો CPU ફાયદો એટલો સ્પષ્ટ નથી, પરંતુ તે હાજર પણ છે.

ઝડપ

લોકી વધુ ઝડપથી લોગ "ભક્ષી જાય છે". ઝડપ ઘણા પરિબળો પર આધાર રાખે છે - કેવા પ્રકારના લોગ, અમે તેમને કેવી રીતે વિશ્લેષિત કરીએ છીએ, નેટવર્ક, ડિસ્ક, વગેરે - પરંતુ તે ચોક્કસપણે ELK કરતા વધારે છે (મારા પરીક્ષણમાં - લગભગ બે વખત). આ એ હકીકત દ્વારા સમજાવવામાં આવ્યું છે કે લોકી ઇન્ડેક્સમાં ઘણો ઓછો ડેટા મૂકે છે અને તે મુજબ, ઇન્ડેક્સિંગ પર ઓછો સમય વિતાવે છે. આ કિસ્સામાં, શોધની ઝડપ સાથે પરિસ્થિતિ ઉલટી થાય છે: લોકી થોડા ગીગાબાઇટ્સ કરતા મોટા ડેટા પર નોંધપાત્ર રીતે ધીમો પડી જાય છે, જ્યારે ELK માટે, શોધ ઝડપ ડેટાના કદ પર આધારિત નથી.

લોગ શોધ

લોગ શોધ ક્ષમતાઓના સંદર્ભમાં લોકી ELK કરતા નોંધપાત્ર રીતે હલકી ગુણવત્તાવાળા છે. રેગ્યુલર એક્સપ્રેશન સાથે ગ્રેપ એ એક મજબૂત વસ્તુ છે, પરંતુ તે પુખ્ત ડેટાબેઝ કરતા હલકી ગુણવત્તાવાળા છે. રેન્જ ક્વેરીઝનો અભાવ, ફક્ત લેબલ્સ દ્વારા એકત્રીકરણ, લેબલ વિના શોધવાની અસમર્થતા - આ બધું અમને લોકીમાં રુચિની માહિતી શોધવામાં મર્યાદિત કરે છે. આનો અર્થ એ નથી કે Loki નો ઉપયોગ કરીને કંઈપણ શોધી શકાતું નથી, પરંતુ તે લોગ સાથે કામ કરવાના પ્રવાહને વ્યાખ્યાયિત કરે છે, જ્યારે તમને પ્રથમ પ્રોમિથિયસ ચાર્ટ્સ પર કોઈ સમસ્યા મળે છે, અને પછી આ લેબલ્સનો ઉપયોગ કરીને લોગમાં શું થયું તે જુઓ.

ઈન્ટરફેસ

પ્રથમ બોલ, તે સુંદર છે (માફ કરશો, પ્રતિકાર કરી શક્યા નથી). ગ્રાફનામાં સુંદર દેખાતા ઈન્ટરફેસ છે, પરંતુ કિબાના વધુ કાર્યાત્મક છે.

લોકી ગુણદોષ

એક ફાયદો એ છે કે લોકી પ્રોમિથિયસ સાથે એકીકૃત થાય છે, તેથી અમને બૉક્સની બહાર મેટ્રિક્સ અને ચેતવણી મળે છે. તે લૉગ્સ એકત્રિત કરવા અને તેને કુબરનેટસ પોડ્સમાંથી સંગ્રહિત કરવા માટે અનુકૂળ છે, કારણ કે તે પ્રોમિથિયસ પાસેથી વારસામાં મળેલી સેવા શોધ ધરાવે છે અને આપમેળે લેબલ્સ જોડે છે.

ગેરફાયદામાંથી - નબળા દસ્તાવેજીકરણ. કેટલીક વસ્તુઓ, જેમ કે પ્રોમટેલની વિશેષતાઓ અને ક્ષમતાઓ, મેં કોડના અભ્યાસની પ્રક્રિયામાં જ શોધી કાઢી, ઓપન-સોર્સનો ફાયદો. અન્ય ગેરલાભ એ નબળા પદચ્છેદન ક્ષમતાઓ છે. ઉદાહરણ તરીકે, લોકી મલ્ટિલાઈન લોગનું વિશ્લેષિત કરી શકતું નથી. ઉપરાંત, ગેરફાયદામાં એ હકીકતનો સમાવેશ થાય છે કે લોકી પ્રમાણમાં યુવાન તકનીક છે (પ્રકાશન 1.0 નવેમ્બર 2019 માં હતું).

નિષ્કર્ષ

લોકી એ 100% રસપ્રદ તકનીક છે જે નાના અને મધ્યમ પ્રોજેક્ટ્સ માટે યોગ્ય છે, જે તમને લોગ એકત્રીકરણ, લોગ સર્ચ, મોનિટરિંગ અને લોગના વિશ્લેષણની ઘણી સમસ્યાઓ હલ કરવાની મંજૂરી આપે છે.

અમે Badoo પર લોકીનો ઉપયોગ કરતા નથી, કારણ કે અમારી પાસે એક ELK સ્ટેક છે જે અમને અનુકૂળ છે અને તે વર્ષોથી વિવિધ કસ્ટમ સોલ્યુશન્સ સાથે વધુ ઉગાડવામાં આવ્યો છે. અમારા માટે, ઠોકર ખાનારો એ લોગમાં શોધ છે. દરરોજ લગભગ 100 GB લૉગ્સ સાથે, અમારા માટે બધું અને થોડું વધુ શોધવામાં સક્ષમ બનવું અને તે ઝડપથી કરવું મહત્વપૂર્ણ છે. ચાર્ટિંગ અને મોનિટરિંગ માટે, અમે અન્ય ઉકેલોનો ઉપયોગ કરીએ છીએ જે અમારી જરૂરિયાતોને અનુરૂપ છે અને એકબીજા સાથે સંકલિત છે. લોકી સ્ટેકમાં મૂર્ત લાભો છે, પરંતુ તે આપણને આપણી પાસે જે છે તેના કરતાં વધુ આપશે નહીં, અને તેના લાભો સ્થળાંતર કરવાની કિંમત કરતાં બરાબર નહીં હોય.

અને તેમ છતાં સંશોધન પછી તે સ્પષ્ટ થઈ ગયું કે અમે લોકીનો ઉપયોગ કરી શકતા નથી, અમે આશા રાખીએ છીએ કે આ પોસ્ટ તમને પસંદ કરવામાં મદદ કરશે.

લેખમાં વપરાયેલ કોડ સાથેનો ભંડાર સ્થિત છે અહીં.

સોર્સ: www.habr.com