Installing the Monitoring Profile
Directions for installing the data workbench Monitoring Profile.
- Configure a new Sensor instance as if it will be used for tagged web page data collection. Be sure the zig.gif file is in the Sensor web server document root. Sensor can be run on the same host as the monitor profiles. (This is not an issue if using a text file for this purpose.)This Sensor instance must be dedicated to receiving only traffic from the Monitoring Agents. Also, the Sensor can be configured to run on a different port if you are re-purposing a web server for this collection.
- In the txlogd.conf file there is the default line:
- Copy the insight_monitor.zip/insight_monitor_agent to a temporary location.
- Update insight_monitor_agent.cfg file for your environment. Follow the comments inside the configuration file:The Monitoring configuration file:Define where you are collecting all information and provide URL address. This needs to be a dedicated sensor and should receive no traffic except for this application.There are paths assuming there is an e: disk. You may want to change this path for your environment.Sometime when running a Transform profile, data workbench can be unresponsive. This value lets you send an alert if three times in a row the process is unresponsive. This is a way of reducing false positive alerts.This is where you set the environment and group dimensions. This may be different from host to host.This is w here you can see exactly what the monitor agent is doing by viewing error logs in this path.This is to use the temp db internally. It may be alerted when reaching capacity. This is different than physical disk usage.
- Copy the insight_monitor_agent folder to each DPU and FSU host running the data workbench server. The default location as indicated in the configuration file is e:\insight_monitor_agent but you can change this location.
- Add a Windows scheduled task to invoke the agent every 10 minutes (this period is assumed in the processing rate calculations). The program is e:insight_monitor/insight_monitor_agent.exe. The argument is config-file e:\insight_monitor\insight_monitor.cfg. Start in e:\insight_monitor. The user running executing the task must have permission to read/write e:\insight_monitor and read the Win32 OLE object root\CIMV2 (required to ascertain the data workbench server service start mode and to check the percentage of space on local disks)
- Confirm that the VSL file is starting to grow as monitor records accumulate. This will take some time as the traffic volume will be extremely low in a small installation (every 10 minutes the agent sends only one hit for the host-specific data, plus one hit per processing profile).
- Unzip insight_monitor.zip\profiles\Insight Historic to a temporary location.
- Update host name in profile.cfg, [ dataset\cluster.cfg], and the [ dataset\segment export.cfg].
- Update the files to the data workbench profiles directory.
- Update log server and path in dataset\log processing.cfg to the location where the Sensor VSLs are accumulating.
- # do the same with the profiles Insight Profile Status and Insight Server Status. In addition, the status profiles should be reprocessed nightly with a trailing two day window. Add a Windows scheduled task: The program is e:\insight_monitor\insight_reprocess.exe. The argument is --profile-path="PATH TO PROFILES\insight profile status" --start-days-ago=2. Leave start in blank. Add another scheduled task for "insight server status" . insight_reprocess.exe requires read/write access to log processing.cfg to update the start time.
- In addition, the status profiles should be reprocessed nightly with a trailing two day window. Add a Windows scheduled task: The program is e:\insight_monitor\insight_reprocess.exe . The argument is - -profile-path="PATH TO PROFILES\insight profile status" --start-days-ago=2. Leave start in blank. Add another scheduled task for "insight server status". insight_reprocess.exe requires read/write access to log processing.cfg to update the start time. Confirm that each profile is reading the monitor VSLs as they accumulate. Again, this will take some time—probably hours—because of the extremely low volume.
- Configuring the Monitoring Profile in a licensed test environment . The test environment package is included with your implementation of data workbench, allowing you to install and configure the application. If installing on a production FSU or DPU server, then you will need to configure the server to run on a separate port.
- Deploying a new Sensor specifically for the Monitoring Profile . You will need to install a new instance of Sensor to the server running the Monitoring Profile. This is in addition to the production instance of Sensor. (There is no additional charge for installing Sensor on either a production or non-production server specifically for the Monitoring Profile.)
- Disable the monitor agent during data workbench maintenance . To avoid polluting the uptime and performance metrics, you can set service start mode to manual for the service InsightServer (Omniture Insight Server). A handy PowerShell command is set-service -name insightserver -startuptype manual . Set it back to automatic after the maintenance: set-service -name insightserver -startuptype automatic . Another option is to temporarily disable the monitor agent scheduled task.
- The Status profiles need a trailing window to drop old hosts and profiles as well as old host-profile mappings. However, if the amount of event data is so small that data workbench won't buffer it in, then you may need to extend the size of the window quite a bit to get it to process.
- The agent collects the overall and oldest as-of time from data workbench detailed status , which is reported in local host time assuming the event data log time stamps are in UTC (as in VSL files). If the event data timestamps are in a non-UTC time zone the as-of time will be offset in the resulting Insight Profile Status profile. If all of your event data time stamps are in the same time zone you can add that offset to Insight Profile Status\metrics\as of delay minutes.metric .
- Two new dimensions were introduced to help the customer group their servers if they are in different states , such as production, staging, testing servers, and servers in other states. For example if you are looking for "uptime", then you look at servers only in production mode. As a result, the Group dimension is just another way of arbitrarily grouping servers for your needs. For example, in the Monitoring Configuration file you can set, which host your department is servicing, such as Operations, Development, or Marketing.