Showing results for 
Search instead for 
Did you mean: 

What are the main processes within Prognosis for UC monitoring?


What are the main processes within Prognosis for UC monitoring?

What are the main processes of Prognosis for UC and their functions?


Re: What are the main processes within Prognosis for UC monitoring?

What are the main processes of Prognosis for UC and their functions?

ADI stands for Application Development Interface and Extractor Collector (configured via EXTRACTOR configuration). It is significant in that it supplies user records which are defined in userdefs.


AUTOAN stands for Auto Analyst. It is the process that interprets Threshold conditions and Analyst rules. There will be one process for each active Analyst rule and Threshold that you can see from the Node Navigator.


This is the set of Avaya collectors responsible for connecting to the different types of AVAYA PBXs in order to collect information using SAT commands. Each of these collectors is responsible for monitoring the PBX specified in the various
AVAYA_<XXX> static configurations.


AVCOL – stands for Availability Collector. It collects availability data such as percentage up/down for entities configured in the AVAILABILITY configuration.


IRCMDSRV – stands for command server. It is the process that handles command requests from the UI or from services like the Analyst. The command output is available as the PrognosisCommandOutput (AUTOOUT). This process supplies the specific data to IRGFSRV. IRGFSRV is the process that actually handles the request for this record.


DBASE – stands for database. It is a process that handles both data collection and replay. One such process will exist for each active database collection. Other dynamic processes will exist during database replay.


DLLCOL – stands for dll Collector. It is the Collector shell which contains many collection dlls. It handles one collection per dll. The list of dlls which comprise such collections is specified in irdllcol1.ini. IRDLLCOL1 defaults to run at normal priority which collects critical high level data regarding CallManager.


This is a second copy of DLLCOL. This process is similar to IRDLLCOL1 except that it is defaulted to run at a lower priority. A full list of records that IRDLLCOL2 Collector supplies can be found in the IRDLLCOL2.ini file.


DSPSRV – stands for Dispatch Server. It is responsible for sending email and pager alerts.


GFSRV – stands for Generic File Server. It maintains various persistence and work files on the system (F00* files). It is responsible for retrieving information out of the F00* files and supplies record such as AUTOOUT, DISPMSG, and DISPLOG. Note that these are records that show information on PROGNOSIS actions or alerts.


NETMON – stands for Network Monitor. It supplies network related records (MpSubnet*). It is also responsible for monitoring packets coming in and out of CallManagers and provides raw data regarding real time calls.


NETRTR – stands for Network Router. It is the communication hub. All UI requests and data responses to and from processes plus inter-system communication take place via IRNETRTR.


This is the Nortel collectors responsible for connecting to the Nortel PBXs in order to collect information using CLI commands, SNMP query and traps, etc. It is responsible for monitoring the PBX specified in the NORTEL_PBX static configurations.


PERL – stands for perl interpreter. A lot of the automated script in the standard product is written in perl. This is a specific version of perl that is compiled and distributed with the software to ensure that the version of perl required matches up
with the distributed script.


PROMGS – stands for Process Manager service. It is the process responsible for ensuring all other required processes are kept running.


This executable is responsible for collecting information for a single Cisco v5+ cluster. There will be one executable per Cisco v5+ cluster. The name of the executable will match with the name of the Cisco v5+ cluster being monitored.


RTCPCOL – stands for RTCP collector. It is responsible for analyzing the RTCP packets from the AVAYA endpoints in order to supply data regarding voice streams and network hops.


Retrieves data from Prognosis on request from the IIS Web UI dashboards

Webinar: The Journey to Microsoft Teams - Readiness Phase (part 2)

Having looked at the planning phase in session one of this series, we will turn our focus to the readiness phase. The all important technical capabilities assessment, ensuring the network, endpoints and users are adequately prepared for the move.

Hear first hand from IR's Global Head of Information Systems and Technology, Jason Schwendinger, on how he has been tackling these issues.

Join webinar