Internal Errigal Collaboration Wiki

User Tools

Site Tools

Trace:
Writing /app/www/public/data/meta/ems/performance_and_config_sync_creation.meta failed
ems:performance_and_config_sync_creation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

ems:performance_and_config_sync_creation [2020/06/19 13:02] – created ehearneems:performance_and_config_sync_creation [2021/06/25 10:09] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== Performance and Configuration Sync Creation ======
 +
 +Author: Eoin Hearne.
 +
 +Date: 18-Jun-20.
 +
 +==== Sync Summary ====
 +
 +{{support:ems_sync_select.png}}
 +
 +Configuration and performance syncs can be performed manually through the EMS or on a schedule. Syncs can be started on on-air, show in monitor controllers that are set up to perform these syncs. These syncs use either SNMP or HTTP to gather information from a controller regarding the status of various settings for itself and any children connected to it.
 +
 +=== Configuration Syncs ===
 +
 +Configuration sync parameters can vary from location info to device name. These parameters can sometimes be editable and generally do not change, unless updated by our customers.
 +
 +=== Performance Syncs ===
 +
 +Performance sync parameters differ for config in that they generally are not editable. They display important information from the controller which can change, such as temperatures or power output. Determining which parameters belong to which sync is an important part of creating this process for new technologies.
 +
 +==== Steps for SNMP Sync Creation ====
 +
 +To begin creating and testing these scripts, you will first need to acquire a test system. This is usually given to us by our customer and often there will already be a test system available if alarm syncs have been created. There may also be an active device to test on.
 +
 +Ensure you have the latest version of the MIB used for this technology. This can be obtained from a customer, vendor or our server. If a MIB is provided that we do not have, it will need to be loaded onto our system or our current one may need an update.
 +
 +{{support:mib_root_oid.png}}
 +
 +Once the MIB in on your local machine, do an snmpwalk ([[https://www.poftut.com/snmpwalk-command-line-examples/|tutorial]]) on the system. If the system is closed to that customer network, perform the walk on a QA server and save the results to a file. The walk is performed on the root OID which can be found in the MIB, in the image, this is .1.3.6.1.4.1.331.1.
 +
 +Go through OIDs in MIB using MIB browser, which can be downloaded [[http://www.ireasoning.com/mibbrowser.shtml|here]]. Find OIDs that are relevant to either performance or config. 
 +
 +{{support:mib_oid_details.png  }}
 +Each OID will have a (1) name, (2) syntax, (3) access and (4) status. Make sure the OID status is current. The access can be read only or read/write. This can also be seen in the navigator tree, with read only having a leaf symbol and write having a pen.
 +
 +Configuration gives information about a controller or node, which can include software versions, IP addresses and other settings. These parameters don't usually change frequently and can be editable by the customer. Performance parameters, on the other hand, can change often by the system and report on important device information such as temperatures and power output.
 +
 +Some OIDs return multiple results. These results are either in relation to the controllers children or reference a series of other equipment, such as connected power supply units. For the children, extra numbers are appended onto the original OID to allow the system to reference those elements specifically. We are required to distinguish what the technologies method is for adding these numbers or suffix. As an example, a recent Andrews ION-E script was added, and the suffix was made up of ASCII codes for each letter of the nodes name, with the length of the name at the start.
 +
 +^ Node Name      ^  Characters          ^^^^^^^^^^^
 +| 1.0.OPT.L5|name.size()|1|.|0|.|O|P|T|.|L|5|
 +^ OID Suffix      ^  ASCII Code Mapping          ^^^^^^^^^^^
 +|.10.49.46.48.46.79.80.84.46.76.53|10|49|46|48|46|79|80|84|46|76|53|
 +
 +In the above example, the original OID is appended first with the names number of characters, then each characters ASCII code, to make up the full OID. Unfortunately, not all technologies follow this convention.
 +
 +This logic will then need to be added to the reverse translation script in the technology table in order for the sync scripts to map the returned values to the corresponding child elements.
 +
 +For the syncs to function correctly, there is a checklist of scripts and database table entries that will be required.
 +
 +==== Scripts =====
 +
 +=== Config/perform sync path ===
 +
 +Used to generate the paths where the parameters will be found. These will be a list of the discoveryoid in the database for SNMP or URLs for HTTP.
 +
 +=== Retrieve config params/performance value ===
 +For SNMP, the DefaultSnmp scripts can be used. For HTTP, custom scripts will need to be created to retrieve the values from the device.
 +
 +=== Config/perform sync parser ===
 +Used to parse the results retrieved.
 +
 +==== Table entries ====
 +
 +If they do not already exist, entries will need to be added into the following tables:
 +
 +=== technology ====
 +
 +  *  name - used in other scripts, such as the discovery, to assign the correct technology to new network elements.
 +  *  reverse_translation - mentioned above. Important for determining child OIDs.
 +
 +Multiple MIBs can be added in the technology controller, if required.
 +
 +=== config_sync_setting ===
 +
 +Wiki link for [[http://wiki.err/doku.php?id=ems:config_sync_setting&s[]=performance&s[]=sync|config sync setting]].
 +
 +  *  retrieve_path_script_id - ID of the config sync path script.
 +  *  config_get_type - either SNMP_SUBTREE or HTTP_GET.
 +  *  config_mib_id - if a specific MIB is used which is not in the technology table.
 +  *  config_value_parser_script_id - ID of the config sync parser script.
 +
 +=== performance_discovery_setting ===
 +
 +Wiki link for [[http://wiki.err/doku.php?id=ems:performance_discovery_setting&s[]=performance&s[]=sync|performace sync setting]].
 +
 +  *  retrieve_path_script_id - ID of the perform sync path script.
 +  *  perform_get_type - either SNMP_SUBTREE or HTTP_GET.
 +  *  perform_mib_id - if a specific MIB is used which is not in the technology table.
 +  *  perform_value_parser_script_id - ID of the perform sync parser script.
 +
 +=== remote_discovery_configuration ===
 +
 +  *  name - technology name.
 +  *  update_config_script_id - ID of update script, if required.
 +  *  retrieve_config_params_script_id - either the ID of the newly created config retrieval script or the SnmpDefault.
 +  *  retrieve_performance_values_script_id - either the ID of the newly created perform retrieval script or the SnmpDefault.
 +
 +=== discoveryoid ===
 +
 +Used for SNMP OIDs, this is used by the path script to retrieve all the config or performance paths for syncs
 +
 +  *  actual_name - the name found in the MIB to describe the parameter e.g. fwuRmtType
 +  *  category - either CONFIGURATION or STAT for performance.
 +  *  is_active - activate or deactivate an OID.
 +  *  is_primary - is a core parameter or an additional.
 +  *  is_writable - if it is editable. Information can be obtained from the MIB.
 +  *  oid - the OID path found in the MIB.
 +  *  readable_name - used to display on the EMS widgets e.g. Remote Type.
 +  *  suffix_addition_max - used to iterate when multiple values are returned that don't relate to remotes e.g. Host DART Min Input Pwr1, which isn't related to a child element, rather another piece of equipment attached to the unit.
 +  *  technology_id - important for ensuring the OID relates to the correct entry in the technology table.
 +
 +=== snmp_hardware_type ===
 +
 +Used to allow a network element's assigned hardware type to be used for SNMP per technology
 +
 +  *  hw_type - can be ALL_FOR_TECHNOLOGY or specific type e.g. HUB
 +  *  technology_id
 +  *  hw_type_id - relates to the hardware_type table. Not required if hw_type is ALL_FOR_TECHNOLOGY
 +
 +=== discoveryoid_hardware_type ===
 +
 +Acts as a bridge table between discoveryoid and hardware_type. It can determine whether an OID will be used on the hub or node.
 +
 +  *  discoveryoid_hw_types_id - the ID of the discoveryoid entry
 +  *  hardware_type_id - ID of hardware type
 +
 +=== threshold_collection ===
 +
 +  *  name - technology name
 +
 +=== simple_threshold ===
 +
 +These thresholds are used on the performance widget to highlight which values are above or below the threshold. Values within are highlighted green while values that go outside the range are changed to red. The thresholds only support numerical values but they will still need to be added for other parameters.
 +
 +  *  breach_value - the maximum allowed value. This can be either an integer or floating point number, positive or negative.
 +  *  name - based on the discoveryoid readable_name
 +  *  operator - determines how the value will be compared to the breach_value. Options are LESS_THAN, EQUAL_TO, GREATER_THAN.
 +  *  threshold_collection_id - references the threshold_collection table.
 +  *  find_strategy - determines how to find the name. The name can be a section of the readable_name, to allow multiple OIDs to use the same threshold. Options are SEARCH_STRING_STARTS_WITH, COMPLETE_MATCH, SEARCH_STRING_CONTAINS, SEARCH_STRING_ENDS_WITH.
 +
 +==== Database checks ====
 +
 +Once the scripts are created and all database entries are complete, you can check that all the relevant references are updated. These include:
 +
 +  *  network_element.remote_element_type - options are SNMP_DEFAULT or GROOVY_SCRIPT.
 +  *  network_element.hardware_type - make sure the test element has a hardware assigned.
 +  *  network_element.assigned_technology - make sure the correct technology is assigned.
 +  *  network_element.config_sync_setting_id - add the created config_sync_setting ID.
 +  *  network_element.performance_discovery_setting_id - add the created performance_discovery_setting ID.
 +  *  network_elememt.non_snmp_performance_thresholds_id - add the threshold_collection id here.
 +  *  The correct MIBs are in the technology controller.
 +
 +==== Widgets ====
 +
 +{{support:config_widget.png?900X400}}{{support:perform_widget.png?}}
 +
 +There is a widget in the EMS for both performance and configuration. They are both similar but retrieve different parameters based on the settings added to the database and the scripts that are ran during the refresh. You can see in the performance widget image a good example of an OID that retrieves multiple values. Because the discoveryoid.suffix_addition_max is set to 8, the application will list each one based on the index 1 - 8. In the example, the controller has 5 DARTs connected in slots 1-4 and 8.
 +
 +==== Testing ====
 +
 +Once all the correct elements are present, and the scripts perform as expected, you can run the syncs from the EMS. Tail the SnmpManager logs to see if you get any errors during the process. Usually, if any errors occurs, it's because one of the references in the database is missing. The logs will give a good indication of what is going wrong. The discoveryoids will only be retrieved if they are set to is_active, the network_element.hw_type na discovery_hardware_type are not null and they match. The retrieval scripts are also a good way to check if you are getting the correct parameters back.
  

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki