Application / Data Propagation Overview

1. Account manually entered by GWN staff.

2. Account added to dvpointp database.

3. sndNetWatchData, which is controlled as a cron job, runs at 3,8,13,18,23,28,33,38,43,48,53, and 58 past the hour. sndNetWatchData looks at the database for changes in monitoring requests. The daemon process locates the changes, packages, encrypts (more like an encoding) the data, and passes it on to the nodes via sendmail.

4. sendmail passes the new data to ALL nodes in the field (only actives nodes in the MONITORNODE table).

5. On the nodes, emailRcvMsg receives the incoming data. It checks to ensure the following:

6. rcvNetWatchData runs at 4,9,14,19,24,29,34,39,44,49,54,59 of each hour. It checks /viewPoint/var/dataUpdate/inbound for new data and populates the data in the database.

7. jobInitiater is a daemon process that checks the database every minute for new monitoring requests. jobInitiater notifies the serviceQueue daemon of new jobs and the serviceQueue places the monitoring requests in one of two priority queues. The first priority queue is for all services whose monitoring interval is 1,2,3, or 5. The second queue is for all other services. The first priority queue is worked off before anything in the second queue.

8. The masterOfAgents daemon checks the queue and assigns agents to the new monitoring requests. Depending on the monitoring request a specific agent is assigned to the task and runs at the appropriate timing. Examples of agents: httpAgent, dnsIspAgent, traceRouteAgent, pingAgent, dnsAgent.

9. Once the agents perform their tasks the collected data written to a message queue. This message queue is then read by saveMonRes, which in turn creates a flat file containing the raw result data.

10. sndMonRes then reads the data file and opens a live TCP/IP connection to the main database server and transmits the data to rcvMonRes.

11. rcvMonRes receives the data from the nodes, populates the data into the database and then passes the same data to notifyServer.

12. notifyServer keeps in shared memory a table of monitoring errors. Once monitoring errors accumulate past the threshold, the notifyServer generates emails to alert the end user.

13. Customer receives notification via email, pager, text messaging via wireless phone and can respond to issues affecting their servers and applications.

Additional Comments

1. The example shows the processes for monitoring a URL, but the application can monitor applications, networks, routers, email systems, ftp sites, etc. The process remains the same regardless of the target being monitored.

2. Each process runs on a 1:1 ratio, meaning that for each monitoring item running on the system, the application spawns a process to handle each request from start to finish.

3. Data propagation to the Sprint Internal Nodes works as follows: The GNW system sends the service propagation to global.netwatch@mail.sprint.com , which in turn forwards to the Carlisle node. The node then sends the email on to all the internal nodes.

Application and Data Propagation Flow (last edited 2011-08-11 19:43:21 by Bryce Camp)