قراءة JMX عبر وكيل HTTP باستخدام Jolokia

إذا كان نشر Java يعرض بالفعل نقطة نهاية Jolokia مصرَّحاً بها، فيمكن لعميل المراقبة قراءة سمات JMX عبر وكيل HTTP أمامي عادي. يتحدث العميل HTTP إلى Jolokia، التي تنفذ عملية JMX على جانب التطبيق.

monitor → HTTP proxy → HTTPS Jolokia endpoint → MBean

يحتاج هذا المسار إلى نقطة نهاية إدارة تدعم HTTP. وتوجيه عميل JMX أصلي دون تغيير إلى وكيل الويب لا ينشئ واحدة.

على سبيل المثال، يمكن التعبير عن قراءة استخدام الكومة في 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 تصميم نقل آخر، لكنها تبقى اتصالاً بالخدمة الأصلية؛ ولا تحول بروتوكولها إلى واجهة HTTP API الخاصة بـJolokia.