Classic Monitor Configuration Migration Design

Background ¶

MCT has various of monitors to cover lots of customer use cases, there are now two types of monitors:

1. new monitors, AKA Plugins
2. classic monitors.

Plugins are high scalable and easy to maintain, on the contrary, classic monitors has many hard coded logic on each layer, we suffered a lot even on each slight change. Now MCT 3.0 is on the way developing, those legacy logics should be taken into new framework, they must be eliminated now.

Classic Monitors List ¶

Migration Plan ¶

1. Map all hard coded field into xml, and add to mct_zone_template and mct_server_template ¶

According to hard coded logic in infrastructure.js (L1667-L2020) and infrastructure.js (L3745-L4233)

Meeting Zone example:

<zone-template>
    <zoneField1 name='Primary storage location' type='text' desc='Example: 192.168.0.1:/nbr_root' check-regular=''></zoneField1>
    <zoneField2 name='Backup storage location' type='text' desc='Example: 192.168.0.2:/nbr_root' check-regular=''></zoneField2>
    <zoneField3 name='Verify Meeting' type='checkbox' desc='Checked means do verify meeting' checkitems=':0' check-regular=''>0</zoneField3>
    <zoneField4 name='Tomcat J2ee App Server VIP' type='text' desc='Example: nebulaab.webex.com;nebulaac.webex.com' check-regular=''></zoneField4>
    <parameter name='Web Domain' key='webDomain' type='text' desc='Example: abwd' check-regular=''></parameter>
    <parameter name='Verification Mode' type='select' key='verifyMode' checkitems='SMAC:SMAC;CI:CI' desc='SMAC: Key Management Service' check-regular=''>SMAC</    parameter>
    <parameter name='CI Scope' key='CIScope' type='text' show-dependency="verifyMode:CI"></parameter>
    <parameter name='CI Env' key='CIEnv4MeetingZone' type='select' show-dependency="verifyMode:CI" checkitems='IL5:IL5'>IL5</parameter>
</zone-template>

Note: seem zone field and server field do not support type checkbox, should add this support.

2. Case by case handle field in Java code (add switch, the switch could be passed through api parameter) ¶

List Zone / Check template ¶

Set all the monitor types to using plugin render way, and the zone / check parameters will be listed in new zone / check request, it should be able to auto rendered.

List zone api: /mpi/plugin-setting/zone/zone-type/{zoneType} List check api: /mpi/plugin-setting/servers/zone-type/{checkType}

Add Zone / Check ¶

Payload of New field vs original field, take meeting zone as an example:

// classic
{
    "domainType": "0",
    "domainId": 0,
    "domainName": "",
    "zoneType": "0",
    "zoneName": "meeting zone",
    "keyZone": 0,
    "zoneField1": "Primary storage location",
    "zoneField2": "Backup storage location",
    "zoneField3": "1",
    "zoneField4": "Tomcat J2ee App Server VIP",
    "zoneField6": "9999",
    "testLocations": "",
    "webDomain": "Web Domain",
    "verifyMode": "SMAC",
    "CIScope": "",
    "CIEnv4MeetingZone": "IL5"
}
// new
{
    "domainType": "0",
    "domainId": 0,
    "domainName": "",
    "zoneType": "0",
    "zoneName": "meeting zone",
    "keyZone": 0,
    "zoneField1": "Primary storage location",
    "zoneField2": "Backup storage location",
    "zoneField3": "1",
    "zoneField4": "Tomcat J2ee App Server VIP",
    "zoneField6": "9999",
    "testLocations": "",
    "zoneField1Type": "text",
    "zoneField2Type": "text",
    "zoneField3Type": "checkbox",
    "zoneField4Type": "text",
    "parameters": [
        {
            "key": "webDomain",
            "type": "text",
            "value": "Web Domain"
        },
        {
            "key": "verifyMode",
            "type": "select",
            "value": "SMAC"
        },
        {
            "key": "CIScope",
            "type": "text",
            "value": ""
        },
        {
            "key": "CIEnv4MeetingZone",
            "type": "text",
            "value": "IL5"
        }
    ]
}

Here need to special handle it in mct-central-api code (add switch), to make sure there are finally only 6 zone and check fields.

in this case, webDomain, verifyMode, CIScope and CIEnv4MeetingZone will be merged into zoneField5.

Update Zone / Check ¶

Update request part is similar with Add Zone / Check.

For listing parameter part, should special handle it in mct-central-api code (add switch), e.g. extract zone / server field to plugin parameter field.

Get Zone / Check parameters ¶

No change needed, since all fields added into DB are same as before.

Get zone / check parameter api: /mpi/zone/{zoneId}/server/{checkId}

3. Handle special monitor cases ¶

For default value and requirement property, it can be defined in xml; for field dependency, can migrate to plugin supported function show-dependency; for those unsupported concatenation, need to handle separately, for example, we need to add special handle code for getting URL Template.

Part of logic need to specially deal with:

• method updateSelectTemplate()
• method onUpdateMonitorURL()
• method deleteUrl()
• method initJ2eeWebDomainSelect()
• method onServerBalanceClicked()
• method initJ2eeAppPort()
• method urlCheck()
• method _initServerTemplate()
• method urlParamsCheck()
• method urlSplice()
• method onServerChangeGenericTemp()
• method updateSelectTemplate()
• method updateSelectCountry()

Part of concatenation can be migrated to show-dependency:

• method displayItemByVerifyMode()
• Tel Zone (zone type 4) cascading logic
• method displayItemByCIEnv4TPGW()
• method onServerClickCheckbox()
• method onServerAuthenChange()
• method onServerChangeUrlWatchMethod()

Conclusion ¶

Config change needed: organize zone / server template xml.

Code change needed:

1. Page JS, add all field type support for zone / server field.
2. Page JS, set parameter render type to plugin for all monitors.
3. Page JS, specially deal with some particular cases.
4. mct-central-api, special handle field data when adding zone / check.
5. mct-central-api, special handle field data when getting zone / check.