Zabbix Server

آٹو اسکیلنگ کی سپورٹ # ماہر

‏AWS آٹو اسکیلنگ Zabbix کے ساتھ کیسے کام کرتی ہے؟

‏Zabbix سے آٹو اسکیلنگ سنبھالنے کے لیے تین باتوں کا خیال رکھنا ہوتا ہے:

1. نیا انسٹنس آتے ہی اُسے Zabbix میں شامل کرنا۔ یہ فعال Zabbix ایجنٹس کی خودکار رجسٹریشن سے کیا جا سکتا ہے (6.4، 6.0، 4.0)۔ یوں نیا انسٹنس آتے ہی Zabbix اُسے خودکار طور پر نئے ہوسٹ کے طور پر شامل کر لیتا ہے۔
2. انسٹنس کا ID ‏Zabbix انوینٹری میں محفوظ کرنا۔ انسٹنس ختم ہونے (scale in) پر ہمیں اُس کے ID کے ساتھ پیغام ملتا ہے، اس لیے اُسے ہوسٹ انوینٹری میں رکھنا ضروری ہے تاکہ ڈھونڈ کر مٹایا جا سکے۔
3. ‏AWS کے اسکیلنگ پیغامات وصول کرنا۔ اسکیلنگ کا واقعہ ہونے پر AWS آپ کے مقرر کردہ SNS ٹاپک میں پیغام شائع کرتا ہے۔ اُس ٹاپک کو SQS قطار سے جوڑ کر ہم Zabbix سے پیغامات پڑھ سکتے ہیں اور اسکیلنگ گروپس سے نکلنے والے انسٹنسز مٹا سکتے ہیں۔

کلائنٹ کی ترتیب

‏Zabbix میں آٹو اسکیلنگ کے لیے کلائنٹس تیار کرنے کو دو مرحلے درکار ہیں: ‏Zabbix ایجنٹ کی ترتیب، اور instance_id آئٹم کے لیے یوزر پیرامیٹر والی فائل شامل کرنا۔

‏Zabbix ایجنٹ کی ترتیب

آپ کی دیگر ضروری تبدیلیوں کے علاوہ، Zabbix ایجنٹ کی مقامی ترتیب فائل (عموماً /etc/zabbix/zabbix_agentd.conf) میں چھ باتیں بدلنی ہوتی ہیں:

• ‏Server آپشن کو کمنٹ کر دیں۔
• فعال سرور مقرر کرنے کے لیے ServerActive=YOUR__ZABBIX__IP__ADDRESS شامل کریں۔
• ‏Hostname آپشن کو کمنٹ کر دیں۔
• ‏StartAgents آپشن 0 کر دیں۔
• ‏HostnameItem آپشن system.hostname کر دیں۔
• ‏HostMetadataItem آپشن system.uname کر دیں۔

اس ترتیب سے Zabbix کلائنٹ فعال موڈ میں چلتا ہے (کلائنٹ سرور کو معلومات بھیجتا ہے، سرور سے جانچ وصول نہیں کرتا)۔ ساتھ ہی Zabbix مشین کے نام کو ہی ہوسٹ نام مانتا ہے، جس سے ہر نئے سرور کے آغاز پر نام بدلنے کی ضرورت نہیں رہتی۔ آخر میں Zabbix ‏uname کا نتیجہ میٹا ڈیٹا کے طور پر بھیجتا ہے: ‏AWS انسٹنسز خاص کرنل استعمال کرتے ہیں، اس لیے اُس میں aws کی قدر نظر آتی ہے جسے سرور کی رجسٹریشن کے لیے استعمال کیا جا سکتا ہے۔

‏instance_id پیرامیٹر

پہلے سے طے شدہ طور پر، آٹو اسکیلنگ سے آنے والا نیا سرور Zabbix میں AWS EC2 Template نامی خاص ٹیمپلیٹ سے جڑ جاتا ہے، جس میں instance_id آئٹم انوینٹری کے alias خانے سے منسلک ہوتا ہے۔ اُسے بھرنے کے لیے Zabbix کلائنٹ میں یہ فائل بنا کر یوزر پیرامیٹر شامل کریں:

UserParameter=aws.ec2.instance_id,curl -s http://169.254.169.254/latest/meta-data/instance-id

سرور کی ترتیب

کلائنٹس کی ترتیب کے بعد اگلا مرحلہ سرور کو یوں ترتیب دینا ہے کہ وہ ہٹائے گئے انسٹنسز مٹا دے۔ تیز اور آسان راستہ دو مرحلوں کا ہے: اسکیلنگ پیغامات ایک SQS قطار میں بھیجنا اور سرور کو اُسے پڑھنے کے لیے ترتیب دینا۔

اسکیلنگ پیغامات SQS قطار میں بھیجیں

ہم چاہتے ہیں کہ آٹو اسکیلنگ سروس کی بھیجی اطلاعات ایک SQS قطار میں محفوظ رہیں، تاکہ پائیداری اور وسعت دونوں ملیں۔ چونکہ AWS آٹو اسکیلنگ اطلاعات ایک SNS ٹاپک میں شائع کرتی ہے، اس لیے درکار ہے:

• ایک SNS ٹاپک بنانا۔
• ایک SQS قطار بنانا۔
• ‏SNS کو پیغامات SQS تک پہنچانے کے لیے ترتیب دینا۔
• پیغامات پڑھ سکنے والا ایک IAM صارف بنانا۔

یہ ترتیب پیچیدہ ہے، اس لیے آپ ہمارے CloudFormation اسٹیک سے مطلوبہ ریجن میں تمام اجزا بنا سکتے ہیں۔ تعیناتی کے بعد Outputs ٹیب میں چار قدریں ملیں گی جنہیں نوٹ کر لیں:

• ‏SNSTopicARN: بنائے گئے SNS ٹاپک کا ARN۔
• ‏SQSQueueURL: ‏SQS قطار کا URL۔
• ‏SQSReadIAMUserAccessKey اور SQSReadIAMUserSecretKey: ‏IAM صارف کی کلید اور خفیہ کلید۔

ترتیب کے لیے یہی قدریں درکار ہیں۔ فائل /etc/zabbix/zabbix_ami.yml میں اس طرح کے حصے میں ترمیم کریں:

sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url:
      access_key_id:
      secret_access_key:
      region:

اسکیلنگ اطلاعات والی ہر SQS قطار کے لیے موجودہ اندراج جیسا ایک اور اندراج شامل کریں، CloudFormation کی دی گئی قدروں کے ساتھ۔ اس فائل کے بارے میں مزید تفصیل اہم فائلیں کے حصے میں ہے۔

اہم فائلیں # ماہر

‏Zabbix AMI میں چند خاص فائلیں ہیں جن کے بارے میں جاننا ضروری ہے۔

/etc/zabbix/zabbix_ami.yml

یہی سب سے اہم فائل ہے، کیونکہ اسکیلنگ کی جانچ یا SNS اطلاعات جیسے خصوصی پہلوؤں کی ترتیب یہی سنبھالتی ہے۔ ایک مثال (فرضی معلومات کے ساتھ):

zabbix:
  api:
    user: autoscaler_api_user
    password: i-073672daf01037aea94
sns:
  aws:
    access_key_id: AKK4L6A3OXZZ5HE2POQRU7V
    secret_access_key: cICycAg26hSDpsJwbhZjbaaYlt4Tz3n1xqE7Oxp6X2Hf
    region: us-east-1
  topics:
    not_classified: arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    information:    arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    warning:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    average:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    high:           arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    disaster:       arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url: https://sqs.us-east-1.amazonaws.com/000000000/zabbix-pro-sqs-queue
      access_key_id: AKIA3OXZZ5HEWUR5A16CNWH
      secret_access_key: 8ttYO3Ba9K6p0C+aj3fH5cDt2eRLHmlkHbMtlrpv18S7KRbC
      region: us-east-1

اِس وقت اس فائل میں تین الگ حصے ہیں:

• ‏zabbix: پرانے ہوسٹس مٹانے کے لیے Zabbix سرور سے جڑنا پڑتا ہے، اس لیے API تک رسائی درکار ہے۔ اس مقصد کے لیے ہم ایک مخصوص صارف بناتے ہیں، جس کی تفصیل یہاں درج ہوتی ہے۔
• ‏sns: ‏SNS کے ذریعے الارم بھیجنے کے لیے درکار ترتیب۔ یہاں IAM صارف کی تفصیل اور استعمال ہونے والے SNS ٹاپکس مقرر کیے جاتے ہیں۔
• ‏sqs: ‏AWS کے اسکیلنگ پیغامات سنبھالنے کی ترتیب۔ یہاں طے ہوتا ہے کہ قطار کتنے وقفے سے دیکھی جائے (delay_seconds) اور کون کون سی قطاریں جانچی جائیں۔

/var/log/zabbix-sqs-reader/zabbix-sqs-reader.log

اس فائل میں SQS سے پڑھے گئے آٹو اسکیلنگ واقعات درج ہوتے ہیں۔

ترتیب مکمل ہونے سے پہلے آپ کو پیغام Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. نظر آئے گا — یہ معمول کی بات ہے اور zabbix_ami.yml ترتیب دیتے ہی ختم ہو جاتا ہے۔

‏AMI کی اپڈیٹس # ماہر

چونکہ Zabbix نئی خصوصیات اور بہتریوں کے ساتھ نئے ورژن جاری کرتا رہتا ہے، اس لیے وقتاً فوقتاً ہماری AMI اپڈیٹ کرنا ہی بہتر ہے۔ بدقسمتی سے یہی نئی خصوصیات ڈیٹابیس اور اندرونی تبدیلیاں لاتی ہیں، جو موجودہ تنصیب اپڈیٹ کرتے وقت مسئلہ بن سکتی ہیں۔

ہماری Zabbix AMI اِن مسائل سے بچنے کا بہترین طریقہ ہے، کیونکہ ہم بڑے ورژنز کے درمیان ایسا راستہ دیتے ہیں جو عام طریقے سے تیز، آسان اور محفوظ ہے۔

اپڈیٹ کا خلاصہ

ہماری AMI کی اپڈیٹ کا عمل خاصا سادہ ہے:

• موجودہ ڈیٹابیس کا ڈمپ لینا۔
• تازہ ترین مستحکم ورژن کے ساتھ نئی AMI چلانا۔
• ڈیٹابیس ڈمپ نئے انسٹنس پر اپ لوڈ کرنا۔
• ہماری منتقلی کی اسکرپٹ چلانا۔

یوں موجودہ اور نیا — دونوں ورژن ساتھ ساتھ چلتے ہیں، اور سب کچھ درست چلنے کی تسلی کے لیے ضروری جانچ کے بعد ہی اُس انسٹنس کے EIP منتقل کیے جا سکتے ہیں یا کلائنٹس آہستہ آہستہ منتقل کیے جا سکتے ہیں۔

اپڈیٹ کا طریقہ

مرحلہ 1: ماخذ سرور کا بیک اپ

پہلا مرحلہ ماخذ سرور کی امیج بنانا ہے، تاکہ ڈیٹا حادثاتی طور پر ضائع نہ ہو۔ اس کے لیے AMI بنانے کی AWS ہدایات دیکھ سکتے ہیں۔

مرحلہ 2: ڈیٹابیس ڈمپ اور Zabbix ورژن

‏SSH سے انسٹنس میں داخل ہو کر root بنیں:

sudo /bin/su -

پھر ڈیٹابیس کو ایک فائل میں ڈمپ کریں:

mysqldump zabbix > zabbix_origin_database.sql

آخر میں بنی ہوئی فائل اپنی مشین پر ڈاؤن لوڈ کریں تاکہ بعد میں نئے سرور پر چڑھا سکیں۔ موجودہ Zabbix ورژن بھی نوٹ کر لیں: یہ ویب انٹرفیس میں نظر آتا ہے اور 4.0، 4.2، 4.4 یا 5.4 جیسا کوئی نمبر ہوگا۔

مرحلہ 3: نیا Zabbix انسٹنس چلائیں

اگلا مرحلہ AMI کے تازہ ترین مستحکم ورژن سے نیا Zabbix انسٹنس بنانا ہے، جو AWS Marketplace پر ہماری فروخت کنندہ پروفائل پر ملے گا۔ کم از کم ہماری Zabbix AMI کا ورژن 6.0 استعمال کرنا ہوگا۔

یہی نیا انسٹنس ہدف سرور ہوگا جہاں ہم ڈیٹا لے جائیں گے، اور اُس میں تازہ ترین ورژن پہلے سے نصب اور اپڈیٹ شدہ ہوتا ہے۔ چلنے کے بعد ماخذ سرور کا ڈیٹابیس ڈمپ اُس پر نقل کریں۔

مرحلہ 4: ڈیٹابیس اپڈیٹ کریں

موجودہ ڈیٹابیس ڈالنے، اُسے نئے ورژن پر لے جانے اور ضروری ترتیبات شامل کرنے کے لیے /opt/tools/bin/zabbix-ami-upgrade.sh اسکرپٹ استعمال کریں۔ اسے ubuntu صارف کے طور پر چلائیں اور اصل Zabbix ورژن اور ڈمپ فائل بتائیں۔ مثلاً Zabbix 4.0 سے منتقلی پر:

/opt/tools/bin/zabbix-ami-upgrade.sh 4.0 zabbix_origin_database.sql

یہ عمل ہر مرحلے کی اطلاع دیتا رہتا ہے، اور مکمل ہونے پر آپ نئے Zabbix سرور کے ساتھ کام جاری رکھ سکتے ہیں۔

مرحلہ 5: ویب انٹرفیس کھولیں

منتقلی مکمل ہونے پر ویب انٹرفیس کھول کر سرور کی مجموعی حالت دیکھی جا سکتی ہے۔ یاد رہے کہ وہی صارف اور پاس ورڈ استعمال کرنے ہوں گے جو پچھلے سرور پر تھے۔

مرحلہ 6: خصوصی ترتیبات منتقل کریں اور کلائنٹس درست کریں

ڈیٹابیس چلنے کے بعد سرور پر نصب کی گئی دیگر ترتیبات کا بھی خیال رکھیں، مثلاً:

• مانیٹرنگ اسکرپٹس۔
• اضافی سسٹم پیکیجز۔
• نصب شدہ SSL سرٹیفکیٹس۔

اُس انسٹنس کے لیے ترتیب دیا گیا EIP بھی منتقل کرنا ہوگا، تاکہ کلائنٹس میں کوئی تبدیلی نہ کرنی پڑے۔

اگر EIP استعمال نہیں ہو رہا تو شروع کرنے کا یہی بہترین موقع ہے؛ ورنہ تمام کلائنٹس میں نئے سرور کا IP بدلنا پڑے گا۔