عامل قاعدة بيانات AppDynamics: تنبيهات خاطئة حول التوفر

مسألة

أثناء إطار زمني محدد، أبلغ "عامل قاعدة بيانات AppDynamics" عن توفر منخفض لأدوات تجميع ABC و XYZ. أشارت مقاييس المراقبة إلى وجود انخفاض وفجوة في واجهة مستخدم وحدة التحكم. لم يكن هناك دليل على حالات قطع الاتصال بين مضيف البرنامج وقواعد البيانات أثناء هذه الفترة الزمنية، كما لم يتم إعادة تشغيل وكيل DB JVM.

البيئة

• التقنية: AppDynamics

• التقنية الفرعية: AppDynamics - عامل قاعدة البيانات

• قواعد البيانات المراقبة: Oracle 19.0.0.0

• أدوات تجميع البيانات المراقبة: ABC و XYZ

• لم يتم الإبلاغ عن أية تغييرات من جانب قاعدة البيانات أثناء نافذة الحدث

قرار

لمعالجة أحداث توفر قاعدة البيانات المنخفضة التي تم الكشف عنها بواسطة عامل قاعدة بيانات AppDynamics، تم تقديم الإرشادات حول هذه الخطوات وتنفيذها.

الخطوة 1: مراجعة سجلات عامل قاعدة البيانات لمعلمات كومة الذاكرة المؤقتة ل JVM وحالات انتهاء المهلة وتغييرات التكوين وعمليات إيقاف تشغيل مجمع البيانات

فحص سجلات "عامل قاعدة بيانات AppDynamics" لمعلمات كومة الذاكرة المؤقتة ل JVM، وحالات انتهاء مهلة الاتصال، وتغييرات التكوين، وعمليات إيقاف تشغيل مجمع السجلات. مقتطفات السجل ذات الصلة من هذه الحالة:

25 Jan 2026 22:47:00,394  INFO [DBAgent-4] ADBMonitorConfigResolver: - Outdated Configs: [ResolvedDBMonConfig {configName='XYZ', ... cpuCores=18, ...}]
25 Jan 2026 22:47:00,394  INFO [DBAgent-4] ADBMonitorConfigResolver: - new Configs: [ResolvedDBMonConfig {configName='XYZ', ... cpuCores=16, ...}]
25 Jan 2026 22:47:00,406  INFO [DBAgent-4] ADBCollector: - DB collector [XYZ] shut down!
25 Jan 2026 22:50:30,308  INFO [DBAgent-8] Agent: - JVM Args : -XX:+HeapDumpOnOutOfMemoryError | -XX:OnOutOfMemoryError=kill -9 %p | -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector | --add-opens=java.base/java.lang=ALL-UNNAMED | --add-opens=java.base/java.security=ALL-UNNAMED | -Ddbagent.name=dbagent |

الخطوة 2: إعادة تشغيل عامل قاعدة البيانات باستخدام وسيطات كومة الذاكرة المؤقتة ل JVM المعدلة

1. قم بإعادة تشغيل "عامل قاعدة بيانات AppDynamics"، مما يضمن تحديد وسيطات JVM المناسبة -XMS (الحد الأدنى لحجم كومة الذاكرة) و-Xmx (الحد الأقصى لحجم كومة الذاكرة) كما هي موثقة في متطلبات النظام الرسمية. يساعد هذا في معالجة قيود الذاكرة أو الموارد التي يمكن أن تساهم في إعادة تشغيل الوكيل الداخلي.

2. مثال أمر أن يعيد تشغيل الوكيل مع هذه الوسيطات (صياغة الأمر الفعلية يمكن أن تختلف حسب البيئة):

nohup java -Xms<size> -Xmx<size> -Ddbagent.name=DB_AGENT_NAME -jar db-agent.jar

استبدل <size>بالقيم المناسبة لبيئة المراقبة الخاصة بك، مع الرجوع إلى الوثائق الرسمية للحصول على التوصيات.

الخطوة 3: ارجع إلى الوثائق الرسمية لمتطلبات النظام

راجع متطلبات "نظام رؤية قاعدة البيانات" الرسمية لتحديد أحجام كومة الذاكرة المؤقتة الموصى بها وأفضل ممارسات التكوين لعامل قاعدة بيانات AppDynamics. قم بمحاذاة وسيطات JVM ومعلمات التكوين دائما مع هذه الإرشادات.

السبب

يرجع انخفاض التوافر الملحوظ والثغرات في القياسات الخاصة بجامعي ABC و XYZ إلى عدم وجود معلمات كومة الذاكرة المؤقتة ل JVM (-XMS و -XMX) وعمليات إيقاف العامل اللاحقة. يبدو أن السبب الجذري مرتبط بقيود الموارد (إعدادات حجم كومة الذاكرة المؤقتة) التي أدت إلى توقف عمليات الوكيل بشكل مؤقت.

المحتوى ذي الصلة

• الدعم الفني والتنزيلات من Cisco