Image used with Creative Commons license permission from Eyesplash; originally published on Flickr.com.*

For Nimsoft Monitor

Nimsoft’s Unified Management Portal, v7.5 or later, enables you to select the language it uses. Administrative users can select the language for the UMP site and other types of users can select the language for their personal views of UMP.

Administrator 

To change the default language setting for the UMP site:

• Navigate to Control Panel>Portal Settings>Display Settings>Default Language.
• From the pull-down menu of available languages, select the language you want.

Nimsoft User or Account Contact User

To select the language for your personal view of UMP:

• Click on your User ID icon.
• Navigate to My Account>Display Settings.
• From the pull-down menu of available languages, select the language you want.

For more information on Nimsoft Monitor and UMP, see the product documentation library at docs.nimsoft.com.

To tell us what you think of this Flipboard post, take the survey on Survey Monkey.

*Image does not imply the availability of all represented languages in UMP.

For CA Nimsoft Monitor

The SNMP Data Monitoring (snmpcollector) probe self-health metrics are always on by default. If you do not want to collect and view this information, you can disable self-monitoring metrics in raw config.

Follow these steps:

1. Open the probe configuration in Raw Configure.
2. Expand the self_health node.
   The system displays the available self-health metrics.
3. Change the status attribute for the metric:
   enable – The metric is on and monitoring the probe
   disable – The metric is off and not monitoring the probe
   Important! Only change the metric status. If you change any other information, you could collect incorrect data.
4. Select Apply.
5. Restart the probe to complete the configuration.
   The SNMP Data Monitoring probe updates the status settings when the probe starts.

For more information, see the Probe Guide for SNMP Data Monitoring.

Image used with Creative Commons permissions from Ben Garney, originally published on Flickr.com.

Create a Custom URL Action in UMP

With the release of Nimsoft 7.6, you can now create a custom URL action. This provides a shortcut from an alarm to a third-party application by launching the URL in a new browser tab.

You can even use parameters in the syntax of the URL action, so that alarm attributes are substituted in the URL.

For example, you can use the parameter ${MESSAGE} to include alarm messages in the URL that can be consumed by a third-party service desk application.

To create a custom URL action, follow these steps:

1. First, make sure you have the right ACLs: To create or edit custom URL actions, you must have the Edit URL Actions permission set in the ACL. To launch a custom URL action, you must have the Launch URL Actions permission set in the ACL. With this permission, you can select an alarm, then launch an alarm action from the Actions menu.
2. Select the Alarms tab.
3. Select the Actions menu just above the list or table of alarms > Edit URL Actions.The Edit URL Actions dialog opens.
4. Select New URL action. Specify a name and a valid URL.
5. (Optional) Click the button and select an argument from the list. Repeat this step to add additional arguments if desired.
6. Make a selection from the Visibility menu. Note: The Public option makes the URL action available to both Nimsoft users and account contact users. Select account > No Account to restrict the URL action to Nimsoft users only.
7. (Optional) Click New variable to define a POST variable. If desired, click the button to use parameters in the POST variable.
8. Click Save to exit the dialog.

Note: Additional configuration steps are required on a system where Remote Desktop is launched.

To learn more about how to configure UMP, see the UMP guides in the product information library at docs.nimsoft.com.

To tell us what you think of this Flipboard post, take the survey on Survey Monkey.

There’s a new kind of data source available for widgets in the UMP Dashboard portlet – Metric! A Metric data source allows widgets to display the current performance data being monitored on a system. A Metric data source may be used with all widget types except tables and pie charts.

You define a Metric data source from the Data Sources tab:

From here, a hierarchical tree structure displays systems that have metrics available, grouped under either the Groups node (as defined in Unified Service Manager) or the Other node. Just keep expanding nodes until you find the system you want.

Once you select the system name, you can drill down to the specific metrics available. Select the desired metric, and drag it onto your widget. When you go to Live view, you’ll see the performance data.

For Nimsoft Monitor

Maybe you’ve seen one of the latest YouTube videos from CA Technologies, the one that shows how the application economy is a lot like speed dating?

And maybe you know that CA APM can help you make a better first impression with your customers because it uses synthetic monitoring. And you know synthetic monitoring is valuable because it helps you identify problems and determine if a website or web application is slow before that problem affects your end-users.

But did you know that using CA Nimsoft in concert with APM can be even more effective than using either one alone?

This is because Nimsoft’s probes, especially those developed to monitor networks, systems, and SLMs, can help you know whether an application problem is really only a symptom of an infrastructure one.

And knowing is half the battle!

To learn more about how Nimsoft probes can help you monitor your infrastructure and compliment your application monitoring, see the probe guides on the docs.nimsoft.com library.

To tell us what you think of this Flipboard post, take the survey on Survey Monkey.

For CA Nimsoft Monitor

Amazon Web Services (AWS) provide a decentralized IT infrastructure for multiple organizations. The various capabilities of AWS include remote storage and content delivery, scalable computing, and database access.

The AWS Monitoring (aws) probe uses CloudWatch to monitor:

• AWS Status – The availability of services for a specific geographic location. Alarms are generated if a service is unavailable.
  
• Amazon S3 – This service provides storage through web services interfaces. The probe generates QoS data based on the time consumed in storing and retrieving files.
  
• Amazon Elastic Compute Cloud (EC2) -  This service allows users to rent virtual computers on which to run their own computer applications. The probe generates QoS data based on the performance of various AWS computer instances.

For more information about the aws probe, click here.

Graphic representation of an algorithm by fdecomite, used with Creative Commons permissions; originally published on Flickr.com.

For CA Nimsoft Monitor

On September 15, Anton Chuvakin, Research VP and blogger for Gartner, posted about his updated research on “Security Information and Event Management Architecture and Operational Processes.”

Chuvakin urges anyone in the business of IT – or the IT of business –  to invest in growing and maturing their security information and event management (SIEM ) strategies because IT environments will only grow more complex and, “attackers, driven by improving defenses,” will only, “shift to more advanced attack methods.”

A mature SIEM strategy is complex but it includes many simple and crucial ingredients. One of those ingredients is insight into what is abnormal for your IT environment. This insight enables you to tell the difference between harmless anomalies and signs of a harmful catastrophe.

Many CA Nimsoft Monitor probes support dynamic alarm thresholds, which you can configure at the QoS metric level to yield alarms based on what you find most useful in identifying trouble in your system.

You do this by choosing one of three algorithms:

• Scalar: Each threshold is a specific value from the computed baseline.
• Percent: Each threshold is a specific percentage of the computed baseline.
• Standard Deviation: Each threshold is a measure of the variation from the computed baseline. A large standard deviation indicates that the data points are far from the computed baseline and a small standard deviation indicates that they are clustered closely around the computed baseline.

For more information about Nimsoft Monitor probes, with or without dynamic alarm thresholds, see the product information library at docs.nimsoft.com.

To tell us what you think of this Flipboard post, take the survey on Survey Monkey.

The security behavior of .NET in Windows Server 2003 and Windows Server 2008 r2 is different.

In Windows 2003, the SSL certificate for an LDAP server is accepted even when the host name in the certificate does not resolve to the physical host name of the LDAP server.

In Windows 2008, the implementation rejects the certificate if the host name in the certificate does not match that of the physical LDAP server.

To work around this problem, ensure that any alias used in a certificate file has an entry in the server’s hosts file which resolves the alias to the server’s physical IP address.

In addition, all configuration information for remote value must be entered in the SSO configuration tool.  Local value parameters, on the other hand, should not be overridden.

Did you know that you can customize your discovery results using Lua scripts?

Lua is a lightweight programming language that is designed for cross platform scripting.  It can be embedded and extended to address a wide variety of problems, making it very flexible and adaptable to a broad range of applications.

With Nimsoft Monitor, you can use Lua scripts to modify discovery results to fit your specific needs. By overriding the values that are stored in the CM_COMPUTER_SYSTEM database table after discovery runs, you customize the returned values for inventory descriptions such as name or os_type.

Default Lua scripts are located in the discovery_server/scripts directory.  If you would like to modify how the values returned from these scripts are displayed (e.g. display results in all caps, or to apply special filtering), simply override the default rule in the default script:

1. Copy the default Lua script to a new file prefixed with “override_”.
2. Modify the script logic as needed and save the file.
3. Restart the discovery server to apply your changes.

For example, if you want to modify the eval_name.lua script, you would copy the file and rename it to override_eval_name.lua. Then modify the script logic, save the file, and restart the discovery server. The next time you run discovery, the rules set in your new override_eval_name.lua file will take precedence.

Things to keep in mind when creating and using the Lua override rules:

• Do not modify the default Lua script files.  Any changes will be ignored and overwritten on a probe update.
• When adding or modifying an override Lua script file, you need to restart the discovery server for the changes to be applied.
• If any override Lua script file contains invalid Lua code, none of the override rules will be applied. Lua script errors are logged in the discovery server log file.
• The override rules will be applied when the discovery server processes new device data (or when you run discovery).
• The override rules get applied on device data from all sources, not just from discovery agents.
• If an override rule returns nil, the discovery server will apply its default data.

For more information about using Lua scripts to customize your discovery results, review the README file found in the discovery_server/scripts directory.

With the 8.0 version of CA Unified Infrastructure Management (formerly CA Nimsoft Monitor), you’ll begin to see some changes in our documentation.

You’ll still be able to go to http://docs.nimsoft.com to find all of your documentation needs for CA Unified Infrastructure Management.  However, with the 8.0 release, we are making the move to our new documentation home, the CA Technologies Product Documentation Wiki.

Wiki – what’s a wiki?

A wiki (not to be confused with a Harrison Ford sidekick), looks just like any other website.  The big difference is the collaborative feature that a wiki provides.  Now, when you view the CA Unified Infrastructure Management documentation on the new wiki, you have the opportunity to provide your input.  You can leave a comment, ask a question, or even give a “thumbs up” if you really like a specific topic.  This type of feedback is invaluable in helping CA to effect continuous improvement in our documentation as we continue to “REWRITE” Business in an application driven world.

How do I navigate the wiki?

In your browser, navigate to the CA Technologies Product Documentation Wiki, https://wiki.ca.com.   On the home page, you’ll see a drop down menu where you can select documentation for a specific product.  Click in the Select Product drop down and select CA Unified Infrastructure Management – 8.0.

*Tip: Just begin typing in the field and smart search will filter your selection so that you don’t have to scroll through the whole list. 

When you open the CA Unified Infrastructure Management-8.0 home page, you’ll see that the documentation is organized a little differently.  We have moved to a task-based organization so that you can navigate to the information you need based on your specific use case.  If you’re interested in Monitoring, simply click on the Monitoring Your Environment section and you’ll find all the information you need to know about setting up your system and performing application monitoring.

In the main window, you’ll find helpful informational tiles that summarize the contents of the sections listed in the table of contents.  The left pane lists the table of contents in a tree format so that you can expand and collapse your navigation.

How do I search in the wiki?

To search within the current documentation, click on the Search Product field in the left pane, and enter your search terms.  Your search results will appear in a new page with all of the topics containing your search terms.

In the search results page, you can further filter your results by Author or by other product spaces, as well as by modification date, or content type.

How do I collaborate in the wiki?

When you click on a specific topic, contents are displayed in the main window.  At the bottom of each page, you’ll see the collaboration space.  This is where you get to provide your feedback.

You can “like” or dislike” the topic, and you can leave your input by writing a comment in the comment field.  Comments that are entered in the collaboration space are forwarded to the documentation team. 

As you can see, with the move to the wiki, you’ll still be able to find all of the information that you need for CA Unified Infrastructure Management (formerly CA Nimsoft Monitor).  You’ll also have the opportunity to provide dynamic input that will help us cater the documentation to suit your needs.

What’s that Name?

The product formerly known as CA Nimsoft Monitor is now CA Unified Infrastructure Management (UIM).

Likewise, the Flipboard cookbook is now the CA Unified Infrastructure Management Cookbook.

What’s in a Name?

The new name better represents the diverse and robust array of monitoring and managing capabilities unified within a single solution.

What’s New?

You can find documentation for the just-released UIM 8.0 on the shiny, new CA Wiki. (Once there, simply start typing CA Unified Infrastructure Management in the main search box and you will see links to two separate wikis, one for CA UIM and one just for the CA UIM Probes.)

What’s Staying the Same?

You can still find documentation on the Product Information Library, support at both CA Support and on the Nimsoft Customer Portal, and community on the CA Nimsoft Monitor Community site.

And as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

Prediction Engine is a new SLM probe that lets administrators configure a Time To Threshold alarm for QoS enabled probes. To configure a Time to Threshold alarm, you must have CA Unified Infrastructure Management version 8.0 installed and the following probes deployed:

• baseline_engine version 2.34
• Probe Provisioning Manager (PPM) version 2.38
• prediction_engine version 1.01

Note: The prediction_engine probe doesn’t work with CA Nimsoft Monitor v7.6 and earlier.

Time To Threshold is an event violation rule that sends an alarm if a QoS metric is predicted to reach a set value within a user-defined time period. Setting a Time To Threshold alarm for any of the QoS enabled probes allows the prediction_engine probe to gather trending information used to calculate when a particular event might occur. The Time To Threshold settings are configured using the Admin Console.

Configuring Time To Threshold Settings

For any of the QoS enabled probes, you can configure a Time To Threshold time frame and prediction threshold to generate a predictive alarm. To generate a Minor alarm when within 10 days of a 100 MB change in disk usage on a particular disk in the environment you’re monitoring with the cdm probe, follow these steps:

1. Using the Admin Console, for the cdm probe select Configure > Disks > C:\ > Disk Usage Change.
2. Select the Publish Data check box to allow the probe to send its QoS metric.
3. Select Time To Threshold Alarm from the Predictive Alarm settings.
4. Configure the following alarm settings:

• Time Threshold: 10
• Time Units: Days
• Prediction Value: 100
• Alarm Severity: Alarm Severity 3 (Minor)

With these settings, the prediction_engine begins calculating a new metric, QOS_DISK_DELTA_TIME_TO_100, which will be the time, in days, until there is a disk usage increase or decrease of 100 MB. The baseline_engine sends an alarm each hour with the configured alarm severity when the QOS_DISK_DELTA_TIME_TO_100 metric (the Prediction Value) is less than or equal to 10 days.

Best Practices for Time To Threshold

• Narrow the time frame and prediction value for a Time To Threshold alarm. For example, a predictive alarm generated when a disk usage change is within 10 days of 100 MB is more accurate and useful than a predictive alarm that’s generated when a disk usage change is within 90 days of 100 MB.
• The Time To Threshold alarm is available for all QoS enabled probes. However, this alarm is more useful for probes that collect metrics for linear data growth, such as CPU, storage, or bandwidth.
• To turn off the Time To Threshold alarm, set the Predictive Alarm setting to None.
• You can change the Time To Threshold alarm settings at any time. The new settings become active at the top of the next hour.

For more information about the Time To Threshold predictive alarm, go to http://wiki.ca.com/display/UIMPGA/Prediction+Engine+%28prediction_engine%29+Versions.

Image of sunflower seeds by oatsy40, used with Creative Commons permissions; originally published on Flickr.com.

Seed device discovery is a new feature introduced in CA Unified Infrastructure Management 8.0 that enables you to add network seed devices to act as an initial communication point for discovering your network topology.

Seed device discovery benefits you in the following ways:

It allows you to enter only the IP address of select devices instead of a full set of IP ranges when you are configuring your discovery.
In some cases, you may still want to enter the full set of IP ranges to set the discovery boundaries.  If you don’t specify boundaries, discovery can be limited to the local LAN subnets from all discovered routers in order to avoid discovering the world.

It accelerates the discovery of known devices on the network. 
Starting with the seed device discovery phase, it can find network devices connected to the seed devices by evaluating route tables and CDP tables.  In the next phase of normal device discovery, the known addresses are discovered before unknown addresses.  The results of the ICMP ping sweep are also taken into account.

The ordering of the device discovery is prioritized as follows:

1. Routers and switches
2. Other known network devices as seen by CDP
3. IP addresses with a successful ICMP ping response
4. Other IP addresses (either automatically determined from the collected local LAN subnets or from IP ranges you specify)

Seed device discovery may not speed up the total discovery time, but it makes discovery smarter by finding known addresses first.

In CA Unified Infrastructure Management, you can configure seed device discovery when you define scopes using the Scopes tab in the Discovery Wizard.  For more information about defining scopes and configuring seed device discovery, check out the documentation on the new CA Unified Infrastructure Management Wiki.

For CA Unified Infrastructure Management

IBM WebSphere MQ is messaging middleware that allows you to share data and messages asynchronously between applications across multiple platforms. Websphere MQ allows independent and potentially non-concurrent applications on a distributed system to communicate with each other.  Applications can put or get data through Websphere MQ messaging queues.

Websphere MQ defines logical containers called Queue Managers (QM) that manage the storage and recovery of data. QMs coordinate with the applications that are updating messages on the queues, and perform queue isolation and locking functions to maintain consistency. Websphere MQ messaging queues are used either to store messages that are sent by programs or are pointers to other queues.  Channels are defined as a logical communication link between QMs. Websphere MQ supports message exchange via point-to-point and publish/subscribe mode.

The WebSphere MQ Monitoring (websphere_mq) probe is installed locally on a system with the IBM WebSphere MQ software. The probe discovers the available QMs and the corresponding messaging queues and channels. You can monitor and generate alarms for:

• MQ Queue Managers
• MQ Messaging Queues
• MQ Channels

For more information, see the Probe Guide for WebSphere MQ Monitoring.

Sunset Over Barcelona taken by Matt Debnam, used with Creative Commons license* permission, originally published on Flickr.com.

Today is the last day of vmworld Europe in Barcelona, Spain.

Whether you’re are saying adios to beautiful Barcelona, or you’re in a data center on the other side of the world, it’s a great day to say hola! to the CA Unified Infrastructure Management VMWare Monitoring (vmware) probe v6.21.

If you’ve been introduced to the CA UIM vmware probe already, you know that it helps you get the most from your VMs because it automates all common monitoring and data collection tasks.

But did you know that the latest release, vmware 6.2, includes ten brand new monitors (aka metrics)?

On the Datastore Node:

• Usage Cluster

On the Computer Resource Node:

• CPUusage
• Memoryusage

On the Host Node:

• distributedCpuFairness
• distributedMemoryFairness

On the VM Node:

• GuestMemoryUsage
• HostCPUUsage
• Physical Cores Used
• StorageProvisioned
• StorageUsage

To learn more about vmware and other probes, see the probe guides at doc.nimosft.com and the new CA Unified Infrastructure Management Probes Wiki.

And as always, we’d like to know what you think of this and other Cookbook articles. Let us know by taking the survey on Survey Monkey.

*For more information about the Creative Commons license, go here.

You’ve spent a lot of time creating the perfect dashboard. You want to make sure that people see it when they start UMP. You’ve tried sending emails to everyone. You’ve called. You’ve stood in their offices. And still they aren’t using the dashboard you created! What can you do?

In CA Unified Infrastructure Management 8.0, you (the system administrator) can specify the default dashboard to display when UMP starts. How, you may ask? It’s really pretty easy.

First, create and save the perfect dashboard.

Next, click the  (Options) icon in the Dashboard banner and choose Preferences. The Preferences dialog shows a list of all of the saved dashboards that are available. Select the perfect one and click Save.

That’s it!

 If you manage a large enterprise, all of your device and host configuration information is likely maintained in a configuration management database (CMDB).  You may be faced with the daunting task of ensuring that all of that configuration information is discovered by your CA Unified Infrastructure Management deployment.

Automated discovery in an enterprise deployment can often take several hours or longer, and may include devices you are not interested in, or it may fail to include devices that are temporarily offline. File-based import takes just minutes to complete, and allows you to control which devices you want to monitor.

To run a file-based import, you will need to prepare an XML file that contains your device and profile data. The XML file must conform to the standards set in the XML schema definitions located in the <UIM_install_directory>\probes\service\cm_data_import\schema  directory.

This directory also includes example XML files that outline the maximum and minimum elements to be included in your XML file, as well as an example Device and snmp profile file. These example files to ensure that your XML file will be accepted.  XML files that do not conform to the XML schemas are returned, and the data is not imported.

Once you have your XML file prepared, you have two methods available for completing the import. You can manually import the data in your file, or you can use the automatic method and allow the cm_data_import probe to complete the import.

The cm_data_import probe scans the <UIM_install_directory>\probes\service\cm_data_import\import directory according to the probe configuration (default is every 60 seconds) for valid XML files. When the probe finds a valid XML file, it imports the information and publishes the information to the discovery_server.

You can find step-by-step instructions for running the file-based import, as well as XML Schemas and examples on the CA Unified Infrastructure Management documentation wiki.

For CA Unified Infrastructure Management

The Oracle Database Monitoring (oracle) probe allows you to monitor your Oracle databases 24×7 so you can detect, diagnose, and resolve Oracle performance issues as soon as they occur. This information is presented to a database administrator as reports, and also as alarms when database performance crosses a specified threshold.

You can set up multiple configurable monitoring profiles to extract vital information about your database servers at specified intervals. Database administrators can use this information to tune and optimize database performance, and perform capacity planning.

Note: The oracle probe also provides support for Real Application Cluster (RAC).

The following information can be monitored on either local or remote database instances:

• Database uptime
• Tablespace growth
• Database growth
• Tablespace status
• Index status
• Data-file status
• Rollback segment status
• Fragmented segments
• The extents that can’t extend
• The data dictionary cache-hit ratio
• The data buffer cache-hit ratio
• The redo copy latch-hit ratio
• The library cache-hit ratio
• The sort-hit ratio
• PGA resource consumption (monitor memory consumption of Oracle users)
• The rollback segment contention
• The number of invalid objects
• The number of chained rows
• The number of users currently logged onto the server
• The MTS response time
• The number of MTS waits
• The enqueue resources
• The UGA memory usage
• User locks and locked users
• Lock waits event time
• The user buffer cache-hit ratio
• System waits and user waits
• Datafile i/o
• System statistics
• Global cache service utilization for RAC
• Global cache fusion ratio for RAC
• Global cache lock get time for RAC
• Global cache lock conversion timeouts for RAC
• Global cache average lock get time for RAC
• Global cache corrupt blocks count for RAC
• Global cache lost blocks count for RAC
• Number of long running queries
• Tablespace size
• Database size
• Resource utilization %
• Dataguard status
• Dataguard gap
• Dataguard timegap
• Tablespace temp free
• Active users
• Flash recovery area memory free
• Active connection ratio

For more information about this probe, click here.

CA UIM 8.0 introduced a new widget that allows administrators to design lists that display system information in a Dashboard.

When you drag the List widget to your Dashboard, the List Designer wizard starts. First, you create filters to define the computer systems that will be included in your list. You can specify more than one filter, and you can check your filter definitions before proceeding by clicking Test Filters. When you are satisfied with the filter definitions, click Next.

Now you need to choose what system information to include. When you click Add Column, a Metric column is added to the list. The Column Properties tab is where you define which information to include, and how to format it. The wizard shows you what the output will look like, so you can make changes and see the results instantly.

Once you’re happy with the output, click Finish. The widget is added to your Dashboard.

If you want to make changes to the list, go back to Edit mode and select the List widget. A tab pops up in the top right-hand corner, with an Open Wizard icon and a Reload Data icon . Click Open Wizard to easily make changes to the widget definition.

That’s it!

For Unified Infrastructure Management

Did you know you can create your own monitoring configuration with the SNMP Data Monitoring (snmpcollector) probe? If the thresholds in the default configuration do not meet your needs, you can create a monitoring configuration with different thresholds. First create a new monitoring configuration, then modify it to set the thresholds.

Important! It is strongly recommended that you create a new monitoring configuration instead of modifying a monitoring configuration that is applied to devices. If you modify a monitoring configuration that is already applied to devices, the changes are immediately applied to all monitored devices.

Follow these steps:

1. Select Monitoring Configurations >  > Create New Monitoring Configuration.
2. Enter the name for the configuration and click Submit. The configuration is empty. You must modify the configuration.
3. Select new configuration name >  > Modify Configuration.
4. In the Available column, click the metric families you want to collect data for.
5. Click Submit.
6. Click Reload to reload the SNMP Data Monitoring probe configuration.
7. Select new configuration name > metric family > Default Rule. The metrics and default thresholds for the component are displayed in the right pane.
8. In the table, select a metric. The threshold information appears below the table.
9. Update the threshold information as needed, then click Save.

Note: To return to the default thresholds for a metric, click Actions > Reset Thresholds to Defaults.

For more information, see the Probe Guide for SNMP Data Monitoring.