𝗖𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲𝗱 𝗟𝗼𝗴𝗴𝗶𝗻𝗴 𝗪𝗶𝘁𝗵 𝗚𝗿𝗮𝗳𝗮𝗻𝗮 𝗔𝗹𝗹𝗼𝘆 𝗮𝗻𝗱 𝗟𝗼𝗸𝗶

லாகுகளைக் (logs) கண்டறிவது என்பது குறிப்பிட்ட சர்வர்களில் SSH செய்து grep கட்டளையை இயக்குவதாகும்.

ஒரு தொழில்நுட்பச் சிக்கல் (incident) ஏற்படும் போது, எந்த சர்வரில் பிழை உள்ளது என்பது பெரும்பாலும் தெரியாது. இதனால் நீங்கள் பல ஹோஸ்ட்களுக்கு (hosts) இடையே மாறி மாறிச் சென்று, நேர முத்திரைகளை (timestamps) கண்களால் பார்த்துப் பொருத்த முயல வேண்டியிருக்கும். வேகம் தேவைப்படும் போது இந்த முறை தோல்வியடையும்.

நான் மையப்படுத்தப்பட்ட லாகிங்கிற்கு (centralized logging) மாறினேன். இப்போது, ஒவ்வொரு சர்வரிலிருந்தும் வரும் ஒவ்வொரு லாக் வரியும் ஒரே இடத்தில் சேமிக்கப்படுகிறது. லாகுகளை Loki-க்கு அனுப்ப ஒவ்வொரு ஹோஸ்டிலும் நான் Grafana Alloy-வைப் பயன்படுத்துகிறேன்.

ஏன் இந்தத் தொழில்நுட்பத் தொகுப்பு (stack)?

  • ELK மிகவும் கனமானது. Elasticsearch-க்கு அதிக பராமரிப்பும் வன்பொருளும் (hardware) தேவைப்படுகிறது.
  • Loki முழு உரையைத் (full text) தேடுவதற்குப் பதிலாக லேபிள்களை (labels) மட்டும் குறியீடாக்குகிறது (indexes). இது இதை இயக்குவதற்கு எளிமையாகவும் செலவு குறைந்ததாகவும் மாற்றுகிறது.
  • உங்கள் சர்வர் எண்ணிக்கை (fleet) அதிகரிக்கும் போது, SaaS கருவிகளின் செலவு விரைவாக உயரும்.
  • Alloy என்பது Grafana-வின் புதிய தரநிலை ஏஜென்ட் (standard agent) ஆகும். இது திறமையானது மற்றும் நம்பகமானது.

அமைப்பமைப்பு (The Setup)

Alloy ஒவ்வொரு ஹோஸ்டிலும் உள்ள கோப்புகளைப் படிக்கிறது. இது host, environment மற்றும் service போன்ற லேபிள்களைச் சேர்க்கிறது. பின்னர் அவற்றை Loki-க்கு அனுப்புகிறது. நான் ஒரு Slack பாட் (bot)-ஐயும் உருவாக்கினேன். இது Loki API-ஐப் பயன்படுத்துவதால், குழுவினர் தங்கள் சாட் சேனலை விட்டு வெளியேறாமலேயே லாகுகளைப் பெற முடியும்.

நான் எதிர்கொண்ட நிஜ உலக சவால்கள்:

  • அனுமதிகள் (Permissions): Alloy ஒரு தனி பயனராக (user) இயங்குகிறது. உங்கள் ஆப் லாகுகள் (app logs) கட்டுப்படுத்தப்பட்டிருந்தால், Alloy எந்தத் தகவலும் தெரிவிக்காமல் தோல்வியடையும். நீங்கள் alloy பயனரை உங்கள் ஆப் குழுக்களில் (app groups) சேர்க்க வேண்டும்.
  • கலப்பு OS தொகுப்புகள் (Mixed OS fleets): உங்களிடம் Debian, Ubuntu மற்றும் RHEL சர்வர்கள் இருக்கலாம். ஒவ்வொன்றிற்கும் சரியான பேக்கேஜ் மேனேஜர்களைப் (package managers) பயன்படுத்த வேண்டும்.
  • பழைய ஏஜென்ட்கள் (Legacy agents): பழைய லாக் ஷிப்பர்கள் (log shippers) லாகுகளை இருமுறை அனுப்பக்கூடும். புதிய அமைப்பைச் செயல்படுத்தும் போது (rollout), அவற்றை நீங்கள் கண்டறிந்து நீக்க வேண்டும்.
  • மல்டிலைன் லாகுகள் (Multiline logs): Java stack traces பல வரிகளில் இருக்கும். ஒரு multiline regex இல்லையென்றால், ஒரு பிழை நாற்பது தனித்தனி, பயனற்ற பதிவுகளாக மாறிவிடும்.

லேபிள்களுக்கான பொன்விதி (The Golden Rule of Labels)

லேபிள்களில் அதிக கார்டினாலிட்டி (high-cardinality) தரவுகளைப் பயன்படுத்த வேண்டாம். Request IDs அல்லது User IDs-களை லேபிள்களாக ஒருபோதும் பயன்படுத்தாதீர்கள். இது உங்கள் குறியீட்டை (index) பாதிக்கும். Service name அல்லது environment போன்றவற்றுக்கு லேபிள்களைப் பயன்படுத்துங்கள். மற்ற அனைத்திற்கும் ஃபில்டர்களைப் (filters) பயன்படுத்துங்கள்.

முடிவு (The Result)

மையப்படுத்தப்பட்ட லாகிங், லாகுகளை மெட்ரிகளாக (metrics) மாற்றுகிறது. ஒரு மனிதர் பிரச்சனையைத் தெரிந்துகொள்ளக் காத்திருப்பதற்குப் பதிலாக, பிழை விகிதங்களைக் (error rates) கொண்டு நீங்கள் எச்சரிக்கைகளை (alerts) அமைக்கலாம். ஒரு தொழில்நுட்பச் சிக்கல் ஏற்படும் போது, ஒரு Slack கட்டளை மூலம் விடையைப் பெற்றுவிடலாம்.

ஆதாரம்: https://dev.to/azeemsidd3/centralized-logging-across-a-mixed-os-server-fleet-with-grafana-alloy-and-loki-51c6

விருப்பமான கற்றல் சமூகம்: https://t.me/GyaanSetuAi