Kafka क्लायंट अजूनही तयार किंवा वापरू शकत नसतानाही bootstrap कनेक्शन यशस्वी होऊ शकते. Bootstrap सर्व्हर क्लायंटला क्लस्टर शोधण्यास मदत करतात; ते क्लायंट जोडणारे एकमेव एंडपॉइंट असतीलच असे नाही.

Broker मेटाडेटामध्ये पुढील कनेक्शनसाठी वापरले जाणारे पत्ते असतात. जर ती नावे किंवा पोर्ट इच्छित प्रॉक्सी मार्गाने पोहोचण्यायोग्य नसतील, तर पहिले यशस्वी कनेक्शन उर्वरित काम सोडवत नाही.

जाहीर केलेले एंडपॉइंट वाचा

Bootstrap पत्त्याची क्लायंटला प्रत्यक्षात मिळणाऱ्या broker पत्त्यांशी तुलना करा. सार्वजनिक bootstrap उपनाव खासगी जाहीर केलेल्या नावांकडे घेऊन जाऊ शकते, आणि एक स्थानिक पोर्ट पुढे पाठवल्याने मेटाडेटामधील प्रत्येक पत्ता आपोआप पुन्हा लिहिला जात नाही.

क्लायंट अंमलबजावणी कोणत्या प्रॉक्सी मार्गाला समर्थन देते तेही ओळखा. Java सिस्टम SOCKS गुणधर्म ही हमी नाही की लायब्ररीचे NIO-आधारित ट्रान्सपोर्ट JDK Socket प्रॉक्सी यंत्रणा वापरते. प्रत्येक Java सॉकेट समान सेटिंग पाळते असे गृहीत धरण्याऐवजी प्रत्यक्ष Kafka क्लायंट आणि नेटवर्क एकत्रीकरण तपासा.

प्रॉक्सी-जागरूक क्लायंटला संबंधित broker एंडपॉइंटपर्यंत परवानगी असलेला मार्ग आवश्यक आहे. नेटवर्क-स्तरीय व्यवस्थेला संबंधित पोहोच आणि नाव निराकरण आवश्यक आहे. हे वेगवेगळे आराखडे आहेत, आणि प्रॉक्सीला bootstrap सर्व्हर म्हणून सूचीबद्ध केल्याने कोणतेही मिळत नाही.

सुरक्षा प्रोटोकॉल आणि प्रमाणीकरण सेटिंग्ज वेगळ्या ठेवा. प्रॉक्सी TCP मार्ग स्थापित करू शकतो, पण TLS ओळख, SASL प्रमाणीकरण किंवा broker अधिकृतता अजूनही अयशस्वी होऊ शकते.

निदानासाठी, कोणते एंडपॉइंट अयशस्वी झाले आणि ते स्थिर संरचनेतून आले की परत मिळालेल्या मेटाडेटामधून आले हे नोंदवा. तो फरक आधीच पोहोचण्यायोग्य असलेले एंडपॉइंट वारंवार बदलण्यापेक्षा समस्या खूप अधिक मर्यादित करतो.

संबंधित लेख