ஒரே VPS-ல் log management அமைப்பது எப்படி?

ஒரே VPS-ல் self-hosted log management-ன் உண்மையான செலவு

ஒரே VPS-ல் (virtual private server) log management-ஐ நீங்களே நிர்வகிப்பது ஒரு முக்கியமான கேள்வியைச் சார்ந்தது: உங்களுக்கு ஒரு search cluster தேவையா, அல்லது log rotation மற்றும் grep போதுமா? பெரும்பாலான விற்பனையாளர்களின் வழிகாட்டிகள், ஒரு log line-ஐக் கூட அனுப்பும் முன்பே மூன்று nodes மற்றும் 12 GB RAM தேவை என்று பரிந்துரைக்கின்றன. ஒரே ஒரு server-க்கு இந்த பதில் பயனற்றது. எனவே, கீழே உள்ள ஒப்பீடு, ஒரு சிறிய server-ல் எந்தவொரு தரவையும் சேமிக்கும் முன்பே ஒவ்வொரு தீர்வும் எவ்வளவு வளங்களை (resources) கோருகிறது என்பதை அடிப்படையாகக் கொண்டது.

நீங்கள் ஒன்று அல்லது இரண்டு server-களை மட்டும் இயக்குகிறீர்கள் என்றால், கடந்த செவ்வாய்க்கிழமை என்ன நடந்தது என்பதை அறிய systemd-journald மற்றும் logrotate ஆகியவையே போதுமானவை; அடுத்த பகுதியை நீங்கள் படிக்க வேண்டிய அவசியமில்லை. பல இயந்திரங்களின் logs-ஐ ஓரிடத்தில் சேமித்து, வாரக்கணக்கில் தேட வேண்டிய தேவை இருந்தால், Grafana Loki ஒரு சிறிய server-க்கு ஏற்றது; ஏனெனில் இது வரிகளின் உரையை (text) குறியீடாக்காமல், labels-ஐ மட்டுமே குறியீடாக்குகிறது. Elasticsearch மற்றும் OpenSearch ஆகியவை முழுமையான full text search வசதியை வழங்குகின்றன, ஆனால் இதற்கு அதிக நினைவகம் (memory) தேவைப்படுகிறது; ஏனெனில் JVM (Java virtual machine) heap-க்கு ஒரு குறைந்தபட்ச அளவு உள்ளது, அதற்கு கீழே உங்களால் செல்ல முடியாது.

journald-ல் தொடங்குங்கள், ஏனெனில் பெரும்பாலானோர் இதிலேயே நிறுத்திவிடுகிறார்கள்

தற்போதைய எந்தவொரு Ubuntu அல்லது Debian server-லும் systemd-journald ஏற்கனவே இயங்கிக்கொண்டிருக்கும். இது ஒவ்வொரு service unit-ன் standard output, kernel செய்திகள் மற்றும் syslog-க்கு அனுப்பப்படும் அனைத்தையும் சேகரிக்கிறது. நான்கு கட்டளைகள் பெரும்பாலான சிக்கல்களைத் தீர்க்கப் போதுமானவை.

journalctl -u nginx.service --since "2026-08-14 09:00" --until "2026-08-14 10:00"
journalctl -p err -b
journalctl -f -u ssh.service
journalctl --disk-usage

கடைசி கட்டளை Archived and active journals take up 1.1G in the file system. போன்ற ஒரு வரியை வெளியிடும். உங்களுக்கு வேறு ஏதேனும் தேவைப்படுகிறதா என்பதைத் தீர்மானிக்கும் எண் இதுதான். இது சில நூறு மெகாபைட்டுகளைக் காட்டினால், -u மற்றும் --since மூலம் உங்களுக்குத் தேவையானதைக் கண்டறிய முடிந்தால், உங்கள் பணி முடிந்தது.

Reboot-க்கு பிறகும் journal நீடிக்க வேண்டுமா என்பது Storage= மற்றும் /var/log/journal உள்ளதா என்பதைப் பொறுத்தது. பொதுவான Storage=auto அமைப்பில், அந்த directory இருக்கும்போது journald /var/log/journal-ல் எழுதுகிறது, அது இல்லாதபோது /run/log/journal-ல் எழுதுகிறது. /run என்பது memory-ஐ அடிப்படையாகக் கொண்டது, எனவே அந்த directory இல்லாத server-களில் ஒவ்வொரு reboot-ன் போதும் அனைத்து log-களும் அழிக்கப்படும்; ஆனால் அந்த log-களை நீங்கள் படிக்க வேண்டிய தருணமே அதுதான். Ubuntu images-ல் அந்த directory இருக்கும். Minimal மற்றும் container அடிப்படையிலான images-ல் பெரும்பாலும் அது இருக்காது.

ls -d /var/log/journal
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Restart செய்த பிறகு, journalctl --disk-usage-ன் அளவு /run-ஐ விட /var/log/journal-க்கு குறைவாக இருக்க வேண்டும். இயல்புநிலை அமைப்புகளே போதுமான வரம்புகளைக் கொண்டுள்ளன, இதனால்தான் journald ஒரு தற்காலிகத் தீர்வு அல்ல, ஒரு முழுமையான தீர்வாகும். journald.conf man page-ல் SystemMaxUse= என்பது file system அளவில் 10% ஆகவும், SystemKeepFree= என்பது 15% ஆகவும் அமைக்கப்பட்டுள்ளது, மேலும் கணக்கிடப்பட்ட இயல்புநிலை அதிகபட்சம் 4G ஆக இருக்கும். SystemMaxFileSize= இயல்பாக SystemMaxUse=-ல் எட்டில் ஒரு பங்காக இருக்கும், இது அதிகபட்சம் 128M ஆகக் கட்டுப்படுத்தப்படும், எனவே பொதுவாக நீங்கள் ஏழு rotated files-களை வைத்திருப்பீர்கள். MaxRetentionSec= இயல்பாக 0 என இருக்கும், இது age அடிப்படையிலான நீக்கலை முடக்குகிறது. அந்த கடைசி இயல்புநிலையை மீண்டும் கவனியுங்கள்: இயல்பாகவே journal அளவு அடிப்படையில் மட்டுமே கட்டுப்படுத்தப்படுகிறது, வயது அடிப்படையில் அல்ல.

[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=30day

இதை /etc/systemd/journald.conf.d/99-size.conf-ல் எழுதி, journald-ஐ restart செய்து, பின் journalctl --disk-usage உங்கள் புதிய வரம்பை நோக்கி நகர்ந்துள்ளதா எனச் சரிபார்க்கவும். அடுத்த rotation வரை காத்திருக்காமல் இப்போதே இடத்தை மீட்க, sudo journalctl --vacuum-size=500M அல்லது sudo journalctl --vacuum-time=14d-ஐ இயக்கவும். இவை இரண்டும் தாங்கள் நீக்கும் ஒவ்வொரு கோப்பையும் அச்சிடும், எனவே எந்த வெளியீடும் இல்லை என்றால் நீக்க எதுவும் இல்லை என்று பொருள்.

Journal-க்கு வெளியே உள்ள அனைத்தும், உதாரணமாக /var/log/nginx/access.log, logrotate-ன் வேலை, இது systemd timer மூலம் தினமும் இயங்குகிறது. ஒரு தோல்வியைப் பற்றித் தெரிந்துகொள்வது அவசியம், ஏனெனில் அது df-ல் உள்ள பிழை போலத் தோன்றும். Rotation-க்கு பிறகு, பழைய கோப்பு directory பட்டியலிலிருந்து மறைந்துவிடும், ஆனால் daemon அதைத் தொடர்ந்து திறந்து வைத்திருக்கும். எனவே, df -h வட்டு முழுமையாக இருப்பதாகக் காட்டும், அதேசமயம் du -sh /var/log மிகக் குறைந்த அளவே காட்டும். அந்த process தனது log-ஐ மீண்டும் திறக்கும்போது மட்டுமே இடம் திரும்பக் கிடைக்கும், இதற்காகவே config-ல் postrotate reload வரி உள்ளது. sudo lsof -nP +L1 நீக்கப்பட்ட கோப்புகளைத் தொடர்ந்து திறந்து வைத்திருக்கும் process-களைப் பட்டியலிடும். எதையும் மாற்றாமல் ஒரு விதியைச் சோதிக்க sudo logrotate -d /etc/logrotate.d/nginx-ஐப் பயன்படுத்தவும்.

பல server-களிலிருந்து ஒரு collector-க்கு logs அனுப்புதல்

ஒன்றுக்கும் மேற்பட்ட server-கள் இருக்கும்போது, பல Linux server-களை ஒரே நேரத்தில் நிர்வகிப்பது அவற்றின் logs-களை ஓரிடத்தில் சேமிக்கும்போது எளிதாகிறது. பெரும்பாலான Linux விநியோகங்களில் rsyslog ஏற்கனவே நிறுவப்பட்டிருக்கும், எனவே ஒவ்வொரு sender-லும் ஒரு கோப்பை உருவாக்குவதே மிக எளிமையான மையப்படுத்தப்பட்ட சேகரிப்பு முறையாகும்.

*.* action(type="omfwd" target="logs.example.com" port="514" protocol="tcp")

இதை /etc/rsyslog.d/50-forward.conf எனச் சேமிக்கவும், பின் sudo rsyslogd -N1 மூலம் சரிபார்க்கவும். இது configuration-ஐ சரிபார்த்து, எதையும் தொடங்காமல் வெளியேறும். அதன் பிறகு rsyslog-ஐ restart செய்யவும். Collector-ல், TCP input-ஐ enable செய்யவும்.

module(load="imtcp")
input(type="imtcp" port="514")

இரண்டு எச்சரிக்கைகள், இவை தொழில்நுட்ப ரீதியானவை. Plain syslog-ல் encryption மற்றும் authentication கிடையாது. எனவே, port 514-ஐ அணுகக்கூடிய எவரும் உங்கள் log-களைப் போலவே போலியான வரிகளை உள்ளிட முடியும். இதை ஒரு private network அல்லது VPN-ல் மட்டும் பிணைக்கவும் (bind) மற்றும் firewall மூலம் port-ஐப் பாதுகாக்கவும். இரண்டாவதாக, இயல்பான action queue நினைவகத்தில் (memory) இயங்குகிறது. எனவே, collector-ஐ அணுக முடியாதபோது queue நிரம்பிவிடும், மேலும் செய்திகள் இழக்கப்படும்; அவற்றின் நகல் எங்கும் சேமிக்கப்படாது. இதற்கான தீர்வாக, rsyslog-ன் reliable forwarding tutorial-ல் disk assisted queue பற்றி விளக்கப்பட்டுள்ளது.

சிறிய VPS-ல் ஏன் ELK stack பொருந்தாது

ELK என்பது தரவுகளைச் சேமித்துத் தேட Elasticsearch, தரவுகளை உள்ளீடு செய்ய Logstash, மற்றும் இடைமுகத்திற்கு Kibana ஆகியவற்றைக் குறிக்கிறது. இதன் அடிப்படைத் தேவை JVM heap ஆகும்; எந்தவொரு log-ம் வருவதற்கு முன்பே இது ஒதுக்கப்பட்டுவிடும்.

ஒவ்வொரு Elasticsearch node-க்கும் கிடைக்கும் மொத்த நினைவகத்தில் 50%-க்கு மேல் heap-ஐ ஒதுக்கக்கூடாது என்று Elastic-ன் ஆவணங்கள் கூறுகின்றன. ஏனெனில், இந்தச் செயல்முறை off-heap buffers-ஐயும் பயன்படுத்துகிறது, மேலும் index கோப்புகளை விரைவாகப் படிக்க operating system file cache-ஐயும் சார்ந்துள்ளது. எனவே, 2 GB heap தேவை என்றால், Kibana மற்றும் அந்த server-ன் முதன்மைப் பணிகளுக்குத் தேவையான நினைவகம் போக, குறைந்தது 4 GB நினைவகம் கொண்ட machine தேவைப்படும். node-ன் பணிகள் மற்றும் மொத்த நினைவகத்தைப் பொறுத்து Elasticsearch தானாகவே heap-ஐ அளவிடுகிறது என்றும் Elastic கூறுகிறது. இதனால், சிறிய server-ல் heap அளவு குறைவாக இருப்பதால், அது எப்போதும் garbage collection செய்வதிலேயே நேரத்தைச் செலவிடும்.

Logstash என்பது சிறிய பட்ஜெட் கொண்ட server-களில் நேரடியாகப் பாதிப்பை ஏற்படுத்தும் பகுதியாகும். பொதுவான ingestion பணிகளுக்குக் குறைந்தது 4 GB முதல் 8 GB வரை heap தேவை என்று Elastic-ன் JVM அமைப்புகள் பக்கம் பரிந்துரைக்கிறது. ஒரு pipeline-ன் இடைப்பட்ட செயல்முறைக்கு மட்டும் 4 GB VPS-ன் முழு நினைவகமும் தேவைப்படும்.

[
  {
    "label": "Loki plus Alloy (no JVM)",
    "documented_heap_mb": 0
  },
  {
    "label": "OpenSearch demo compose",
    "documented_heap_mb": 512
  },
  {
    "label": "OpenSearch production example",
    "documented_heap_mb": 2048
  },
  {
    "label": "Logstash recommended minimum",
    "documented_heap_mb": 4096
  }
]

இவை அந்தந்தத் திட்டங்களின் ஆவணங்களில் வெளியிடப்பட்ட மதிப்புகள். இவை சோதனைச் சாவடிகளில் எடுக்கப்பட்ட அளவீடுகள் அல்ல; உங்கள் பணிச்சுமையைப் பொறுத்து இவை மாறுபடும். OpenSearch-ன் மாதிரி compose கோப்பு, ஒரு demo-விற்கு 512 MB-யையும், production உதாரணத்திற்கு 2048 MB-யையும் ஒரு node-க்கு ஒதுக்குகிறது. அதேசமயம் Logstash-ன் பரிந்துரைக்கப்பட்ட குறைந்தபட்ச அளவு 4096 MB ஆகும். Loki மற்றும் Alloy ஆகியவற்றுக்கான heap நெடுவரிசையில் 0 என்று உள்ளது, ஏனெனில் அவை Go மொழியில் உருவாக்கப்பட்டவை, அவற்றுக்கு JVM heap ஒதுக்கீடு தேவையில்லை. இதுவே ஒரு எண்ணில் உள்ள மிகப்பெரிய வித்தியாசம்: logs வந்தாலும் வராவிட்டாலும், JVM சார்ந்த ஒரு கூறு தனக்கான நினைவகத்தை முன்பதிவு செய்துவிடும்.

இருப்பினும் நீங்கள் ஒரு சிறிய server-ல் Elastic stack-ஐப் பயன்படுத்த விரும்பினால், Logstash-ஐ நீக்கிவிட்டு, ஒரு சிறிய collector மூலம் நேரடியாக Elasticsearch-க்கு தரவுகளை அனுப்பவும். அதிக அளவிலான தரவுகளைப் பகுப்பாய்வு செய்து மாற்றியமைக்கவே Logstash தேவைப்படுகிறது; ஒரு server-ல் அந்த வேலையை edge-லேயே செய்துவிடலாம் அல்லது அதைத் தவிர்த்துவிடலாம்.

Elasticsearch மற்றும் OpenSearch ஆகிய இரண்டிற்கும் vm.max_map_count மதிப்பை 262144 ஆக உயர்த்த வேண்டும். ஏனெனில், அவை index கோப்புகளை memory map செய்கின்றன, ஆனால் Linux-ன் இயல்புநிலை வரம்பு அவற்றுக்குப் போதுமானதாக இல்லை. ஒரு புதிய server-ல் container தொடங்கிய சில நொடிகளிலேயே நின்றுவிடுகிறது என்றால், அதற்கு இதுவே பெரும்பாலும் காரணமாக இருக்கும்.

OpenSearch அல்லது Elasticsearch: எதை நீங்கள் deploy செய்யலாம்?

இதன் உரிம வரலாறு சுருக்கமானது, ஏனெனில் நீங்கள் எதை இயக்கலாம் என்பதை இதுவே தீர்மானிக்கிறது. ஜனவரி 2021-ல், Elastic நிறுவனம் Elasticsearch மற்றும் Kibana ஆகியவற்றை Apache 2.0 உரிமத்திலிருந்து, SSPL (server side public license) மற்றும் Elastic License 2.0 ஆகிய இரட்டை உரிம முறைக்கு மாற்றியது. AWS நிறுவனம், கடைசியாக இருந்த Apache 2.0 குறியீட்டைப் பிரித்து OpenSearch-ஆக உருவாக்கியது; இது தொடர்ந்து Apache 2.0 உரிமத்திலேயே உள்ளது. செப்டம்பர் 2024-ல், Elastic நிறுவனம் தனது இலவச source code-க்கு AGPLv3 (GNU Affero General Public License version 3)-ஐ மற்றொரு விருப்பமாகச் சேர்த்தது. ஒரு தனிநபர் தனது VPS-ல் self-hosting செய்வதற்கு, இந்த உரிமங்கள் அனைத்தும் நீங்கள் செய்யும் செயலுக்கு அனுமதி அளிக்கின்றன. நீங்கள் இந்த மென்பொருளை ஒரு managed service-ஆக மற்றவர்களுக்கு வழங்கும்போதே உரிமக் கட்டுப்பாடுகள் சிக்கலாகின்றன.

ஒரு சிறிய server-ல் இவற்றிற்கு இடையேயான நடைமுறை வேறுபாடு, வரலாற்றில் கூறப்படுவதை விடக் குறைவுதான், ஏனெனில் இரண்டின் அடிப்படையிலும் ஒரே engine தான் உள்ளது. பெயர்கள் மட்டுமே மாறுகின்றன: index lifecycle என்பது OpenSearch-ல் ISM (index state management) என்றும், Elasticsearch-ல் ILM (index lifecycle management) என்றும் அழைக்கப்படுகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, OpenSearch 2.12 மற்றும் அதற்குப் பிந்தைய பதிப்புகள், முதல்முறை இயக்கும்போது admin password அமைக்கப்படாவிட்டால் தொடங்க மறுத்துவிடும்.

sudo sysctl -w vm.max_map_count=262144
printf 'vm.max_map_count = 262144\n' | sudo tee /etc/sysctl.d/99-opensearch.conf
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" \
  -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" \
  opensearchproject/opensearch:latest

sysctl -w வரியானது அந்த அமைப்பை உடனடியாகச் செயல்படுத்துகிறது, மேலும் /etc/sysctl.d/-ல் உள்ள கோப்பு reboot-க்குப் பிறகும் அந்த அமைப்பைத் தக்கவைக்கிறது. curl -k -u admin:<password> https://localhost:9200 மூலம் container சரியாகத் தொடங்கியுள்ளதா எனச் சரிபார்க்கவும். இது demo certificate-ஐப் பயன்படுத்தி https மூலம் பதிலளிக்கும், எனவே -k சரிபார்ப்பைத் தவிர்க்கிறது; cluster மற்றும் அதன் பதிப்பைக் குறிப்பிடும் ஒரு சிறிய JSON தொகுதியே ஆரோக்கியமான பதிலாகும். OpenSearch நிறுவல் பக்கம், Docker Desktop பயன்படுத்துபவர்கள் host-க்குக் குறைந்தபட்சம் 4 GB memory ஒதுக்க வேண்டும் என்று அறிவுறுத்துகிறது; இது அந்த process-க்குத் தேவைப்படும் வளங்கள் குறித்த தெளிவான அறிகுறியாகும்.

Loki எவ்வாறு சிறியதாக இருக்கிறது: முழுமையான உரை குறியீட்டிற்கு (full text index) பதிலாக labels-ஐப் பயன்படுத்துதல்

Loki, labels-ஐக் கொண்டு ஒரு குறியீட்டை (index) பராமரிக்கிறது மற்றும் log வரிகளைச் சுருக்கப்பட்ட துண்டுகளாக (compressed chunks) சேமிக்கிறது. ஒரு query முதலில் streams-ஐத் தேர்ந்தெடுத்து, பிறகு உரையை வடிகட்டுகிறது (filters). {unit="ssh.service"} |= "Failed password" அதன் label மூலம் stream-ஐத் தேர்வு செய்கிறது, பின்னர் அந்தத் துண்டுகளில் குறிப்பிட்ட string-ஐத் தேடுகிறது. ஒரு வரியின் உள்ளடக்கத்தை (body) எதையும் இது குறியீடு செய்வதில்லை, எனவே ingestion செலவு குறைவாகவே இருக்கும் மற்றும் நினைவகத்தில் (memory) வைத்திருக்க வேண்டிய inverted index எதுவும் இல்லை. இதன் செலவு query நேரத்திற்கு மாறுகிறது, நீங்கள் எந்த service-ஐப் பார்க்கிறீர்கள் என்பது உங்களுக்குத் தெரிந்திருக்கும்போது இது ஒரு நல்ல பரிமாற்றமாகும்.

Grafana-வின் ஆவணங்கள் monolithic mode-ஐ, அதாவது Loki-ன் அனைத்துப் பகுதிகளையும் -target=all உடன் ஒரே process-ல் இயக்குவதை, ஒரு நாளைக்கு சுமார் 20GB வரை குறைவான வாசிப்பு மற்றும் எழுதும் அளவுகளுக்குப் பரிந்துரைக்கின்றன. ஒரு VPS-க்கு இது போதுமானதாகும்.

இதில் உள்ள சிக்கல் label cardinality ஆகும். label மதிப்புகளின் ஒவ்வொரு தனித்துவமான சேர்க்கையும் ஒரு stream ஆகும், மேலும் stream-களின் எண்ணிக்கையே Loki-ன் நினைவகம் மற்றும் குறியீட்டின் அளவைத் தீர்மானிக்கிறது. ஒரு label-ல் client IP address அல்லது request identifier போன்றவற்றை வைத்தால், ஒவ்வொரு மதிப்பிற்கும் ஒரு stream உருவாகும். இதனால், ஒரு பிஸியான web server ஒரு நாளில் பல்லாயிரக்கணக்கான streams-ஐ உருவாக்கக்கூடும், மேலும் kernel அதை நிறுத்தும் வரை அந்த process வளர்ந்துகொண்டே இருக்கும். காகிதத்தில் எண்ணக்கூடிய மதிப்புகளை மட்டுமே labels-ஆக வைத்திருங்கள்: unit, host, job, level. மாறக்கூடிய விவரங்களை வரியிலேயே (line) வையுங்கள், அங்கு query நேரத்தில் ஒரு filter expression மூலம் அதைக் கண்டறிய முடியும்.

ஒரே VPS-ல் Loki மற்றும் Alloy நிறுவுதல்

இரண்டு செயல்முறைகள் (processes) இந்த வேலையைச் செய்கின்றன. Loki தரவுகளைச் சேமித்து, வினவல்களுக்குப் பதிலளிக்கிறது. Grafana Alloy பதிவுகளை (logs) வாசித்து அவற்றை அனுப்புகிறது. முன்பு Promtail பயன்படுத்தப்பட்டது, ஆனால் அது 2 March 2026 அன்று அதன் ஆயுட்காலத்தை முடித்துக்கொண்டது. எனவே, புதிய நிறுவல்களில் Alloy பயன்படுத்தப்படுகிறது. Loki-ன் அதிகாரப்பூர்வ Docker உதாரணம் இப்போது Alloy உள்ளமைவை (config) உள்ளடக்கியுள்ளது.

wget https://raw.githubusercontent.com/grafana/loki/v3.7.0/cmd/loki/loki-local-config.yaml -O loki-config.yaml

அந்தக் கோப்பைப் பயன்படுத்துவதற்கு முன்பு அதைப் படிக்கவும். அது path_prefix: /tmp/loki-ஐ /tmp/loki/chunks-க்குக் கீழே உள்ள chunks-உடன் அமைக்கிறது. இது ஒரு சோதனைக்குச் சரியானது, ஆனால் ஒரு server-க்குத் தவறு. container-ன் /tmp-க்குக் கீழே உள்ள எதுவும் container மீண்டும் உருவாக்கப்படும்போது நீடிக்காது. எனவே, அடுத்த முறை image update செய்யும்போது உங்கள் வரலாறு அழிந்துவிடும். அதை நீங்கள் mount செய்யும் ஒரு பாதைக்கு (path) மாற்றவும்.

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

docker volume create loki-data
docker run --name loki -d \
  -v $(pwd):/mnt/config -v loki-data:/loki \
  -p 127.0.0.1:3100:3100 \
  grafana/loki:3.7.0 -config.file=/mnt/config/loki-config.yaml
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3100/ready

அந்தக் கடைசி கட்டளை 200-ஐ அச்சிட வேண்டும். ஏனெனில் Loki தரவுகளைப் பெறத் தயாரானதும் /ready HTTP 200 குறியீட்டைத் தரும். வேறு ஏதேனும் வந்தால், செயல்முறை இன்னும் தொடங்கவில்லை அல்லது உள்ளமைவு நிராகரிக்கப்பட்டது என்று பொருள். docker logs loki அதற்கான காரணத்தைக் கூறும். run கட்டளையில் உள்ள இரண்டு விவரங்கள் வேண்டுமென்றே சேர்க்கப்பட்டுள்ளன. port 127.0.0.1-ல் மட்டுமே வெளியிடப்படுகிறது. ஏனெனில் மாதிரி உள்ளமைவு auth_enabled: false-ஐக் கொண்டுள்ளது மற்றும் Loki-ல் சொந்தமாக பயனர் அங்கீகாரம் (authentication) இல்லை. எனவே, port 3100-ஐ அணுகக்கூடிய எவரும் அனைத்துப் பதிவுகளையும் படிக்கலாம் அல்லது போலியான பதிவுகளை எழுதலாம். இதை loopback-ல் வைக்கவும் அல்லது VPN அல்லது அங்கீகாரம் வழங்கும் reverse proxy-க்கு பின்னால் வைக்கவும். named volume முக்கியமானது, ஏனெனில் image loki என்ற பயனர் மற்றும் UID 10001-ல் இயங்குகிறது. எனவே, root-க்குச் சொந்தமான bind mounted host directory-ஐ container-ஆல் எழுத முடியாது.

sudo apt-get update && sudo apt-get install -y gpg wget
sudo mkdir -p /etc/apt/keyrings/
sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y alloy

Alloy /etc/alloy/config.alloy-ஐ வாசிக்கிறது. இது system journal மற்றும் ஒரு கோப்புத் தொகுப்பை எடுத்து, இரண்டையும் உள்ளூர் Loki-க்கு அனுப்புகிறது.

loki.write "local" {
  endpoint {
    url = "http://127.0.0.1:3100/loki/api/v1/push"
  }
}

loki.relabel "journal" {
  forward_to = []
  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }
}

loki.source.journal "read" {
  forward_to    = [loki.write.local.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = {job = "systemd-journal", host = "app-01"}
}

local.file_match "nginx" {
  path_targets = [{"__path__" = "/var/log/nginx/*.log", "job" = "nginx", "host" = "app-01"}]
}

loki.source.file "nginx" {
  targets    = local.file_match.nginx.targets
  forward_to = [loki.write.local.receiver]
}

relabel விதி, journal field __journal__systemd_unit-ஐ unit என்ற label-க்கு நகலெடுக்கிறது. இதுதான் பிற்காலத்தில் {unit="ssh.service"} வேலை செய்ய உதவுகிறது. அந்த விதி இல்லையென்றால், unit பெயர் பதிவின் உள்ளே இருக்கும், label-ல் இருக்காது. இதனால் உங்களால் அதைத் தேர்ந்தெடுக்க முடியாது மற்றும் ஒவ்வொரு வினவலும் அனைத்தையும் ஸ்கேன் செய்ய வேண்டியிருக்கும்.

sudo systemctl reload alloy
systemctl show -p User alloy
sudo journalctl -n 5
sudo -u alloy journalctl -n 5

இங்குதான் பெரும்பாலான அமைப்புகள் சிக்கிக்கொள்கின்றன. Alloy root-ஆக அல்லாமல், அதன் சொந்த service account-ஆக இயங்குகிறது. system journal-ஐ வாசிக்க systemd-journal குழுவில் உறுப்பினராக இருக்க வேண்டும். மேலும், Debian மற்றும் Ubuntu-வில் /var/log/nginx-க்குக் கீழே உள்ள கோப்புகள் adm குழுவிற்குச் சொந்தமானவை. கடைசி கட்டளையில் systemctl show அச்சிட்ட கணக்கை மாற்றவும். அது root-ஆக இயக்கும்போது கிடைப்பதை விட மிகக் குறைவான பதிவுகளைத் தந்தால், அந்த கணக்கினால் system journal-ஐ வாசிக்க முடியாது என்று பொருள். உங்கள் உள்ளமைவு சரியாக இருந்தாலும் Loki காலியாகவே இருக்கும். குழுக்களைச் சேர்த்து, sudo usermod -aG systemd-journal,adm alloy மற்றும் அதைத் தொடர்ந்து sudo systemctl restart alloy மூலம் restart செய்யவும்.

curl -G -s "http://127.0.0.1:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job="systemd-journal"}' \
  --data-urlencode 'limit=5' | jq '.data.result | length'

0-க்கு மேல் உள்ள எண், அந்த label-உடன் streams இருப்பதையும், அதில் பதிவுகள் இருப்பதையும் குறிக்கிறது. 0 என்றால் அந்த label-ன் கீழ் இன்னும் எதுவும் வரவில்லை என்று பொருள். ஒரு பொதுவான தவறான எச்சரிக்கையை ஒரு default விளக்குகிறது: loki.source.journal, max_age-ஐ 7h என அமைக்கிறது. எனவே, புதிதாகத் தொடங்கும்போது கடந்த ஏழு மணிநேர journal மட்டுமே வாசிக்கப்படும், அதற்கு முந்தையவை அல்ல. மனிதர்கள் பயன்படுத்தும் இடைமுகத்திற்கு, அதே box-ல் Grafana-வை இயக்கி, Loki data source-ஐ http://127.0.0.1:3100.-க்குச் சுட்டிக்காட்டவும். Container பதிவுகளுக்கு வேறு source தேவை: Alloy இயங்கும் Docker container-களைக் கண்டறிந்து அவற்றைப் பின்தொடர்கிறது (tail). Loki-ன் தொடக்க உதாரணம் இதைத்தான் செய்கிறது. VPS-ல் உள்ள ஒற்றை node k3s cluster-ல், அந்த வேலை kubelet எழுதும் pod log directory-க்கு மாறுகிறது.

Retention: உங்கள் logs எப்போது நீக்கப்பட வேண்டும் என்பதைத் தீர்மானித்தல்

வட்டு (disk) நிரம்பும் வரை யாரும் retention காலத்தை முடிவு செய்வதில்லை; சேவை முடங்கியிருக்கும் நிலையில் அதிகாலை 3 மணிக்கு அவசரமாக இதைச் செய்ய வேண்டியிருக்கும். முதல் நாளிலேயே இரண்டு கேள்விகளைக் கேட்டு இதை முடிவு செய்யுங்கள்: நீங்கள் உண்மையில் எவ்வளவு பழைய தரவுகளைத் தேடுகிறீர்கள், மற்றும் அடுத்த மாதம் நடக்கும் incident review-ன் போது உங்களிடம் என்னென்ன தரவுகள் இருக்க வேண்டும். ஒரு தனி server-க்கு, 14 முதல் 30 நாட்கள் என்பது இந்த இரண்டு கேள்விகளுக்கும் போதுமான விடையாகும்.

நீங்கள் compactor-ஐ இயக்கும் வரை Loki எதையும் நீக்காது. Retention இயல்பாகவே முடக்கப்பட்டிருக்கும்; இது பலருக்கு ஆச்சரியத்தை அளிக்கும், ஏனெனில் retention_period அமைப்பில் இருந்தும், அது எதையும் செய்யாமல் இருந்ததால் அவர்களின் volume நிரம்பியிருக்கும்.

limits_config:
  retention_period: 744h

compactor:
  working_directory: /loki/retention
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
  delete_request_store: filesystem

744h என்பது 31 நாட்களைக் குறிக்கும். அந்தத் தொகுதியைக் கட்டுப்படுத்தும் நான்கு விதிகள் இங்கே உள்ளன:

• Retention என்பது compactor மூலம் செயல்படுத்தப்படுகிறது, மேலும் compactor-ஐ ஒரே ஒரு instance-ஆக மட்டுமே இயக்க வேண்டும் என்று Grafana ஆவணங்கள் கூறுகின்றன. ஒரு VPS-ல் இது தானாகவே நடக்கும்.
• குறைந்தபட்ச retention காலம் 24h ஆகும், மேலும் index காலம் 24h ஆக இருக்கும்போது மட்டுமே retention வேலை செய்யும். மாதிரி schema_config ஏற்கனவே period: 24h-ஐப் பயன்படுத்துகிறது, எனவே அதை மாற்ற வேண்டாம்.
• retention_enabled என்பது true எனும்போது delete_request_store அவசியமானது. இது நீக்குதல் கோரிக்கைகளைச் சேமிக்கும் இடத்தைக் குறிப்பிடுகிறது, எனவே filesystem-ஐ அடிப்படையாகக் கொண்ட single node-ல் இது ஏற்கனவே schema-வில் உள்ள object_store: filesystem-உடன் ஒத்துப்போக வேண்டும்.
• Chunks முதலில் குறிக்கப்பட்டு, retention_delete_delay-க்கு பிறகு நீக்கப்படும் (இங்கே இது 2h). எனவே, கொள்கை குறிப்பிடுவதை விட தாமதமாகவே வட்டு இடம் காலியாகும். ஒரு reload செய்த ஐந்து நிமிடங்களுக்குப் பிறகு df-ஐ வைத்து இந்த அமைப்பை மதிப்பிட வேண்டாம்.

OpenSearch தனித்தனி வரிகளுக்குப் பதிலாக முழு index-களையும் நீக்குகிறது, இதனால்தான் log index-கள் ஒவ்வொரு நாளும் உருவாக்கப்படுகின்றன. ஒரு ISM policy, index-ஐ பல்வேறு நிலைகளுக்குக் கொண்டு சென்று, அது போதுமான அளவு பழையதாகிவிட்டால் அதை நீக்கிவிடும். ஒரு ism_template அந்தப் புதிய index-களுடன் கொள்கையை இணைக்கும், எனவே நீங்கள் அதை நினைவில் வைத்திருக்க வேண்டியதில்லை.

{
  "policy": {
    "description": "delete log indexes after 14 days",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "14d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ],
        "transitions": []
      }
    ],
    "ism_template": { "index_patterns": ["logs-*"], "priority": 100 }
  }
}

நீங்கள் எந்த அமைப்பை இயக்கினாலும், retention எண் என்பது அதன் பின்னணியில் உள்ள free space சரிபார்ப்பு எவ்வளவு துல்லியமாக இருக்கிறதோ அவ்வளவுதான் சிறந்தது. 10 நாட்களுக்கான logs ஏற்கனவே volume-ஐ நிரப்பிவிட்டால், 14 நாட்களில் நீக்கும் கொள்கை உங்களுக்கு உதவாது. எனவே, இந்தக் கொள்கையுடன் VPS-ல் வட்டு ஆரோக்கியத்தைக் கண்காணித்தல் மற்றும் 80% பயன்பாட்டில் எச்சரிக்கை (alert) அனுப்பும் வசதியைச் சேர்த்துக்கொள்ளுங்கள்.

ஒரு GB log-க்கு எவ்வளவு disk தேவை

இதற்கான உண்மையான பதில் உங்கள் log-ல் உள்ள வரிகள் மற்றும் fields-ஐப் பொறுத்தது. எனவே, வெளியிடப்பட்ட எந்தவொரு விகிதத்தையும் நம்புவதை விட, உங்கள் சொந்த தரவுகளைக் கொண்டு அளவிடுவது சிறந்தது. ஒவ்வொரு தொழில்நுட்பத்தின் செயல்பாடும் மாறுபடுவதால், disk பயன்பாட்டை முன்கூட்டியே கணிப்பது கடினம். OpenSearch மற்றும் Elasticsearch ஆகியவை ஒவ்வொரு indexed field-க்கும் ஒரு inverted index-ஐ உருவாக்குகின்றன. இதனால், சேமிக்கப்படும் தரவு மூல உரையை (raw text) விட பெரியதாக இருக்கும்; மேலும், ஒவ்வொரு replica-வும் இந்த அளவை பலமடங்கு அதிகரிக்கும். ஒரே node-ல் replica count-ஐ 0 என அமைக்கவும், ஏனெனில் அதே node-ல் உள்ள replica shard அந்த node செயலிழந்தால் உதவாது. இதை 1 என வைத்தால் disk பயன்பாடு இருமடங்காகும், மேலும் cluster health எப்போதும் yellow நிலையிலேயே இருக்கும். Loki சுருக்கப்பட்ட chunks மற்றும் சிறிய label index-ஐ மட்டுமே எழுதுவதால், அதன் disk பயன்பாடு வரிகளின் சுருக்கப்பட்ட அளவைப் பொறுத்தே அமையும்.

sudo du -sh /var/lib/docker/volumes/loki-data/_data
curl -k -u admin:<password> "https://localhost:9200/_cat/indices?v&h=index,docs.count,store.size"

மேலே உள்ளவற்றில் எது உங்கள் சூழலுக்குப் பொருந்துகிறதோ, அதைத் தொடர்ந்து இரண்டு நாட்கள் இயக்கவும். அந்த இரண்டு நாட்களுக்கு இடைப்பட்ட வித்தியாசமே உங்கள் தினசரி வளர்ச்சி (daily growth). இந்த அளவை உங்கள் retention நாட்களால் பெருக்கவும். அதனுடன் compaction மற்றும் merges-க்காக சுமார் 30% கூடுதல் இடவசதியைச் சேர்க்கவும். பின்னர், அந்த அளவை உங்கள் volume கொள்ளளவுடன் ஒப்பிடவும். அது போதவில்லை என்றால், புதிய disk வாங்குவதற்கு முன் retention காலத்தைக் குறைக்கவும். ஏனெனில், பெரிய volume-ஐ வாங்குவது தற்காலிகத் தீர்வே, அது சில வாரங்களில் மீண்டும் அதே சிக்கலை உருவாக்கும்.

சிறிய server-களில் முதலில் பாதிக்கப்படுபவை

முதலில் Memory தீர்ந்துவிடும். Kernel-ன் OOM (out of memory) killer ஒரு பெரிய process-ஐத் தேர்ந்தெடுத்து நிறுத்திவிடும்; logging server-ல் JVM தான் மிகப்பெரிய process-ஆக இருக்கும். journalctl -k | grep -i "killed process", அடைப்புக்குறிக்குள் process பெயருடன் அந்த kill நிகழ்வைக் காட்டும். பாதிக்கப்பட்ட process எப்போதும் log stack-ஆக இருக்காது: sshd அல்லது உங்கள் database கூட தேர்ந்தெடுக்கப்படலாம்; இதனால் நீங்கள் log-களைப் பெற விரும்பிய application-மே செயலிழக்க நேரிடும். Containers-க்குத் தெளிவான உச்சவரம்புகளை (ceilings) வழங்குங்கள், அப்போதுதான் நீங்கள் விரும்பும் இடத்தில் தோல்வி ஏற்படும்; இதற்காகத்தான் memory limits in Docker Compose பயன்படுத்தப்படுகின்றன.

இரண்டாவதாக Disk தீர்ந்துவிடும், search engine-கள் ஒரு குறிப்பிட்ட மற்றும் எளிதில் அடையாளம் காணக்கூடிய வகையில் தோல்வியடையும். Elasticsearch மற்றும் OpenSearch ஆகியவை disk பயன்பாட்டைப் பல நிலைகளில் கண்காணிக்கும். Low watermark 85%-லும், high watermark 90%-லும் இருக்கும். 95% என்ற flood stage-ஐ எட்டும்போது, அந்த node-ல் shard-களைக் கொண்ட ஒவ்வொரு index-ம் index.blocks.read_only_allow_delete என்ற தடையைப் பெறும், அதன் பிறகு எழுதும் செயல்பாடுகள் blocked by: [FORBIDDEN/12/index read-only / allow delete (api)] பிழையுடன் தோல்வியடையும். பயன்பாடு high watermark-க்குக் கீழே குறைந்தவுடன் இந்தத் தடை நீக்கப்படும். முதலில் disk இடத்தை விடுவியுங்கள், அதன் பிறகும் தடை நீடித்தால் மட்டும் கைமுறையாக அதை நீக்குங்கள்.

curl -k -u admin:<password> -X PUT "https://localhost:9200/_all/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.blocks.read_only_allow_delete": null}'

Loki அமைதியாகத் தோல்வியடையும். இதற்கு read-only mode கிடையாது, எனவே volume முழுமையாக நிரம்பினால் sender-ல் தோல்வியடைந்த pushes மற்றும் query முடிவுகளில் இடைவெளிகள் ஏற்படும். மேலும், cardinality பிரச்சினை ஏற்பட்டால் அது பிழையாகத் தெரியாமல் memory பயன்பாடு மெதுவாக அதிகரிப்பதாகவே இருக்கும். Incident நடந்த பிறகு பார்ப்பதை விட, அட்டவணைப்படி chunks directory-ன் அளவைக் கண்காணித்து வாருங்கள்.

கடைசியாக, தவறான தரவுகளைச் சேமிப்பது தோல்விக்கு வழிவகுக்கும். Log system என்பது metrics system அல்ல: 10 வினாடிகளுக்கு ஒருமுறை CPU load-ஐ எடுத்து text-ஆகச் சேமிப்பது அதிக செலவு மற்றும் அதை வரைபடமாக்குவது கடினம்; அந்த வேலை a Zabbix monitoring server on Ubuntu 24.04 போன்ற ஒன்றிற்கு உரியது. Application exceptions-க்கு grouping, deduplication மற்றும் stack trace view தேவை, இது a self-hosted error tracker-ன் வேலை. தளம் செயலிழந்துள்ளதா என்பதை அறிவது தனி வேலை, அதற்கு an uptime and status page such as Uptime Kuma போன்ற சேவைகளைப் பயன்படுத்தலாம். Log system-ஐ மனிதர்கள் வாசிக்கும் text வரிகளுக்காக மட்டும் பயன்படுத்துங்கள்.

FAQ

எனது server logs-ஐத் தேட Elasticsearch தேவையா?

ஒன்று அல்லது இரண்டு server-களுக்கு இது தேவையில்லை. journalctl ஏற்கனவே unit, priority, boot மற்றும் time range ஆகியவற்றின் அடிப்படையில் வடிகட்டுகிறது, மேலும் சுழற்சி செய்யப்பட்ட (rotated) கோப்புகளை grep மற்றும் zgrep மூலம் அணுகலாம். பல இயந்திரங்கள் இருக்கும்போது, அவை அனைத்திலும் ஒரே நேரத்தில் free text search செய்ய வேண்டியிருக்கும்போது அல்லது பல பயனர்களுக்கு பகிரப்பட்ட interface தேவைப்படும்போது மட்டுமே search cluster-க்கான RAM செலவு நியாயமானது. அதற்கு குறைவான பயன்பாட்டிற்கு, size limit மற்றும் retention time கொண்ட journald போதுமானது, இது கூடுதல் RAM-ஐப் பயன்படுத்தாது.

Self-hosted log management-க்கு எவ்வளவு RAM தேவை?

பொதுவான விதியைப் பின்பற்றுவதை விட, ஒவ்வொரு project-ன் அதிகாரப்பூர்வ ஆவணங்களில் உள்ள அளவீடுகளைப் பயன்படுத்தவும். Loki மற்றும் Alloy ஆகியவை Go மொழியில் எழுதப்பட்டவை, இவை முன்கூட்டியே heap-ஐ ஒதுக்கீடு செய்யாது. Grafana ஆவணங்களின்படி, monolithic Loki ஒரு நாளைக்கு சுமார் 20GB வரை கையாளும். OpenSearch-ன் sample compose கோப்பு demo-விற்கு 512 MB heap-ஐயும், production உதாரணத்திற்கு 2 GB heap-ஐயும் பரிந்துரைக்கிறது. Elastic-ன் கூற்றுப்படி, heap என்பது மொத்த நினைவகத்தில் 50% அல்லது அதற்கும் குறைவாக இருக்க வேண்டும்; எனவே 2 GB heap-க்கு Kibana-வைத் தவிர்த்து 4 GB RAM கொண்ட இயந்திரம் தேவை. Logstash ஆவணங்கள் குறைந்தது 4GB heap-ஐப் பரிந்துரைக்கின்றன. இவை ஆவணப்படுத்தப்பட்ட அமைப்புகள் மட்டுமே, benchmarks அல்ல; எனவே உங்கள் தேவையைத் தீர்மானிக்கும் முன் உங்கள் server-ன் சுமையை அளவிடவும்.

Logs-ஐப் பொறுத்தவரை Loki மற்றும் OpenSearch-க்கு இடையே உள்ள உண்மையான வேறுபாடு என்ன?

Index model தான் முக்கிய வேறுபாடு. Loki labels-ஐ மட்டுமே index செய்கிறது, log body-ஐ compressed chunks-ஆக வைத்திருந்து query செய்யும்போது ஸ்கேன் செய்கிறது; இதனால் எழுதுவது (writes) எளிது, ஆனால் விரிவான query-களுக்கு அதிக நேரம் எடுக்கும். OpenSearch புலங்களில் (fields) உள்ள உள்ளடக்கத்தை index செய்கிறது, எனவே முழு உரைத் தேடல் (full text search) வேகமானது, ஆனால் இதற்கு அதிக நினைவகமும் வட்டும் தேவைப்படும். எந்த service மற்றும் எந்த கால இடைவெளியில் தேட வேண்டும் என்பது உங்களுக்குத் தெரிந்தால் Loki-ஐத் தேர்ந்தெடுக்கவும். முன்கூட்டியே கணிக்க முடியாத உரையைத் தேட வேண்டியிருந்தால் OpenSearch-ஐத் தேர்ந்தெடுக்கவும்.

VPS-ல் logs-ஐ எவ்வளவு காலம் வைத்திருக்க வேண்டும்?

வட்டு நிரம்பி தானாகவே logs-ஐ அழிக்கும் முன், நீங்களே ஒரு கால அளவைத் தீர்மானிக்கவும். ஒவ்வொரு system-லும் ஒரே ஒரு இடத்தில் மட்டும் இதை அமைக்கவும்: journald-க்கு MaxRetentionSec= மற்றும் SystemMaxUse=, Loki-க்கு compactor வசதியுடன் retention_period, மற்றும் OpenSearch-க்கு min_index_age கொண்ட ISM policy. பெரும்பாலான ஒற்றை server அமைப்புகளுக்கு, 14 முதல் 30 நாட்கள் வரை logs வைத்திருப்பது பிழைத்திருத்தம் (debugging) மற்றும் சம்பவ ஆய்வுக்குப் போதுமானது. நீண்ட காலம் வைத்திருக்க வேண்டிய தரவுகளை server-க்கு வெளியே சேமிக்க வேண்டும், ஏனெனில் செயலிழந்த server-ல் மட்டும் இருக்கும் log ஒரு முழுமையான ஆவணமாகக் கருதப்படாது.

Loki-க்கு logs-ஐ அனுப்ப இன்னும் Promtail-ஐப் பயன்படுத்தலாமா?

இல்லை. Promtail-ன் ஆயுட்காலம் 2 March 2026 அன்று முடிவடைந்தது, அதற்குப் பதிலாக Grafana Alloy வந்துவிட்டது. Loki-ன் தற்போதைய Docker install உதாரணம் Alloy configuration-ஐயே பயன்படுத்துகிறது. ஏற்கனவே உள்ள Promtail config-ஐ Alloy syntax-க்கு மாற்ற Grafana ஒரு converter-ஐ வழங்குகிறது. தற்போதுள்ள Promtail install தொடர்ந்து இயங்கும், ஆனால் அதற்குப் புதிய திருத்தங்கள் (fixes) கிடைக்காது. எனவே, இந்த மாற்றத்தை ஒத்திவைக்கக்கூடிய upgrade-ஆகக் கருதாமல், அவசியமான பராமரிப்புப் பணியாகக் கருதி உடனே மாற்றவும்.