🥇કુબર્નેટ્સમાં લોગિંગ: લોગ કેવી રીતે એકત્રિત કરવા, સંગ્રહિત કરવા, પાર્સ કરવા અને પ્રક્રિયા કરવા

ચાલો ડોકર અને કુબરનેટ્સમાં લોગીંગની મૂળભૂત બાબતો પર જઈએ, અને પછી ઉત્પાદનમાં સુરક્ષિત રીતે ઉપયોગમાં લઈ શકાય તેવા બે સાધનો જોઈએ: ગ્રાફના લોકી અને EFK સ્ટેક (Elasticsearch + Fluent Bit + Kibana).

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

ડોકર લોગીંગ

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

હું આશા રાખું છું કે દરેક વાચક જાણતા હશે: એપ્લિકેશન લૉગ્સ stdout/stderr પર લખવા જોઈએ, અને કન્ટેનરની અંદર નહીં. લોગ્સ ડોકર ડિમન દ્વારા એકત્રિત કરવામાં આવે છે, અને તે તે લોગ સાથે બરાબર કામ કરે છે જે stdout/stderr ને મોકલવામાં આવે છે. વધુમાં, કન્ટેનરની અંદર લૉગ્સ લખવામાં સમસ્યા હોય છે: કન્ટેનર વધતા લોગમાંથી ફૂલી જાય છે (કારણ કે કન્ટેનરમાં કોઈ લોગ્રોટેટ નથી) અને ડોકર ડિમન આ લોગથી વાકેફ નથી.

ડોકર પાસે કન્ટેનર લોગીંગ એકત્ર કરવા માટે ઘણા લોગીંગ ડ્રાઈવરો અથવા પ્લગઈનો છે. ફ્રી ડોકર કોમ્યુનિટી એડિશન (CE) પાસે કોમર્શિયલ ડોકર એન્ટરપ્રાઇઝ એડિશન (EE) કરતાં ઓછા લોગ ડ્રાઇવરો છે.

મેં વ્યવહારમાં ક્યારેય ડોકર ઇઇનો ઉપયોગ કર્યો નથી: સાઉથબ્રિજ ખાતે અમે ઓપન સોર્સ સોલ્યુશન્સને વળગી રહેવાનો પ્રયાસ કરીએ છીએ, અને ગ્રાહકોને ડોકર ઇઇની મોટાભાગની વધારાની સુવિધાઓની જરૂર નથી.

ડોકર સીઇમાં લોગ ડ્રાઇવરો:

સ્થાનિક - આંતરિક ડોકર ડિમન ફાઇલોમાં લૉગ્સ લખવા;
json ફાઇલ - દરેક કન્ટેનરના ફોલ્ડરમાં json-log બનાવવું;
જર્નલ - જર્નાલ્ડ પર લોગ મોકલી રહ્યા છીએ.

ડોકર લોગીંગ સેટિંગ્સ daemon.json ફાઇલમાં સ્થિત છે.

"લોગ-ડ્રાઇવર" ફીલ્ડ પ્લગઇનનો ઉલ્લેખ કરે છે, અને "લોગ-ઓપ્ટ્સ" ફીલ્ડ તેની સેટિંગ્સનો ઉલ્લેખ કરે છે. ઉપરના ઉદાહરણમાં, "json-file" પ્લગઇન ઉલ્લેખિત છે, લોગ માપ મર્યાદા "max-size" છે: "10m"; ફાઇલોની સંખ્યા પર મર્યાદા (રોટેશન સેટિંગ્સ) — “મેક્સ-ફાઇલ”: “3”; તેમજ મૂલ્યો કે જે લોગ સાથે જોડવામાં આવશે.

કેટલાક લોગ ડ્રાઈવર સેટિંગ્સ આદેશ વાક્ય ઉપયોગિતા દ્વારા સેટ કરી શકાય છે. જો અલગ કન્ટેનરને અલગ લોગ ડ્રાઈવર સાથે ચલાવવાની જરૂર હોય તો આ ઉપયોગી છે.

ડોકરમાં લોગીંગ સ્કીમ કેવી દેખાય છે તે અહીં છે:

સ્કીમ કેવી રીતે કામ કરે છે: json-file જેવો લોગ ડ્રાઈવર ફાઈલો બનાવે છે. લોગ કલેક્ટર્સ (Rsyslog, Fluentd, Logagent અને અન્ય) આ ફાઇલો એકત્રિત કરે છે અને તેને સ્થિતિસ્થાપક, Sematext અથવા અન્ય સ્ટોરેજમાં સ્ટોરેજમાં ટ્રાન્સફર કરે છે.

કુબરનેટ્સમાં લોગીંગની સુવિધાઓ

સરળ, કુબરનેટ્સમાં લોગીંગ સ્કીમ આના જેવી દેખાય છે: ત્યાં એક પોડ છે, તેમાં એક કન્ટેનર ચાલી રહ્યું છે, કન્ટેનર stdout/stderr ને લોગ મોકલે છે. ડોકર પછી ફાઈલ બનાવે છે અને લોગ લખે છે, જેને તે પછી ફેરવી શકે છે.

કુબરનેટ્સમાં લોગીંગની સુવિધાઓ ધ્યાનમાં લો.

જમાવટ વચ્ચે લોગ સાચવો. યોગ્ય લોગીંગ સેટિંગ્સ માટે આ એક પૂર્વશરત છે. જો તમે જમાવટ વચ્ચે લૉગ્સ સાચવતા નથી, તો જ્યારે એપ્લિકેશનનું નવું સંસ્કરણ પ્રકાશિત થાય છે, ત્યારે પહેલાના લોગ્સ ઓવરરાઈટ થઈ જશે, કન્ટેનરને ફરીથી લોડ કરવાથી પણ લોગના નુકસાનથી ભરપૂર હશે. Kubernetes પાસે --previous કી છે, તે તમને છેલ્લી Pod પુનઃપ્રારંભ થાય તે પહેલા એપ્લિકેશન લોગ જોવાની પરવાનગી આપે છે, પરંતુ વધુ ઊંડે નહીં.

તમામ ઉદાહરણોમાંથી એકંદર લોગ. જો માઇક્રોસર્વિસિસ ક્લાઉડ્સમાં હોસ્ટ કરવામાં આવે છે, તો ક્લાઉડ પ્રદાતા સિસ્ટમ નિયંત્રણ માટે જવાબદાર છે. જો માઇક્રોસર્વિસિસ તેમના પોતાના હાર્ડવેર પર હોય, તો પછી કન્ટેનરમાંથી લોગ ઉપરાંત, તમારે સિસ્ટમ લોગ્સ પણ એકત્રિત કરવાની જરૂર છે.

પહેલાં, સિસ્ટમ અને માઇક્રોસર્વિસિસ બંનેમાંથી લોગ એકત્રિત કરવા માટે કોઈ અનુકૂળ સાધનો નહોતા. સામાન્ય રીતે, એક ટૂલ સિસ્ટમ લોગ એકત્રિત કરતું હતું (ઉદાહરણ તરીકે, Rsyslog), અને બીજું ડોકરમાંથી લોગ એકત્રિત કરતું હતું (ઉદાહરણ તરીકે, ડોકર લોગ ડ્રાઇવર સાથે જર્નલ-બીટ જર્નલ્ડ પર ગોઠવાયેલ). અમે બંને કન્ટેનરમાંથી લોગ એકત્રિત કરવા માટે જર્નલ-બીટનો ઉપયોગ કરવાનો પ્રયાસ કર્યો (ડોકર લોગ ડ્રાઇવરમાં સ્પષ્ટ કરીને કે લોગ જર્નલ્ડ પર લખવા જોઈએ) અને સિસ્ટમમાંથી (માં CentOS 7 માં પહેલાથી જ systemd અને journald છે. ઉકેલ કામ કરે છે, પરંતુ તે આદર્શ નથી. જો ઘણા બધા લોગ હોય, તો journal-bit પાછળ રહેવાનું શરૂ કરે છે, અને સંદેશાઓ ખોવાઈ જાય છે.

પ્રયોગો ચાલુ રહ્યા અને બીજો રસ્તો મળી આવ્યો. CentOS var લોગમાં 7 મુખ્ય સિસ્ટમ લોગ (સંદેશાઓ, ઓડિટ, સુરક્ષિત) ફાઇલો તરીકે ડુપ્લિકેટ કરવામાં આવે છે. ડોકરને JSON ફાઇલોમાં લોગ સાચવવા માટે પણ ગોઠવી શકાય છે. તે મુજબ, આ ફાઇલો CentOS 7 અને ડોકર એકસાથે બનાવી શકાય છે.

સમય જતાં, ELK સ્ટેક સોલ્યુશન લોકપ્રિય બન્યું. તે ઘણા ટૂલ્સનું સંયોજન છે: ઇલાસ્ટિકસર્ચ, લોગસ્ટાશ અને કિબાના.

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

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

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

એક નિયમ તરીકે, તમારે બધા લૉગ્સ એકત્રિત અને સંગ્રહિત કરવાની જરૂર નથી, તમારે સંગ્રહ માટે માત્ર એક ભાગ મોકલવાની જરૂર છે - ઉદાહરણ તરીકે, સ્થિતિ "ચેતવણી" અથવા "ભૂલ" સાથેના લૉગ્સ. જો આપણે nginx અથવા ingress કંટ્રોલર લોગ વિશે વાત કરી રહ્યા છીએ, તો ફક્ત તે જ જેમની સ્થિતિ 200 થી અલગ છે સ્ટોરેજ માટે મોકલી શકાય છે. પરંતુ આ સાર્વત્રિક સલાહ નથી: જો તમે કોઈક રીતે Nginx લોગ પર આધારિત વિશ્લેષણ બનાવો છો, તો તે દેખીતી રીતે એકત્રિત કરવા યોગ્ય છે.

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

સામાન્ય રીતે, અહીં તમારે કાળજીપૂર્વક વિચારવાની જરૂર છે: તમે શું સંગ્રહિત કરવા માંગો છો અને કેટલા સમય માટે, કારણ કે અન્યથા એક પરિસ્થિતિ ઊભી થશે જ્યારે લોગિંગ સિસ્ટમ મુખ્ય પ્રોજેક્ટ કરતાં વધુ સંસાધનો લેશે.

લોગીંગ માટે હજુ સુધી કોઈ પ્રમાણભૂત ઉકેલ નથી. મોનિટરિંગથી વિપરીત, જ્યાં એક સૌથી સામાન્ય પ્રોમિથિયસ સોલ્યુશન છે, ત્યાં લોગીંગમાં કોઈ ધોરણ નથી.

આ વ્યાખ્યાનમાં, આપણે બે સાધનો જોઈશું: એક લોકપ્રિય છે, અને બીજું લોકપ્રિયતા મેળવી રહ્યું છે. તેમના ઉપરાંત, અન્ય લોકો પણ છે, પરંતુ આ લેખમાં અમે તેમને સ્પર્શ કરીશું નહીં.

ઉપર ચર્ચા કરેલ તમામ વિશેષતાઓને ધ્યાનમાં લેતા, કુબરનેટ્સમાં લોગીંગ હવે નીચેની રીતે રજૂ કરી શકાય છે:

કન્ટેનર લોગ રહે છે, પરિભ્રમણ, પરંતુ કલેક્ટર એજન્ટ દેખાય છે, જે લોગને ઉપાડે છે અને તેને સંગ્રહ માટે મોકલે છે (ડાયાગ્રામમાં - લોગિંગ બેકએન્ડમાં). એજન્ટ દરેક નોડ પર ચાલે છે અને સામાન્ય રીતે કુબરનેટ્સ પર ચાલે છે.

હવે લોગીંગ માટેના સાધનોનો વિચાર કરો.

ગ્રાફના લોકી

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

જેમણે વાંચ્યું નથી તેમના માટે TSDB વિશે એક નાનું ડિગ્રેશન અગાઉનો લેખ: TSDB મોટી માત્રામાં ડેટા, ટાઈમ સીરીઝ સ્ટોર કરવા માટે એક સરસ કામ કરે છે, પરંતુ તે લાંબા ગાળાના સ્ટોરેજ માટે રચાયેલ નથી. જો કોઈ કારણોસર તમારે બે અઠવાડિયાથી વધુ સમય માટે લૉગ્સ સ્ટોર કરવાની જરૂર હોય, તો તેમના સ્થાનાંતરણને બીજા ડેટાબેઝમાં ગોઠવવાનું વધુ સારું છે.

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

લોકી આર્કિટેક્ચર કંઈક આના જેવું લાગે છે:

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

લોકી ઇન્સ્ટોલેશન સૂચનાઓ

લોકી પરિચિત Grafana ઇન્ટરફેસમાં ચાલે છે. લોકીની પોતાની ક્વેરી લેંગ્વેજ પણ છે જેને LogQL કહેવાય છે, જે નામ અને સિન્ટેક્સમાં Prometheus માં PromQL જેવી જ છે. લોકી ઇન્ટરફેસમાં પ્રશ્નો સાથેના સંકેતો છે, તેથી તેને હૃદયથી જાણવું જરૂરી નથી.

LogQL દસ્તાવેજીકરણ

Grafana ઈન્ટરફેસમાં Loki

ફિલ્ટર્સનો ઉપયોગ કરીને, લોકી કોડ્સ શોધી શકે છે (“400”, “404” અને અન્ય કોઈપણ); સમગ્ર નોડમાંથી લોગ જુઓ; "ભૂલ" શબ્દ ધરાવતા તમામ લોગને ફિલ્ટર કરો. જો તમે લોગ પર ક્લિક કરો છો, તો ઇવેન્ટની તમામ માહિતી સાથેનું કાર્ડ ખુલશે.

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

સ્થિતિસ્થાપક + ફ્લુઅન્ટ બીટ + કિબાના (EFK સ્ટેક)

EFK સ્ટેક એ વધુ ક્લાસિક છતાં સમાન રીતે લોકપ્રિય લોગીંગ ટૂલ છે.

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

વિકાસકર્તાઓના મતે, Fluentd કરતાં Fluent Bit પ્રદર્શનમાં 100 ગણું વધુ સારું છે: “જ્યાં Fluentd 20 MB RAM વાપરે છે, Fluent Bit 150 KB વાપરે છે” - દસ્તાવેજીકરણમાંથી સીધો અવતરણ. આને જોતા, ફ્લુએન્ટ બીટનો વધુ વ્યાપક ઉપયોગ થયો છે.

Fluentd કરતાં Fluent Bitમાં ઓછી સુવિધાઓ છે, પરંતુ તે મુખ્ય જરૂરિયાતોને આવરી લે છે, તેથી અમે મોટે ભાગે Fluent Bit નો ઉપયોગ કરીએ છીએ.

EFK સ્ટેક કેવી રીતે કામ કરે છે: એજન્ટ તમામ પોડ્સ (સામાન્ય રીતે બધા ક્લસ્ટર સર્વર્સ પર ચાલતો ડેમનસેટ) માંથી લોગ એકત્રિત કરે છે અને તેમને સ્ટોરેજ (Elasticsearch, PostgreSQL અથવા કાફકા) પર મોકલે છે. કિબાના રીપોઝીટરી સાથે જોડાય છે અને ત્યાંથી તમામ જરૂરી માહિતી પુનઃપ્રાપ્ત કરે છે.

કિબના વપરાશકર્તા મૈત્રીપૂર્ણ વેબ ઈન્ટરફેસમાં માહિતી રજૂ કરે છે. ત્યાં ચાર્ટ, ફિલ્ટર્સ અને વધુ છે.

સમગ્ર ડેશબોર્ડ બનાવવા માટે લોગનો ઉપયોગ કરી શકાય છે.

ફ્લુઅન્ટ બીટ સુવિધાઓ

Fluent Bit સામાન્ય રીતે Logstash કરતાં ઓછું સાંભળવામાં આવતું હોવાથી, ચાલો તેના પર નજીકથી નજર કરીએ. ફ્લુઅન્ટ બીટને તાર્કિક રીતે 6 મોડ્યુલોમાં વિભાજિત કરી શકાય છે અને ફ્લુઅન્ટ બીટની ક્ષમતાઓને વિસ્તારતા કેટલાક મોડ્યુલો સાથે પ્લગઈન્સ જોડી શકાય છે.

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

ઉત્પાદનમાં, અમે મોટાભાગે પ્લગિન્સનો ઉપયોગ કરીએ છીએ પૂંછડી (તે લોગ સાથે ફોલ્ડર પર સેટ કરી શકાય છે) અને systemd (તેને કહી શકાય કે કઈ સેવાઓમાંથી લોગ એકત્રિત કરવા).

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

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

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

રૂટીંગ/આઉટપુટ મોડ્યુલ લોગ મોકલવા માટેના નિયમો અને સરનામા સમાવે છે. પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, લૉગ્સ Elasticsearch, PostgreSQL અથવા ઉદાહરણ તરીકે, કાફકા પર મોકલી શકાય છે.

રસપ્રદ વાત એ છે કે, ફ્લુએન્ટ બીટથી ફ્લુએન્ટમાં લોગ મોકલી શકાય છે. પ્રથમ વધુ હલકો અને ઓછું કાર્યાત્મક હોવાથી, તમે તેના દ્વારા લોગ એકત્રિત કરી શકો છો અને તેને Fluentd પર મોકલી શકો છો, અને પહેલેથી જ ત્યાં, વધારાના પ્લગિન્સની મદદથી, તે વધુ પ્રક્રિયા કરી શકાય છે અને સ્ટોરેજમાં મોકલી શકાય છે.

જો તમે Elasticsearch નો ઉપયોગ કરવાની યોજના ઘડી રહ્યા છો...
છેલ્લે, જેઓ ઉત્પાદનમાં લોગ રીપોઝીટરી તરીકે Elasticsearch નો ઉપયોગ કરવાની યોજના ધરાવે છે તેમના માટે બે ટીપ્સ.

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

એપ્લિકેશન સાથે લૉગ્સ ફેરવો વસ્તુપાલ અથવા Elasticsearch API ને કૉલ કરો. સ્થિતિસ્થાપક પોતે, સૈદ્ધાંતિક રીતે, હવે તૃતીય-પક્ષ સાધનોના ઉપયોગ વિના અનુક્રમણિકાઓના જીવનનું સંચાલન કરવા માટે નોંધપાત્ર પગલાં લઈ રહ્યું છે. સામાન્ય રીતે, લાંબા સમય સુધી લોગ રાખવાનો કોઈ અર્થ નથી: તે અસંભવિત છે કે બે અઠવાડિયા પછી કોઈપણ લોગની જરૂર પડશે - જો તે ખરેખર જટિલ છે, તો તે ચોક્કસપણે બે અઠવાડિયામાં કામ કરશે. આત્યંતિક કિસ્સાઓમાં, જૂના લોગને આર્કાઇવ કરી શકાય છે અને લાંબા ગાળાના સ્ટોરેજ માટે ક્યાંક મોકલી શકાય છે. મેં ખાસ લોગ વિશે સાંભળ્યું કે જે કાયદા દ્વારા 5 વર્ષ સુધી રાખવા જરૂરી છે. અંગત રીતે, હું આનો સામનો કરી શક્યો નથી, પરંતુ હું આવી માહિતીને સામાન્ય લોગ સાથે સરખાવીશ નહીં, અને કદાચ તેમને અલગથી સંગ્રહિત પણ કરીશ.

ચાલુ રહી શકાય…

લેખક: માર્સેલ ઇબ્રાએવ, પ્રમાણિત કુબરનેટ્સ એડમિનિસ્ટ્રેટર, કંપનીમાં પ્રેક્ટિસ એન્જિનિયર સાઉથબ્રીજ, સ્પીકર અને કોર્સ ડેવલપર સ્લર્મ.

સોર્સ: www.habr.com