క్లయింట్ కోసం పరిష్కారాన్ని రూపొందించేటప్పుడు, నేను అందంగా మరియు సాధారణ Zabbix కార్యాచరణతో పరిష్కరించాలనుకున్న 2 పనులు తలెత్తాయి.
టాస్క్ 1. Mikrotik రూటర్లలో ప్రస్తుత ఫర్మ్వేర్ వెర్షన్ను ట్రాక్ చేస్తోంది.
పని సులభంగా పరిష్కరించబడుతుంది - HTTP టెంప్లేట్కు ఏజెంట్ని జోడించడం ద్వారా. ఏజెంట్ Mikrotik వెబ్సైట్ నుండి ప్రస్తుత సంస్కరణను స్వీకరిస్తారు మరియు ట్రిగ్గర్ ప్రస్తుత సంస్కరణను ప్రస్తుత వెర్షన్తో సరిపోల్చుతుంది మరియు వ్యత్యాసం ఉన్నట్లయితే హెచ్చరికను జారీ చేస్తుంది.
మీకు 10 రౌటర్లు ఉన్నప్పుడు, అటువంటి అల్గోరిథం క్లిష్టమైనది కాదు, కానీ 3000 రౌటర్లతో ఏమి చేయాలి? సర్వర్కు 3000 అభ్యర్థనలను పంపాలా? అయితే, అటువంటి పథకం పని చేస్తుంది, కానీ 3000 అభ్యర్థనల ఆలోచన నాకు సరిపోలేదు, నేను మరొక పరిష్కారాన్ని కనుగొనాలనుకుంటున్నాను. అదనంగా, అటువంటి అల్గారిథమ్లో ఇప్పటికీ ఒక లోపం ఉంది: DoS దాడి కోసం ఒక IP నుండి అటువంటి అనేక అభ్యర్థనలను మరొక వైపు లెక్కించవచ్చు, వారు దానిని నిషేధించవచ్చు.
టాస్క్ 2. వివిధ HTTP ఏజెంట్లలో అధికార సెషన్ను ఉపయోగించడం.
ఏజెంట్ HTTP ద్వారా "మూసివేయబడిన" పేజీల నుండి సమాచారాన్ని స్వీకరించవలసి వచ్చినప్పుడు, అధికార కుక్కీ అవసరం. దీన్ని చేయడానికి, సాధారణంగా "లాగిన్ / పాస్వర్డ్" జత మరియు కుకీలో సెషన్ IDని సెట్ చేయడంతో ప్రామాణిక అధికార ఫారమ్ ఉంటుంది.
కానీ ఒక సమస్య ఉంది, హెడర్లో ఈ విలువను భర్తీ చేయడానికి ఒక HTTP ఏజెంట్ అంశం నుండి మరొక అంశం యొక్క డేటాను యాక్సెస్ చేయడం అసాధ్యం.
"వెబ్ స్క్రిప్ట్" కూడా ఉంది, దీనికి మరొక పరిమితి ఉంది, ఇది విశ్లేషణ మరియు మరింత ఆదా కోసం కంటెంట్ను పొందడానికి మిమ్మల్ని అనుమతించదు. మీరు పేజీలలో అవసరమైన వేరియబుల్స్ ఉనికిని మాత్రమే తనిఖీ చేయవచ్చు లేదా వెబ్ స్క్రిప్ట్ దశల మధ్య గతంలో స్వీకరించిన వేరియబుల్లను పాస్ చేయవచ్చు.
ఈ పనుల గురించి కొంచెం ఆలోచించిన తర్వాత, మానిటరింగ్ సిస్టమ్లోని ఏదైనా భాగంలో ఖచ్చితంగా కనిపించే మాక్రోలను ఉపయోగించాలని నేను నిర్ణయించుకున్నాను: టెంప్లేట్లు, హోస్ట్లు, ట్రిగ్గర్లు లేదా ఐటెమ్లలో. మరియు మీరు వెబ్ ఇంటర్ఫేస్ API ద్వారా మాక్రోలను నవీకరించవచ్చు.
Zabbix మంచి మరియు వివరణాత్మక API డాక్యుమెంటేషన్ను కలిగి ఉంది. api ద్వారా డేటా మార్పిడి కోసం, Json డేటా ఫార్మాట్ ఉపయోగించబడుతుంది. లో వివరాలు చూడవచ్చు అధికారిక డాక్యుమెంటేషన్.
మనకు అవసరమైన డేటాను పొందడం మరియు వాటిని మాక్రోలో రికార్డ్ చేయడం కోసం చర్యల క్రమం క్రింది రేఖాచిత్రంలో చూపబడింది.
1 అడుగు
మొదటి దశ ఒకే చర్య లేదా బహుళ చర్యలను కలిగి ఉంటుంది. అన్ని ప్రధాన తర్కం మొదటి దశలలో వేయబడింది మరియు చివరి 3 దశలు ప్రధానమైనవి.
నా ఉదాహరణలో, మొదటి పని కోసం PBXలో అధికార కుక్కీలను పొందడం మొదటి దశ. రెండవ పని కోసం, నేను Mikrotik ఫర్మ్వేర్ యొక్క ప్రస్తుత సంస్కరణ సంఖ్యను పొందాను.
అందుబాటులో ఉన్న తాజా ఫర్మ్వేర్ సంస్కరణను స్వీకరించినప్పుడు ఈ చిరునామాలను Mikrotik పరికరాలు స్వయంగా యాక్సెస్ చేస్తాయి.
మొదటి దశ ప్రతి కేసుకు పూర్తిగా వ్యక్తిగతమైనది మరియు దాని పని యొక్క తర్కం భిన్నంగా ఉండవచ్చు. ఇది మీ పని మీద ఆధారపడి ఉంటుంది.
వెబ్ స్క్రిప్ట్లతో పని చేస్తున్నప్పుడు, మీకు ఏ ప్రతిస్పందన పద్ధతి అవసరమో ట్రాక్ చేయండి. శీర్షికలు HTTP ప్రతిస్పందన లేదా స్వీయ тело శీర్షికలు లేకుండా ప్రతిస్పందన?
అధికార కుక్కీలు అవసరమైతే, ప్రతిస్పందన పద్ధతిని సెట్ చేయండి శీర్షికలు ఆస్టరిస్క్ విషయంలో వలె.
మైక్రోటిక్ సర్వర్ ప్రతిస్పందన విషయంలో మీకు డేటా అవసరమైతే, ఉంచండి శరీరం శీర్షికలు లేకుండా ప్రతిస్పందన.
jsonrpc అనేది ఉపయోగించబడుతున్న JSON-RPC ప్రోటోకాల్ యొక్క సంస్కరణ;
Zabbix JSON-RPC వెర్షన్ 2.0ని అమలు చేస్తుంది;
పద్ధతి - అని పిలువబడే పద్ధతి;
పారామితులు - పద్ధతి ద్వారా ఆమోదించబడిన పారామితులు;
id అనేది ఏకపక్ష అభ్యర్థన ఐడెంటిఫైయర్;
auth - వినియోగదారు ప్రమాణీకరణ కీ; మన దగ్గర ఇంకా అది లేదు కాబట్టి, దానిని శూన్యంగా సెట్ చేద్దాం.
APIతో పని చేయడానికి, నేను పరిమిత హక్కులతో ప్రత్యేక ఖాతాను సృష్టించాను. ముందుగా, మీకు అవసరం లేని చోట యాక్సెస్ ఇవ్వాల్సిన అవసరం లేదు. మరియు రెండవది, వెర్షన్ 5.0 కి ముందు, మాక్రో ద్వారా సెట్ చేయబడిన పాస్వర్డ్ చదవబడుతుంది. దీని ప్రకారం, మీరు Zabbix అడ్మినిస్ట్రేటర్ పాస్వర్డ్ను ఉపయోగిస్తే, అడ్మిన్ ఖాతాను దొంగిలించడం సులభం.
థర్డ్-పార్టీ స్క్రిప్ట్ల ద్వారా APIతో పని చేస్తున్నప్పుడు మరియు పక్కపక్కన ఆధారాలను నిల్వ చేస్తున్నప్పుడు ఇది ప్రత్యేకంగా వర్తిస్తుంది.
వెర్షన్ 5.0 నుండి మాక్రోలో సేవ్ చేసిన పాస్వర్డ్ను దాచడానికి ఒక ఎంపిక ఉంది.
API ద్వారా డేటాను అప్డేట్ చేయడానికి ప్రత్యేక ఖాతాను సృష్టించేటప్పుడు, మీకు అవసరమైన డేటా వెబ్ ఇంటర్ఫేస్ ద్వారా అందుబాటులో ఉందో లేదో మరియు దానిని నవీకరించడం సాధ్యమేనా అని తనిఖీ చేయండి. నేను తనిఖీ చేయలేదు, ఆపై నాకు అవసరమైన స్థూల APIలో ఎందుకు కనిపించడం లేదని నేను చాలా కాలంగా అర్థం చేసుకోలేకపోయాను.
మేము APIలో అధికారాన్ని పొందిన తర్వాత, మేము మాక్రోల జాబితాను పొందడానికి కొనసాగుతాము.
3 అడుగు
హోస్ట్ మాక్రోని పేరుతో అప్డేట్ చేయడానికి API మిమ్మల్ని అనుమతించదు, మీరు ముందుగా మాక్రో IDని పొందాలి. అంతేకాకుండా, నిర్దిష్ట హోస్ట్ కోసం మాక్రోల జాబితాను పొందడానికి, మీరు ఈ హోస్ట్ యొక్క IDని తెలుసుకోవాలి మరియు ఇది అదనపు అభ్యర్థన. డిఫాల్ట్ మాక్రో ఉపయోగించండి {హోస్ట్ ID} అభ్యర్థనలో అనుమతించబడదు. నేను పరిమితిని ఇలా దాటవేయాలని నిర్ణయించుకున్నాను:
నేను ఈ హోస్ట్ IDతో స్థానిక మాక్రోని సృష్టించాను. వెబ్ ఇంటర్ఫేస్ నుండి హోస్ట్ IDని కనుగొనడం చాలా సులభం.
ఇచ్చిన హోస్ట్లోని అన్ని మాక్రోల జాబితాతో ప్రతిస్పందనను నమూనా ద్వారా ఫిల్టర్ చేయవచ్చు:
ఈ విధంగా, మనకు అవసరమైన స్థూల IDని ఎక్కడ పొందుతాము MIKROTIK_VERSION అనేది మనం వెతుకుతున్న మాక్రో పేరు. నా విషయంలో, మాక్రో శోధించబడింది MIKROTIK_VERSIONఇది హోస్ట్కు కేటాయించబడింది.
{mikrotik_version} మొదటి దశలో పొందిన విలువ. నా ఉదాహరణలో, ప్రస్తుత మైక్రోటిక్ ఫర్మ్వేర్ వెర్షన్ {hostmacroid} - విలువ మూడవ దశలో పొందబడింది - మేము అప్డేట్ చేస్తున్న మాక్రో యొక్క id.
కనుగొన్న
ప్రామాణిక కార్యాచరణతో సమస్యను పరిష్కరించే విధానం చాలా క్లిష్టంగా మరియు పొడవుగా ఉంటుంది. ప్రత్యేకించి మీకు ప్రోగ్రామింగ్ తెలిసి స్క్రిప్ట్లో అవసరమైన లాజిక్ను త్వరగా జోడించవచ్చు.
ఈ విధానం యొక్క స్పష్టమైన ప్రయోజనం వివిధ సర్వర్ల మధ్య పరిష్కారం యొక్క "పోర్టబిలిటీ".
నాకు వ్యక్తిగతంగా, HTTP ఏజెంట్ మరొక అంశం యొక్క డేటాను యాక్సెస్ చేయలేకపోవడం మరియు అభ్యర్థన అంశం లేదా శీర్షికలలో వాటిని ప్రత్యామ్నాయం చేయడం వింతగా ఉంది [ ZBXNEXT-5993].