યુરી બુશમેલેવ "લોગ એકત્રિત કરવા અને પહોંચાડવાના ક્ષેત્રમાં રેકનો નકશો" - અહેવાલની ટ્રાન્સક્રિપ્ટ

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

• એપ્લિકેશનમાંથી લોગ કેવી રીતે લખવા;
• લોગ ક્યાં લખવા;
• સંગ્રહ અને પ્રક્રિયા માટે લોગ કેવી રીતે પહોંચાડવા;
• લોગ કેવી રીતે પ્રોસેસ અને સ્ટોર કરવા.

હાલમાં લોકપ્રિય કન્ટેનરાઇઝેશન ટેક્નોલોજીનો ઉપયોગ સમસ્યા હલ કરવાના વિકલ્પોના ક્ષેત્રમાં રેકની ટોચ પર રેતી ઉમેરે છે.

આ વિશે યુરી બુશમેલેવ દ્વારા અહેવાલની ટ્રાન્સક્રિપ્ટ છે "લોગ એકત્રિત કરવા અને પહોંચાડવાના ક્ષેત્રમાં રેકનો નકશો"

કોણ ધ્યાન રાખે છે, કૃપા કરીને બિલાડીની નીચે.

મારું નામ યુરી બુશમેલેવ છે. હું લઝાદા માટે કામ કરું છું. આજે હું વાત કરીશ કે અમે અમારા લોગ કેવી રીતે બનાવ્યા, અમે તેમને કેવી રીતે એકત્રિત કર્યા અને અમે ત્યાં શું લખીએ છીએ.

અમે ક્યાંથી છીએ? આપણે કોણ છીએ? Lazada દક્ષિણપૂર્વ એશિયાના છ દેશોમાં #1 ઓનલાઇન રિટેલર છે. આ તમામ દેશો ડેટા સેન્ટરમાં વહેંચાયેલા છે. હવે કુલ 4 ડેટા સેન્ટર છે. આ શા માટે મહત્વનું છે? કારણ કે કેટલાક નિર્ણયો એ હકીકતને કારણે હતા કે કેન્દ્રો વચ્ચે ખૂબ જ નબળી કડી છે. અમારી પાસે માઇક્રોસર્વિસ આર્કિટેક્ચર છે. મને એ જાણીને આશ્ચર્ય થયું કે અમારી પાસે પહેલેથી જ 80 માઈક્રો સર્વિસ છે. જ્યારે મેં લૉગ્સ સાથે કાર્ય શરૂ કર્યું, ત્યારે તેમાંથી માત્ર 20 જ હતા. ઉપરાંત, PHP વારસાનો એક મોટો ભાગ છે, જેની સાથે મારે જીવવું પડશે અને તેને સહન કરવું પડશે. આ બધું આપણા માટે આ ક્ષણે સમગ્ર સિસ્ટમ માટે પ્રતિ મિનિટ 6 મિલિયનથી વધુ સંદેશાઓ જનરેટ કરે છે. આગળ હું બતાવીશ કે આપણે આ સાથે કેવી રીતે જીવવાનો પ્રયાસ કરી રહ્યા છીએ, અને આ શા માટે છે.

તમારે આ 6 મિલિયન સંદેશાઓ સાથે કોઈક રીતે જીવવું પડશે. આપણે તેમની સાથે શું કરવું જોઈએ? 6 મિલિયન સંદેશાઓની જરૂર છે:

• એપ્લિકેશનમાંથી મોકલો
• ડિલિવરી માટે સ્વીકારો
• વિશ્લેષણ અને સંગ્રહ માટે પહોંચાડો.
• વિશ્લેષણ
• કોઈક રીતે સ્ટોર કરો.

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

તેની સાથે કેવી રીતે જીવવું? હવે હું વિકલ્પોના ક્ષેત્રનું ટૂંકમાં વર્ણન કરીશ - આ સમસ્યા સામાન્ય રીતે કેવી રીતે હલ થાય છે. લોગ એકત્રિત કરવા, સ્થાનાંતરિત કરવા અને સંગ્રહિત કરવાની સમસ્યાને કેવી રીતે હલ કરવી.

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

લોગના સંગ્રહ સાથે, પરિસ્થિતિ લગભગ સમાન છે. આ ચોક્કસ ભાગને ઉકેલવા માટે ઘણા બધા વિકલ્પો નથી. તેમાંના વધુ છે, પરંતુ હજી ઘણા નથી.

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

હું તમને બતાવીશ કે અમે લાઝાડામાં તે કેવી રીતે કર્યું અને તે બધું કેવી રીતે શરૂ થયું.

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

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

અમે તેની સાથે આગળ શું કર્યું? અમે તેને કાફકાને મોકલ્યો. કાફકાથી આગળ, અડધા લોગ લોગસ્ટાશ તરફ ઉડાન ભરી. બાકીના અડધા લોગ શેર કરવામાં આવ્યા હતા. કેટલાક એક ગ્રેલોગ પર ઉડાન ભરી, કેટલાક બીજા ગ્રેલોગ પર. પરિણામે, આ બધું એક Elasticsearch ક્લસ્ટરમાં ઉડી ગયું. એટલે કે આ બધો ગડબડ અંતે ત્યાં જ પડ્યો. તમારે તે કરવાની જરૂર નથી!

જ્યારે ઉપરથી જોવામાં આવે ત્યારે તે આના જેવું જ દેખાય છે. તમારે તે કરવાની જરૂર નથી! અહીં, સમસ્યાવાળા વિસ્તારો તરત જ નંબરો સાથે ચિહ્નિત થયેલ છે. ખરેખર તેમાંના વધુ છે, પરંતુ 6 ખરેખર સમસ્યારૂપ છે, જેની સાથે કંઈક કરવાની જરૂર છે. હું હવે તેમના વિશે અલગથી કહીશ.

અહીં (1,2,3) આપણે ફાઇલો લખીએ છીએ અને તે મુજબ, અહીં એક સાથે ત્રણ રેક છે.

પ્રથમ (1) એ છે કે આપણે તેમને ક્યાંક લખવાની જરૂર છે. API ને ફાઇલ પર સીધું લખવાની ક્ષમતા આપવી હંમેશા ઇચ્છનીય નથી. તે ઇચ્છનીય છે કે API ને કન્ટેનરમાં અલગ કરવામાં આવે, અને વધુ સારું, તે ફક્ત વાંચવા માટેનું હોય. હું એક સિસ્ટમ એડમિનિસ્ટ્રેટર છું, તેથી મારી પાસે આ વસ્તુઓનો થોડો વૈકલ્પિક દૃષ્ટિકોણ છે.

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

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

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

અમે આ પ્રશ્નો પૂછવાનું શરૂ કર્યું. અમે દોષિતોને ન શોધવાનું નક્કી કર્યું.

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

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

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

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

અસ્ખલિત. સૌપ્રથમ, હું તેની સાથે અગાઉની નોકરી પર આવ્યો હતો, અને તે પણ સમયાંતરે ત્યાં પડ્યો હતો. બીજું, આ સમાન છે, ફક્ત પ્રોફાઇલમાં.

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

sysadmin માટે સ્પષ્ટ ઉકેલ આ જથ્થામાં તમામ પ્રકારના syslogs છે (syslog-ng/rsyslog/nxlog).

અથવા તમારું પોતાનું કંઈક લખો, પરંતુ અમે તેને કાઢી નાખ્યું, તેમજ ફાઇલબીટ. જો તમે કંઈક લખો છો, તો વ્યવસાય માટે ઉપયોગી કંઈક લખવું વધુ સારું છે. લોગ્સ પહોંચાડવા માટે, તૈયાર કંઈક લેવાનું વધુ સારું છે.

તેથી, પસંદગી ખરેખર syslog-ng અને rsyslog વચ્ચેની પસંદગી પર આવી. હું rsyslog તરફ ઝુકાવતો હતો કારણ કે અમારી પાસે પપેટમાં rsyslog માટે પહેલાથી જ વર્ગો હતા, અને મને તેમની વચ્ચે સ્પષ્ટ તફાવત મળ્યો નથી. syslog શું છે, syslog શું છે. હા, કેટલાક દસ્તાવેજો ખરાબ છે, કેટલાક વધુ સારા. તે આ રીતે જાણે છે, અને તે અલગ રીતે કરે છે.

અને rsyslog વિશે થોડું. પ્રથમ, તે સરસ છે કારણ કે તેમાં ઘણા બધા મોડ્યુલો છે. તેમાં માનવ વાંચી શકાય તેવી રેનરસ્ક્રીપ્ટ (આધુનિક રૂપરેખાંકન ભાષા) છે. એક અદ્ભુત બોનસ એ છે કે અમે td-એજન્ટની વર્તણૂકને તેના પ્રમાણભૂત સાધનો સાથે અનુકરણ કરી શકીએ છીએ, અને એપ્લિકેશન માટે કંઈ બદલાયું નથી. એટલે કે, અમે td-agent ને rsyslog માં બદલીએ છીએ, અને બાકીની દરેક વસ્તુને હજુ સુધી સ્પર્શતા નથી. અને તરત જ અમને વર્કિંગ ડિલિવરી મળે છે. આગળ, mmnormalize એ rsyslog વિશે સરસ વસ્તુ છે. તે તમને લૉગ્સનું વિશ્લેષણ કરવાની પરવાનગી આપે છે, પરંતુ Grok અને regexp સાથે નહીં. તે અમૂર્ત વાક્યરચના વૃક્ષ બનાવે છે. તે લોગને તે જ રીતે પાર્સ કરે છે જે રીતે કમ્પાઈલર સોર્સ કોડને પાર્સ કરે છે. આ તમને ખૂબ જ ઝડપથી કામ કરવા, થોડું CPU ખાવા અને, સામાન્ય રીતે, તે ખૂબ જ સરસ વસ્તુ છે. અન્ય બોનસનો સમૂહ છે. હું તેમના પર ધ્યાન આપીશ નહીં.

rsyslog માં ઘણા વધુ ગેરફાયદા છે. તેઓ લગભગ બોનસ જેવા જ છે. મુખ્ય સમસ્યાઓ એ છે કે તમારે તેને રાંધવામાં સક્ષમ બનવાની જરૂર છે, અને તમારે સંસ્કરણ પસંદ કરવાની જરૂર છે.

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

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

Rsyslog સ્લાઇડ પર દર્શાવેલ ક્રિયાઓ કરે છે અને ક્યાં તો રિલે અથવા કાફ્કાને લોગ મોકલે છે. કાફકા જૂની રીતને અનુસરે છે. રેલે - મેં લોગ પહોંચાડવા માટે શુદ્ધ rsyslog નો ઉપયોગ કરવાનો પ્રયાસ કર્યો. સંદેશ કતાર વિના, પ્રમાણભૂત rsyslog સાધનોનો ઉપયોગ કરીને. મૂળભૂત રીતે, તે કામ કરે છે.

પરંતુ આ ભાગ (Logstash/Graylog/ES) માં પછીથી તેમને કેવી રીતે ભરવું તેની ઘોંઘાટ છે. આ ભાગ (rsyslog-rsyslog) નો ઉપયોગ ડેટાસેન્ટર્સ વચ્ચે થાય છે. અહીં એક સંકુચિત tcp લિંક છે, જે તમને બેન્ડવિડ્થ બચાવવા માટે પરવાનગી આપે છે અને, તે મુજબ, ચેનલ ભરાઈ જાય ત્યારે અમને બીજા ડેટા સેન્ટરમાંથી કેટલાક લોગ પ્રાપ્ત થવાની સંભાવના વધે છે. કારણ કે આપણી પાસે ઈન્ડોનેશિયા છે, જ્યાં બધું જ ખરાબ છે. ત્યાં જ સતત સમસ્યા રહે છે.

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

શું સમસ્યાઓ છે? સમસ્યા એ હકીકત સાથે ઊભી થઈ કે અમને (અચાનક!) જાણવા મળ્યું કે અમારા લાઈવ API પ્રતિ સેકન્ડ 50k સંદેશા લખે છે. સ્ટેજિંગ વિના આ માત્ર લાઇવ API છે. અને ગ્રેલોગ અમને પ્રતિ સેકન્ડ માત્ર 12 હજાર સંદેશા બતાવે છે. અને વાજબી પ્રશ્ન ઊભો થયો, અવશેષો ક્યાં છે? જેમાંથી અમે તારણ કાઢ્યું કે ગ્રેલોગ ફક્ત સામનો કરી શકતો નથી. અમે જોયું, અને, ખરેખર, Elasticsearch સાથેનો ગ્રેલોગ આ પ્રવાહમાં માસ્ટર ન હતો.

આગળ, અમે રસ્તામાં કરેલી અન્ય શોધો.

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

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

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

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

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

Logstash અને Graylog સાથેનો આ ભાગ, તે ખરેખર ઉગે છે. તેથી, તમારે તેનાથી છુટકારો મેળવવાની જરૂર છે. તમારે એક પસંદ કરવાનું રહેશે.

અમે Logstash અને Kibana છોડવાનું નક્કી કર્યું. કારણ કે અમારી પાસે સુરક્ષા વિભાગ છે. કનેક્શન શું છે? કનેક્શન એ છે કે X-Pack વિના અને Shield વિના કિબાના તમને લોગના ઍક્સેસ અધિકારોને અલગ પાડવાની મંજૂરી આપતું નથી. તેથી, તેઓએ ગ્રેલોગ લીધો. તેની પાસે તે બધું છે. મને તે ગમતું નથી, પણ તે કામ કરે છે. અમે નવું હાર્ડવેર ખરીદ્યું, ત્યાં એક નવો ગ્રેલોગ ઇન્સ્ટોલ કર્યો અને કડક ફોર્મેટ સાથેના તમામ લોગને અલગ ગ્રેલોગમાં ખસેડ્યા. અમે સંગઠનાત્મક રીતે સમાન ક્ષેત્રોના વિવિધ પ્રકારો સાથે સમસ્યા હલ કરી છે.

નવા ગ્રેલોગમાં બરાબર શું સમાવવામાં આવ્યું છે. અમે ફક્ત ડોકરમાં બધું જ લખ્યું છે. અમે સર્વરોનો સમૂહ લીધો, ત્રણ કાફકા દાખલાઓ, 7 ગ્રેલોગ સર્વર્સ સંસ્કરણ 2.3 (કારણ કે હું ઇલાસ્ટિકસર્ચ સંસ્કરણ 5 ઇચ્છતો હતો). આ બધું એચડીડીના દરોડા પર ઉઠાવવામાં આવ્યું હતું. અમે પ્રતિ સેકન્ડ 100 હજાર સંદેશાઓનો ઇન્ડેક્સીંગ દર જોયો. અમે આંકડો જોયો કે દર અઠવાડિયે 140 ટેરાબાઇટ ડેટા.

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

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

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

ગ્રેલોગમાંથી મેટ્રિક્સ એકત્રિત કરો.

દર મર્યાદા બનાવો જેથી અમારી પાસે એક ઉન્મત્ત API હોય જે અમને બેન્ડવિડ્થ અને બાકીનું બધું ન મારે.

અને અંતે, વિકાસકર્તાઓ સાથે અમુક પ્રકારના SLA પર સહી કરો જેથી અમે તેટલી સેવા આપી શકીએ. વધુ લખો તો માફ કરશો.

અને દસ્તાવેજો લખો.

સંક્ષિપ્તમાં, આપણે જે અનુભવ્યું છે તેના પરિણામો. પ્રથમ, ધોરણો. બીજું, syslog એ કેક છે. ત્રીજું, rsyslog એ સ્લાઇડ પર લખેલું છે તે રીતે બરાબર કામ કરે છે. અને ચાલો પ્રશ્નો પર જઈએ.

પ્રશ્નો.

તમારો પ્રશ્ન: તેઓએ કેમ ન લેવાનું નક્કી કર્યું ... (ફાઇલબીટ?)

જવાબ આપો: ફાઇલમાં લખવાની જરૂર છે. હું ખરેખર ઇચ્છતો ન હતો. જ્યારે તમારું API સેકન્ડ દીઠ હજારો સંદેશા લખે છે, ભલે તમે કલાકમાં એક વાર ફેરવો તો પણ આ વિકલ્પ નથી. તમે પાઇપ પર લખી શકો છો. જેના માટે વિકાસકર્તાઓએ મને પૂછ્યું: "જે પ્રક્રિયામાં આપણે લખીએ છીએ તે નીચે આવે તો શું થશે"? તેમને શું જવાબ આપવો તે મને સમજાયું નહીં, અને કહ્યું: "સારું, ઠીક છે, ચાલો તે ન કરીએ."

તમારો પ્રશ્ન: તમે HDFS પર લોગ કેમ લખતા નથી?

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

તમારો પ્રશ્ન: કૉલમ ફોર્મેટ વધુ યોગ્ય રહેશે.

જવાબ આપો: હુ સમજયો. અમે બંને હાથ વડે "માટે" છીએ.

તમારો પ્રશ્ન: તમે rsyslog પર લખો. TCP અને UDP બંને ત્યાં ઉપલબ્ધ છે. પરંતુ જો UDP, તો પછી તમે ડિલિવરીની ખાતરી કેવી રીતે આપશો?

જવાબ આપોA: ત્યાં બે મુદ્દા છે. પ્રથમ, હું તરત જ દરેકને કહું છું કે અમે લોગની ડિલિવરીની ખાતરી આપતા નથી. કારણ કે જ્યારે વિકાસકર્તાઓ આવે છે અને કહે છે: "ચાલો ત્યાં નાણાકીય ડેટા લખવાનું શરૂ કરીએ, અને જો કંઈક થાય તો તમે તેને અમારા માટે ક્યાંક મૂકશો," અમે તેમને જવાબ આપીએ છીએ, "સરસ! ચાલો સોકેટ પર લખવા પર બ્લોક કરવાનું શરૂ કરીએ, અને તે વ્યવહારોમાં કરીએ, જેથી તમે તેને અમારા માટે સોકેટમાં મૂકવાની ખાતરી આપીએ અને ખાતરી કરો કે અમને તે બીજી બાજુથી પ્રાપ્ત થયું છે. અને આ ક્ષણે, દરેક તરત જ બિનજરૂરી બની જાય છે. અને જો નહીં, તો પછી આપણી પાસે કયા પ્રશ્નો છે? જો તમે સોકેટ પર લખવાની બાંયધરી આપવા માંગતા નથી, તો અમે ડિલિવરીની ખાતરી શા માટે આપીશું? અમે શ્રેષ્ઠ પ્રયાસો કરી રહ્યા છીએ. અમે ખરેખર શક્ય તેટલું અને શક્ય તેટલું શ્રેષ્ઠ પહોંચાડવાનો પ્રયાસ કરીએ છીએ, પરંતુ અમે 100% ગેરેંટી આપતા નથી. તેથી, તમારે ત્યાં નાણાકીય ડેટા લખવાની જરૂર નથી. આ માટે વ્યવહારિક ડેટાબેઝ છે.

તમારો પ્રશ્ન: જ્યારે API લોગમાં અમુક સંદેશો જનરેટ કરે છે અને નિયંત્રણને માઇક્રોસર્વિસિસમાં સ્થાનાંતરિત કરે છે, ત્યારે શું તમને સમસ્યા આવી છે કે વિવિધ માઇક્રોસર્વિસીસના સંદેશાઓ ખોટા ક્રમમાં આવે છે? જેના કારણે મૂંઝવણ ઉભી થાય છે.

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

તમારો પ્રશ્ન: ટાઈમસ્ટેમ્પ મિલિસેકન્ડ્સ દ્વારા બદલાઈ શકે છે.

જવાબ આપો: ટાઇમસ્ટેમ્પ API દ્વારા જ જનરેટ થાય છે. આ, હકીકતમાં, સમગ્ર મુદ્દો છે. અમારી પાસે NTP છે. API એ સંદેશમાં પહેલેથી જ ટાઇમસ્ટેમ્પ જનરેટ કરે છે. તે rsyslog દ્વારા ઉમેરવામાં આવતું નથી.

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

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

તમારો પ્રશ્ન: શું તમને અસામાન્ય પરિસ્થિતિઓ દરમિયાન ત્યાંથી લોગ મળે છે?

જવાબ આપો: તમે ત્યાં જઈ શકો છો (ફાઈલ સ્ટોરેજ પર) અને જોઈ શકો છો.

તમારો પ્રશ્ન: તમે કેવી રીતે મોનિટર કરશો કે તમે લોગ ગુમાવશો નહીં?

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

તમારો પ્રશ્ન: ઇલાસ્ટીક સર્ચમાં, તમે લોગને રીડન્ડન્સી સાથે સ્ટોર કરો છો. તમારી પાસે કેટલી પ્રતિકૃતિઓ છે?

જવાબ આપો: એક પ્રતિકૃતિ.

તમારો પ્રશ્ન: શું તે માત્ર એક લીટી છે?

જવાબ આપો: આ માસ્ટર અને પ્રતિકૃતિ છે. ડેટા ડુપ્લિકેટમાં સંગ્રહિત છે.

તમારો પ્રશ્ન: શું તમે કોઈક રીતે rsyslog બફરના કદમાં ફેરફાર કર્યો છે?

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

પ્રશ્ન: શું તમે તૂટેલા JSON લખો છો?

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

પ્રશ્ન: શા માટે કાફકા? શું તમે RabbitMQ નો પ્રયાસ કર્યો છે? ગ્રેલોગ આવા ભાર હેઠળ ઉમેરાતું નથી?

જવાબ આપો: તે ગ્રેલોગ સાથે કામ કરતું નથી. અને ગ્રેલોગ આકાર લઈ રહ્યો છે. તે તેના માટે ખરેખર સમસ્યારૂપ છે. તે એક પ્રકારની વસ્તુ છે. અને, હકીકતમાં, તેની જરૂર નથી. હું તેના બદલે rsyslog થી સીધા elasticsearch પર લખીશ અને પછી Kibana જોઉં. પરંતુ અમારે સિક્યોરિટી ગાર્ડ્સ સાથે આ મુદ્દાનું સમાધાન કરવાની જરૂર છે. જ્યારે આપણે ગ્રેલોગને બહાર કાઢીએ છીએ અને કિબાનાનો ઉપયોગ કરીએ છીએ ત્યારે આ આપણા વિકાસનો સંભવિત પ્રકાર છે. Logstash અર્થમાં રહેશે નહીં. કારણ કે હું rsyslog સાથે તે જ કરી શકું છું. અને તેમાં ઇલાસ્ટીક સર્ચ પર લખવા માટે એક મોડ્યુલ છે. ગ્રેલોગ સાથે અમે કોઈક રીતે જીવવાનો પ્રયાસ કરી રહ્યા છીએ. અમે પણ તેને થોડી tweaked. પરંતુ હજુ પણ સુધારા માટે અવકાશ છે.

કાફકા વિશે. આ રીતે તે ઐતિહાસિક રીતે થયું. જ્યારે હું પહોંચ્યો, તે પહેલેથી જ ત્યાં હતો, અને તેના પર લૉગ્સ પહેલેથી જ લખવામાં આવી રહ્યા હતા. અમે હમણાં જ અમારું ક્લસ્ટર ઊભું કર્યું છે અને તેમાં લૉગ્સ ખસેડ્યા છે. અમે તેને મેનેજ કરીએ છીએ, અમે જાણીએ છીએ કે તે કેવું અનુભવે છે. RabbitMQ માટે... અમને RabbitMQ સાથે મુશ્કેલી આવી રહી છે. અને RabbitMQ અમારા માટે વિકાસ કરી રહ્યું છે. અમારી પાસે તે ઉત્પાદનમાં છે, અને તેની સાથે સમસ્યાઓ હતી. હવે, વેચાણ પહેલાં, તેને શમનાઇઝ કરવામાં આવશે, અને તે સામાન્ય રીતે કામ કરવાનું શરૂ કરશે. પરંતુ તે પહેલા હું તેને પ્રોડક્શનમાં રજૂ કરવા તૈયાર નહોતો. ત્યાં એક વધુ મુદ્દો છે. ગ્રેલોગ AMQP 0.9 સંસ્કરણ વાંચી શકે છે અને rsyslog એ AMQP 1.0 સંસ્કરણ લખી શકે છે. અને ત્યાં એક પણ ઉકેલ નથી જે મધ્યમાં બંને કરી શકે. ત્યાં એક અથવા અન્ય છે. તેથી હમણાં માટે માત્ર કાફકા. પરંતુ ઘોંઘાટ પણ છે. કારણ કે rsyslog ના વર્ઝનનો omkafka કે જેનો અમે ઉપયોગ કરીએ છીએ તે સમગ્ર મેસેજ બફરને ગુમાવી શકે છે જે તે rsyslog માંથી સ્કૂપ કરે છે. જ્યાં સુધી અમે તેની સાથે મૂકીએ છીએ.

પ્રશ્ન: શું તમે કાફકાનો ઉપયોગ કરો છો કારણ કે તમારી પાસે તે હતું? અન્ય કોઈ હેતુ માટે ઉપયોગ થતો નથી?

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

પ્રશ્ન: શા માટે આપણને સોકેટ્સ સાથે આ શામનવાદની જરૂર છે? શું તમે કન્ટેનર માટે syslog લોગ ડ્રાઈવરનો ઉપયોગ કરવાનો પ્રયાસ કર્યો છે.

જવાબ આપો: તે સમયે જ્યારે અમે આ પ્રશ્ન પૂછ્યો, ત્યારે અમારા ડોકર સાથે તણાવપૂર્ણ સંબંધો હતા. તે ડોકર 1.0 અથવા 0.9 હતું. ડોકર પોતે વિચિત્ર હતો. બીજું, જો તમે તેમાં લોગને પણ ધક્કો મારશો તો... મને એક વણચકાસાયેલ શંકા છે કે તે બધા લોગ્સ જાતે જ, ડોકર ડિમન દ્વારા પસાર કરે છે. જો આપણી પાસે એક API ઉન્મત્ત થઈ રહ્યું છે, તો બાકીના API એ હકીકતમાં ચાલશે કે તેઓ stdout અને stderr મોકલી શકતા નથી. મને ખબર નથી કે આ ક્યાં લઈ જશે. મને લાગણીના સ્તરે શંકા છે કે આ જગ્યાએ ડોકર સિસ્લોગ ડ્રાઇવરનો ઉપયોગ કરવો જરૂરી નથી. અમારા કાર્યાત્મક પરીક્ષણ વિભાગ પાસે લોગ સાથેનું પોતાનું ગ્રેલોગ ક્લસ્ટર છે. તેઓ ડોકર લોગ ડ્રાઇવરોનો ઉપયોગ કરે છે અને ત્યાં બધું સારું લાગે છે. પરંતુ તેઓ તરત જ ગ્રેલોગ પર GELF લખે છે. આ ક્ષણે જ્યારે અમે આ બધું શરૂ કર્યું, અમને ફક્ત કામ કરવા માટે તેની જરૂર હતી. કદાચ પછીથી, જ્યારે કોઈ આવે અને કહે કે તે સો વર્ષથી સામાન્ય રીતે કામ કરે છે, ત્યારે અમે પ્રયત્ન કરીશું.

પ્રશ્ન: તમે rsyslog નો ઉપયોગ કરીને ડેટા સેન્ટરો વચ્ચે વિતરિત કરો છો. કાફકા પર કેમ નહીં?

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

સોર્સ: www.habr.com