קריאת JMX דרך פרוקסי HTTP בעזרת Jolokia

אם פריסת Java כבר חושפת נקודת קצה Jolokia מורשית, לקוח ניטור יכול לקרוא מאפייני JMX דרך פרוקסי HTTP קדמי רגיל. הלקוח מדבר HTTP עם Jolokia, שמבצעת את פעולת ה-JMX בצד האפליקציה.

monitor → HTTP proxy → HTTPS Jolokia endpoint → MBean

המסלול הזה דורש נקודת קצה לניהול שתומכת ב-HTTP. הפניית לקוח JMX מקורי ללא שינוי אל פרוקסי הרשת אינה יוצרת אחת כזו.

לדוגמה, קריאה של שימוש ה-heap של ה-JVM יכולה להיות מבוטאת כבקשת POST:

curl --proxy http://proxy.example.net:8080 \
  --header 'Content-Type: application/json' \
  --data '{"type":"read","mbean":"java.lang:type=Memory","attribute":"HeapMemoryUsage","path":"used"}' \
  https://monitor.example.net/jolokia/

נקודת הקצה והפרוקסי הם מצייני מקום. זה משתמש בפעולת קריאה; שיטת ה-HTTP‏ POST נושאת את בקשת ה-JSON של Jolokia ולא מרמזת על כתיבת JMX. Jolokia תומכת גם בבקשות GET לפעולות פשוטות, בעוד ש-JSON POST נמנע מחלק מהבריחה של URL הנדרשת לשמות MBean מורכבים.

עבור נקודת קצה לניהול ב-HTTPS, הפרוקסי הקדמי צריך לאפשר את יעד המנהרה הרלוונטי. TLS אמור עדיין לאמת את monitor.example.net. שם המארח והתעודה של הפרוקסי עצמו, אם חיבור הפרוקסי עצמו משתמש ב-TLS, מתארים קפיצה נפרדת.

הפרידו בין שתי החלטות האימות. אפשרויות אימות הפרוקסי של curl מספקות חשבון פרוקסי. אימות נקודת הקצה מספק את זהות הניהול, והמדיניות של Jolokia קובעת לאילו MBeans ופעולות יש גישה. הרשאה להשתמש בפרוקסי הקדמי אינה הרשאה לנהל את ה-JVM.

גם לתגובה שני רבדים: מצב ההובלה של HTTP ותוצאת פעולת ה-JSON של Jolokia. בדקו את status ו-value המוחזרים במקום לקבל כל גוף כמדד מוצלח. שגיאות פרוקסי, כשלי אימות בנקודת הקצה ו-MBeans חסרים דורשים שינויים שונים.

אם הפריסה חושפת רק מחבר JMX מקורי, בחרו מסלול תואם לאותו מחבר או הסדירו נקודת קצה לניהול HTTP מאושרת. העברה מקומית ב-SSH היא תכנון הובלה אחר, אך היא נשארת חיבור לשירות המקורי; היא אינה משנה את הפרוטוקול שלו ל-API ה-HTTP של Jolokia.