Skip navigation
1 2 Previous Next

Product Blog

21 Posts authored by: rob.hock

If you missed the 11.5 beta, you may not have noticed a subtle, but important new feature in the Quality of Experience dashboard: Application Discovery.

Application Discovery allows QoE sensor to automatically detect ~1400 known applications as well as perform URL parsing for HTTP applications:

2-2-2015 1-36-30 PM.png

 

So why is this a big deal? Previously you had to define which applications to sniff for. Now besides simplifying the sensor process, in combination with the new alerting engine in 11.5, you can now detect and alert on malware or unwanted cloud applications:

 

2-2-2015 1-40-23 PM.png

 

 

Perhaps a little bit of cloud-storage provider activity is permissible in your environment, but if a couple gigs leave it could trigger data ex-filtration concerns? Done:

2-2-2015 1-45-42 PM.png

 

URL parsing also has interesting security implications. Perhaps there is new botnet C&C we want to validate our servers aren't checking in with. A quick report can give us piece of mind:

2-2-2015 1-52-07 PM.png

To deploy QoE agents, simply define the endpoints you want to monitor as managed nodes. For DHCP client ranges, you would likely want to setup scheduled discoveries, and would need to add clients on a recurring basis. 

2-6-2015 10-18-05 AM.png

 

Once managed, you could either deploy sensors to the endpoint, or monitor via SPAN/Tap. Would the constraint of clients having to be managed prevent you from deploying? Please let us know in the comments below. If you're not familiar with QoE agent deployment, check out the deployment guide here.

If you're not yet on 11.5 RC, and are on active maintenance- log into your Customer Portal to download.

Welcome to NPM v11!

 

It's finally here! Throughout the beta and RC process, there has been a ton of excitement around the new Quality of Experience (QoE) dashboard in NPM 11, and today the wait is over!

For those of you that may have missed it, the QoE dashboard captures packet-level data from sensors deployed in your environment, analyzes it and aggregates the information in a easy-to-read dashboard.

These statistics make it easy to tell at a glance not only if you have a user experience issue, but whether the issue is a problem with the network or the application.  In addition to response time statistics, we are capturing aggregate volume metrics, and have the ability to classify application traffic on your network by risk-level and relation to typical business functions.

 

QoE_Dashboard (1).png

Business_v_social.png

Out of the box, NPM 11 is able to categorize ~1200 applications. Here we can see a sample of the Citrix applications we support (including ICA protocol):

Citrix_ICA_Monitoring.png

 

 

Sensor Topology

 

So how are we able to gather this data? In NPM 11.0, we have the ability to deploy Packet Analysis Sensors (PAS) to Windows-based (64-bit / 2008+) systems. Sensors can be deployed in two configurations: "Server" or "Network."

With a "Server" PAS, the sensor is deployed directly on a server you would like to monitor. So for example, if you wish to monitor your Exchange response time / traffic, you would push the sensor directly to your Exchange server:

 

SPAS (1).png

For a "Network" PAS, the sensor is deployed to a dedicated Windows-based system with a dedicated interface attached to a tap / SPAN / mirror interface.

NPAS.png

Once sensors are deployed, you can choose from our library of ~1,200 application signatures to monitor, or create your own custom HTTP applications.


Deployment Considerations


So now that we understand how we are gathering the data, where should we gather it from? Like many deep questions- it depends.

Are you a server admin looking for aggregate response time for your servers? Network admin wanting looking for client response time broken out by site? Both you say?

It's important to note that the PAS will report data aggregated at the server level, unless the individual client endpoints are also managed nodes in NPM. For example, in the case where we would want to see web server statistics from multiple remote sites, endpoints at those remote sites would need to be managed nodes in NPM (even as ICMP nodes.) From there, we could either deploy a SPAS to said endpoints, or use a NPAS anywhere in the traffic path to break out the individual response times.

If the application server is virtualized, you are presented with even more deployment choices for the NPAS. Do you create a virtualized NPAS and sniff the VDS? Create a promiscuous port group? VMWare has some good documentation on the hypervisor side of things: VMware KB: How promiscuous mode works at the virtual switch and portgroup levels  :: How to use Port-Mirroring feature of VDS for monitoring virtual machine traffic?


For more information- please check out our QoE deployment guide.


FAQ

How are sensors licensed?

Out-of-the-box, a licensed version of NPM comes with 1 NPAS and 10 SPAS licenses. For most small-to-mid sized deployments, this should be sufficient to monitor critical infrastructure. Beyond the built-in licenses, NPAS and SPAS are licensed individually (NPAS) and in packs of 10 (SPAS)


How is NRT / ART calculated?

Short answer: magic. Long answer is a bit more complicated . Check out this video presentation by certified Wireshark© network analyst Jim Baxter: Deep Packet Analysis & Quality of Experience Monitoring - YouTube

 

How is an application classified?

Short answer again: magic. Long answer is: it depends on the application. Out-of-the-box NPM ships with ~1200 application signatures that use a variety of techniques beyond the typical port & protocol matching you may find in other solutions. Some examples of techniques used:

  • Statistical Pattern Matching
  • Conversation Semantics
  • Deep Protocol Dissection
  • Behavior Analysis
  • Future Flow Awareness

 

Can I create my own applications?

In NPM 11, we have the ability to create custom HTTP applications. In the future we may look at the definition of custom applications via port & protocol.

7-28-2014 5-31-03 PM.png

How much traffic can a sensor handle?

Both NPAS and SPAS are rated to a sustained 1Gb/s given sufficient resources. (Check out the deployment guide for more detailed information, but good rule of thumb is 1 CPU core per 100Mb sustained traffic.)

Without using a specialty hardware appliance, this is a pretty impressive number.


How many applications can I monitor per sensor?

The recommended maximum is 50 applications per sensor. Beyond this, performance results may vary.


How many sensors can an Orion instance handle?

The current maximum number of sensors an instance can handle is 1,000.


Learn more
For customers under active maintenance, NPM 11 may be found in your SolarWinds Customer Portal.

Release notes for NPM 11.0 may be found here: SolarWinds Network Performance Monitor Release Notes

Sign up for SolarWinds lab, where the topic of discussion will be the new QoE functionality: July 30th, 1PM CT - LAB #16: Deep Packet Inspection Comes To NPM




Overview

 

New for NPM 11.0 is the exciting Quality of Experience (QoE) dashboard. The QoE dashboard uses deep packet inspection to provide the ability to easily determine whether a performance issue stems from application server slowness, or an issue with the underlying network. The two key metrics we surface in QoE to help determine this are: Application Response Time (ART) and Network Response Time (NRT).

NRT (or TCP 3-way handshake) provides a relative metric for the quality of the network connection at a given point in time, where ART (or time to first byte) reflect how long the application server took to respond to the request. Individually the statistics are interesting, but together they allow you say fairly definitively whether an issue is a network problem, or if it's time to call the application / systems team.

7-15-2014 3-53-55 PM.png7-16-2014 1-43-18 PM.png

 

So how do we collect data?

 

NPM 11 collects packet data via new software-based sensors, the Network Packet Analysis Sensor and Server Packet Analysis Sensor.

Out of the box, NPM comes licensed for (1) Network Packet Analysis Sensor (NPAS) and (10) Server Packet Analysis Sensors (SPAS).

 

 

NPAS

     Network Packet Analysis Sensors are installed on a dedicated 64-bit Windows server (physical or VM) with a dedicated interface to be attached to a SPAN / mirror / tap / etc.

For example:

7-15-2014 4-14-13 PM.png

NPAS's can be deployed at any layer of your network to provide visibility into response time across your network. Any aggregation point for which you would want to collect data would be a good candidate for a NPAS, from a remote access-layer switch to a core datacenter chassis. For example, by collecting access layer data, you may want to focus your monitoring of remote-site client endpoints, versus monitoring centralized servers at your core.

 

To deploy a sensor to a dedicated host, simply go to Settings->QoE Settings->Manage QoE Packet Analysis Sensors

From there, click Add Packet Analysis Sensor and select the dedicated host to deploy to:

7-15-2014 4-19-58 PM.png

 

7-15-2014 4-29-24 PM.png

Once the sensor is successfully deployed, you edit the sensor to choose the assigned interface, or add managed nodes for which the sensor will be seeing traffic:

7-15-2014 4-37-31 PM.png

Applications to filter for can then be added on a per-node basis via the "pencil" icon:

7-15-2014 4-44-02 PM.png

 

SPAS

Server Packet Analysis Sensors (SPAS) function almost identically to NPAS, with the exception that a SPAS is designed to collect information only for the system it is installed on. For example, if you were a server administrator interested in collecting Exchange response time data, you would deploy a SPAS to each of your Exchange servers:

 

7-15-2014 5-51-28 PM.png

7-15-2014 5-50-34 PM.png

By default, the sensor will be limited to a single core and 1Gb of memory. It may be desirable to adjust these settings based on amount of traffic, and resources available to the system:

7-15-2014 5-57-07 PM.png

 

7-15-2014 5-54-53 PM.png

 

If the nodes are assigned to an additional poller in the environment, the sensor data will report back in through the assigned poller.

 

Remote Site Considerations

 

Your level of data granularity will vary dependent upon where the sensors are deployed. For example:

 

Sensors deployed in a central location - Provides aggregate data for servers in the central site

NPAS deployed to remote sites - Remote client endpoints can be added to the NPAS to provide a per-client view

SPAS deployed to remote endpoints - SPAS can be deployed to some or all remote endpoints to provide comprehensive or sampled endpoint data

 

The table below should help decide where to deploy:

8-20-2014 6-25-54 PM.png

 

 

Conclusion

 

Whichever deployment method you choose, the sensor installation process should only take a matter of minutes, and begin to immediately report data.

NPAS and SPAS can be mixed in the environment, so for example if you wanted to monitor your core datacenter switch with an NPAS, but wanted to deploy several SPAS to remote-site servers, this would be a valid configuration.

With both a dedicated NPAS and SPAS option, you have the flexibility to quickly and easily gather data in a way that best suits your environment. Licenses are included out-of-the-box with your NPM installation, so give it a try today!

 

For more information and deployment considerations, please check out the deployment guide.

New Free Tool You Say?

 

It's our pleasure to announce the availability of SolarWinds' latest free tool: Response Time Viewer for Wireshark®

Response Time Viewer has the ability to read in common packet capture file formats and automatically identify signatures for over 1,200 applications.

With applications identified, we'll then break out a host of metrics:

 

  • Application Response Time (ART) - Time to first byte
  • Network Response Time (NRT) - Three-way handshake
  • Data Volume (Total and bps)
  • Transaction Volume (Total and Avg per minute)

 

You can then filter by application, and export the pre-filtered capture back out to a PCAP for detailed analysis in Wireshark. No more digging around in Wireshark, filtering by port and protocol trying to find your interesting traffic!

With Response Time Viewer, we make it easy to find the traffic in question, and start to understand whether there may be an issue with the network, or if you may be having a server problem.

Next time you're hunting for that needle in the haystack, give Response Time Viewer a try: SolarWinds Response Time Viewer for Wireshark®

If you're looking for an excuse to check it out, it's also the subject of this month's Thwack mission: thwack Monthly Mission - July 2014

 

Response_Time_Viewer.png

Intro to NPM 11.0

 

With NPM 10.7 just out the door, we are pleased to announce that NPM 11.0 has entered Release Candidate phase. In a first for SolarWinds, NPM 11.0 has the ability to collect packet-level data from sensors distributed throughout your environment, and calculate Network Response Time (NRT) and Application Response Time (ART) for ~1,200 applications. These statistics make it easy to tell at a glance whether an issue is a problem with the network or the application. In addition to response time statistics, we are capturing aggregate volume metrics, and have the ability to classify application traffic on your network by risk-level and relation to typical business functions.

All of this data is displayed in the new "Quality of Experience" dashboard:

 

QoE_Dashboard.png

 

Sensor Topology

 

So how are we able to gather this data? In NPM 11.0, we have the ability to deploy Packet Analysis Sensors (PAS) to Windows-based (64-bit / 2008+) systems. Sensors can be deployed in two configurations: "Server" or "Network."

With a "Server" PAS, the sensor is deployed directly on a server you would like to monitor. So for example, if you wish to monitor your Exchange response time / traffic, you would push the sensor directly to your Exchange server:

SPAS.png

For a "Network" PAS, the sensor is deployed to a dedicated Windows-based system with a dedicated interface attached to a tap / SPAN / mirror interface.

NPAS.png

Once sensors are deployed, you can choose from our library of ~1,200 application signatures to monitor, or create your own custom HTTP applications.

 

NPM 11.0 RC is available in your customer portal today. RC's are fully supported and upgradable to the final GA version (if it differs from RC.)

Please let us know if there are any questions. Comments welcomed below.

SolarWinds takes security seriously, and in addition to performing exhaustive internal security testing, we do our best to respond swiftly to any reported issue. With the recent heartburn around Heartbleed, the development teams at SolarWinds have been working feverishly to determine if any of our products are affected. For those out there that may have missed the news, a few days ago a high-severity vulnerability in many versions of OpenSSL was made public- and dubbed "Heartbleed." If you have a system serving up SSL content, you may well be impacted. Since the details have been covered ad-nauseam by a variety of sources, we won't go into the nitty-gritty, but good primary source material may be found here: http://heartbleed.com/

While we do ship an OpenSSL library in our core platform that would be affected, it is not exposed as a service and is used in a limited outbound capacity. Because of this reason and our failure to locate any vulnerabilities during the course of our research we believe our products are not vulnerable to Heartbleed. Despite having zero known exposure to the vulnerability, we have released an OpenSSL library fix for Core to further put everyone's mind at ease: http://downloads.solarwinds.com/solarwinds/Release/HotFix/OpenSSL-Security-HotFix.zip

[Revised 6/12/14 10:45am CST to include 1.0.1h]

As everyone here hopefully is aware, we take community transparency quite seriously. In that spirit, please find below matrix:

 

ProductVersionStatusDisposition
Alert CentralOK
DameWareOK
DPA (formerly Confio Ignite)OK
EOCOK
FSMOK
FTP VoyagerOK
IPAM>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
ipMonitorOK
Kiwi CatToolsOK
Kiwi SyslogOK
LEMOK
Mobile Admin ServerOK
n-CentralOK
NCM>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
NPM>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
NTA>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
NTMOK
Patch ManagerOK
SAM>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
Serv-UOK
SFTP/SCP Server Free tool1.0.3.20 - 1.0.4.31OKSFTP/SCP Server 1.0.3.20 - 1.0.4.31 does contain OpenSSL 1.0.1e library, however only for internal encryption. No external SSL service is referenced, therefore not vulnerable.
Free SSH ClientOK
Storage ManagerOK
TFTP Server Free toolOK
Engineer's Toolset10.9.1 - 11.0.0OKSFTP/SCP Server in Toolset 10.9.1 - 11.0.0 does contain OpenSSL 1.0.1e library, however only for internal encryption. No external SSL service is referenced, therefore not vulnerable.
UDT>Core 2012.2OKOrion Core >2012.2 does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
Virtualization ManagerOK
VNQM>Core 2012.2OKOrion Core does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.
WebHelpDeskOK
WPM>Core 2012.2OKOrion Core does contain OpenSSL 1.0.1e library, but is only used for outbound SNMPv3 AES communication. It is not able to be referenced by outside process or communication, therefore not vulnerable. Core 2012.2 and earlier do not contain affected OpenSSL library.

 

As always, please let us know if you have any questions or concerns, and we will address them straight away.

All,

 

We have identified a bug in NPM 10.7 and SAM 6.1, which under specific conditions may result in the poller stopping when a Daylight Savings Time change occurs. While this bug only impacts a very small percentage of customers with the affected versions installed, we would encourage customers to install the applicable hotfix. If you have more than one affected product installed, only one hotfix application is required. In an environment with multiple pollers, the hotfix will need to be applied on the main poller plus each additional poller. Detailed installation instructions are included in the hotfix archive. We realize as busy IT professionals, you have far better things to do with your time than apply application patches, and apologize for the inconvenience. Most notably, our European customers would be at risk of encountering this issue when DST reverts this Sunday. Please let us know if there are any questions, or if we may of assistance.

 

 

HotFix1 Link:

http://downloads.solarwinds.com/solarwinds/Release/HotFix/NPM-v10.7.0-HotFix1.zip

It is our pleasure to announce that NPM 10.7 is now generally available!

 

As referenced below, many of these features were directly submitted and voted up by the community. Thanks for all of your ideas and lively discussion on how we can create a great product!

Let’s review some highlights:

 

Core

 

 

NPM

 

 

 

10.7 is available now in your customer portal.

Release notes may be found here.

Even with all of the new and exciting product updates, our development team somehow finds the time to outdo themselves. I'm pleased to be able to share with you an early beta of one of our most exciting projects to date: code-named "DPI."

With the ability to sniff the wire and analyze packet-traffic, DPI provides real observed network response time (NRT) and application response time (ART.) In addition, DPI has the ability to classify and categorize ~1300 different applications by associated purpose and risk-level.

Let's take a look at a few of the data points we will start to capture:

 

Network Response Time (NRT)

Is the problem the application or the network? Now you'll be able to prove your pipes are pristine and start to focus on the troublesome app server:

NRT.png

Application Response Time (ART)

The opposite end of the network problem- how long did it take to receive the first byte for a response? Good insight into the Quality of Experience that your users perceive...

ART.png

 

Data Classification

Sure, with NPM interface statistics or Netflow, you can determine how much of your pipe is being filled, and potentially by whom. However, unless you are able to stay on top of the latest in social apps and malware, who may not realize what you should be looking for.

Our list of ~1300 pre-defined applications makes this easy- whether you are looking for Exchange traffic, or Torrent:

Application_List.pngRisk_Level.png

 

 

 

Very likely this technology would begin to surface in a NPM release in the near future- so stay tuned.

For beta purposes, we're limited to just gathering data from a packet filter driver on the Orion server itself, but we have a few ideas on how we can scale that out.

Bear in mind, we're not yet storing any captured data, but rather just analyzing and discarding. Storage would potentially come later.

 

Interested? Sign up here: DPI Beta Survey

Already signed up, or want to learn more? Join our DPI Beta forum

 

PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) please let us know!

It is our pleasure to announce NPM 10.7 has reached Release Candidate status. Since just recently announcing the 10.6 release, the SolarWinds development team has been hard at work delivering great new features for 10.7.  Release Candidates are fully supported and can be installed on your production environment. Some highlights of 10.7 RC1:

 

Link Utilization on Maps

 

If enabled in Network Atlas, L2 link utilization will be displayed on the map:

Link_utilization.png

 

Independent Node Thresholds and Baselining


As first seen in SAM, NPM inherits the ability to have independent node and interface thresholds. These thresholds can be dynamically calculated on a weekly or daily basis to provide a moving window.

Thresholds.png


NOC View


For those of you that have your NPM console up on the big screen, 10.7 also introduces a special "NOC Mode" that removes the top tabs and cycles through subviews. Since NOC screens tend to have a lot of real estate, we've increased the max columns to 6.


NOC_View.png


Custom Poller Packages


Imagine if you could take your Universal Device Poller data and stick it in native CPU and Memory fields. In 10.7, now you can! Define your polled OIDs, transform, and apply to CPU / Memory fields- polled data will be treated just as native data is. No need to create custom reports and alerts. Import / Export and share on thwack. We've included some sample ones to get you started. (HP Procurve and Fortimanager chief among them.)


DeviceKit.png


Routing Resources now Support VRFs


VRF.png


Resource Drag and Drop


If you had a chance to try any of the 10.7 betas, you may have noticed the hashed "grab-bars" now at the top of each resource. That's right- drag-and-drop resources! We've also added dynamic column resizing to make view customization even easier.

 

DnD.png

 

Support for Ruckus and Motorola Wireless

 

Ruckus and Motorola wireless polling is now natively supported. No need to use UnDPs to retrieve AP info.

 

SNMP Status

 

Since time immemorial, ICMP reachability has been a requirement for a node to show "Up" in NPM. No longer! "List Resources" or use the new "Manage Pollers" page to change what determines status

SNMP_Status.png

 

In addition to these highlighted features, there are a host of incremental feature enhancements and bug fixes. Download the RC from your customer portal to check it out.

In this exciting age of virtualization, cloud, SDN, and other hardware abstractions, we often take for granted the most important technological advances of the 19th century – electricity. While some of us are just able to spin up another EC2 instance from the ether, most of us still worry about physical capacity, even if it’s going to our own internal virtual infrastructure. So that means at the end of the day, in order to add capacity, some poor soul somewhere is going to have to heft 60 pounds of metal into a rack and plug it in.

In its most basic form, this moment of truth is a non-event. The server comes with a couple cables, the PDUs are already mounted in the rack by the last person, just plug in each end and move on. Easy enough. But what if you had to order more of those cables? What the heck is the difference between a C14 and a C19? What if you had to order a new PDU and UPS to build out a new closet or rack? What if you’re standing in the server room right now talking to that kindly gentleman wearing overalls trying to figure out just what sort of socket needs to go on that wall? These are the sort of low-tech questions we’re going to answer here, because the day will come when you’ll be asked to “just” plug something in.

 

Let’s start with the common power cable. Excepting proprietary oddities from a few manufacturers and regional regulations, you will mostly encounter the same 4 types of cables:

 

IEC C13-C14:

IEC_C13-C14_(2).png

IEC C14-C20:

 

IEC_C14-C20.png

 

IEC C19-C20:

IEC_C19-C20.png

 

NEMA 5-15P-C13 (mostly North America):

 

NEMA_5-15P-C13.png

So now that we can identify these cables, where do we plug them in? The most common AC output voltages from UPSs will be 120v and 208v. For the remainder of this post, I will refer to 208v as it is most prevalent in North America, but it could be anywhere from 208v-240v internationally. Most modern datacenter gear will accommodate voltages from 120v-240v AC, however it is always advised you actually check the power supply of the gear to verify there isn’t an old-school voltage selection switch before plugging it in. Unless you like the sweet smell of fried PCB in the morning.

 

This also applies when you’re spec’ing out UPS and PDU gear for a new rack build-out. The first order of business is to make sure all of the gear going into the rack will support the output voltage of the UPS. (Or for that matter, that the PDU does as well.) 208v is more efficient than 120v, so if you have a choice in the matter, go with 208v. Secondarily, choose a PDU (or UPS) with a sufficient number of the desired type of sockets. The choice in output socket is primarily driven by your voltage selection and device amperage requirements, so if you’re going with 120v in North America, NEMA 5-15 is most common. Higher draw devices (read bigger) will likely call for C19 sockets as they can handle ~60% more juice than C13. C13’s also have proclivity to not fit as snug and secure as one might hope, so it may be a worthy investment to find PDUs / cables with locking latches (APC has some decent ones) to prevent accidental downtime.

 

On the other end of that UPS (or PDU) you will have a whole new set of decision points to determine what you need. Apologies in advance for the focus on North American plug types here. High-res pics of other standard (IEC) types would be very welcome in the comments section below. The common input receptacles you will see (or ask your electrician for) in North America will be:

 

L5-20 (120v/20A)

L5-20.png

 

 

L6-30 (208v/30A)

 

L6-30.png

 

 

 

Less common, and usually seen with big 120V UPSs will be a L5-20. Ever wonder what that horizontal slot was for in commercial building sockets? Now you know. If you’re going 208v, you may also be asked by your electrician if you need a “three-phase” circuit. The short answer is that three phase circuits can handle a heavier load, and that you need a UPS that supports it. The long answer may be found here: http://en.wikipedia.org/wiki/Three-phase_electric_power

Speaking of UPS- how does one select the appropriate model? Firstly, let’s talk about one of the dark mysteries of the electrical world- kVa and how it differs from kW. We won’t go too far into the weeds on this, but the reason kVA maps so well to kW is that kVA is “apparent” power and kW is “actual” power. Represented mathematically:

 

kW = kVA * pf (power factor)

 

Power factor is basically the efficiency (loss) of the power load. Nearly all modern high-efficiency server power supplies should have a power factor close to 1.0, so kVA tracks very closely to kW. This is what you will use to size the rated output load of the UPS. As far as runtime goes- pardon the obviousness, but the more batteries, the longer the UPS will run for. This varies by vendor and model, but will usually be stated on the product specs under min/max/average load. Make sure the UPS has the appropriate input connectors for the wall plug you chose, and the matching connectors for the PDUs, and you’re in business. Next step is to wait for a few hundred pounds of gear filled with lead-acid batteries to arrive on a pallet and hoist it into the rack.

 

Until the day comes that Tesla’s dream of wireless power distribution becomes a reality, there will always be a need for someone to push a plug into a matching receptacle of appropriate voltage and with sufficient amperage. If that someone is you- I hope you found this post useful.

In the comments below, we would love to hear how you currently manage your power / cooling / environmentals. Do you have them in NPM or are you using something else? How do you model your racks- Visio? Dare to dream of using something better?

We also have a quick 4-minute survey that gives an opportunity for even more feedback on rack diagramming and power / cooling management. We'd love to hear your thoughts: Rack Diagramming Survey

After release of Web Help Desk v12, we are now busily working on some great new features and enhancements to the product. Here is a preview:

 

  • Asset API to provide more flexibility and ability of automation
  • More robust reporting with options including
    • reporting on new objects like assets, parts or models
    • easier custom reports for common KPIs
    • redesign of custom report writer
  • DameWare integration
    • Some options are chat, screenshot capability or easier configuration for remote connections
  • Revamp of setup section
    • Make settings easier to find when returning to configuration options
  • Propagating information to child tickets
    • Pass various information from parent ticket to child tickets
  • More comprehensive documentation for different areas of Web Help Desk
    • Possible candidates for detailed documentation are SSO, Database migration, sizing and so on
  • Settings export for easier migration
  • Casper 9 support
  • Java 7 support

 

PLEASE NOTE:  This is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Let's Welcome the new "World Map" resource

 

 

 

If you've already had a chance to upgrade to the NPM 10.6 or SAM 6.0 RC's, you may have noticed the new "Worldwide Map" resource.

 

Worldwide_Map.PNG

For those of you that have been requesting this feature, or maybe already framing in Google Maps with your own API key to display dynamic map content, this new resource will be a real treat.

Worldwide Map has the capability to display the status of nodes or an aggregated group of nodes over dynamically updated street data.

Perhaps you're an ISP that manages customer premise equipment all over town? Worldwide map makes it easy to layout and view where your equipment is, and it's relative status. Manage a campus environment and want a birds-eye view of your gear? This new resource has you covered.

To add nodes to the map, simply click "Manage Map" and "Place Nodes on the map"

Manage_World_Map.PNG

Just select where you want the nodes, what nodes are to be placed at that location, and click submit. That's all there is to it.

If you placed a group of nodes, the status of the icon will reflect the "worst" so you instantly be able to see if a node is in a down status.

To select the default position and zoom level, simply "Edit" the resource.

 

In the future we can look at adding support for other objects, or borrowing some further functionality from the Network Atlas playbook.

What else would you like to see added? Please Let us know in the comments below.

For those of you that have installed the RC of NPM 10.6, you may have noticed some changes to the reports menu. And by changes, we mean the newfound ability to create awesome new reports from the web console. The report writer you have come to know and love is still available, and functions exactly as it always has. Reporting isn't something people generally get worked up about, but we think you'll love the new functionality so much, you'll never go back to the old writer. Without further ado, let's go into some highlights.

 

 

New Canned Reports

 

In addition to all the reports you have come to expect from the previous report writer, we've added a bunch of new reports for NPM (and NTA.) New reports have the ability to contain multiple resources (tables / charts) that can be configured to report on separate (or the same) data sources or time periods. For example:

Highest_Average_Response_Time.png

To make your life easier, you can take these existing reports and customize them to your heart's content.

The new report writer gives you the ability to change the header / footer / logo / etc. Additionally, the resources themselves are drag-and-drop to make it easier to layout the report and get it to your boss' satisfaction.

Report_Layout.png

Custom Reports

 

If you're more of a DIY sort of person, the new report writer gives you the ability to create a useful report from scratch- no SQL required. (Unless you really want to use SQL- it can do that too.)

Feel free to use most any of the existing web resources, or create new resources all your own.

Resource_Selector.png

Creating a custom chart or table is as easy as defining your datasource (which can be dynamic) and then the data you would like to report on.

Select_Report_data.png

Data can be filtered to represent the top X items, or the top X percent of items.

 

Custom_Chart.png

Sorting? Check. Grouping? Check. Summarization? Sure. Aggregation? You bet.

The new report writer allows you to get as simple, or detailed report as you like. Reporting can often be a challenge, particularly when you are creating a detailed custom report.

In NPM 10.6, we made it easy. If you're a current SolarWinds customer, NPM 10.6 RC is available now in your customer portal.

Please take it for a spin and let us know what you think.

For those of you not familiar with Google Fusion, it's the latest (beta) data visualization tool to come out of the Mountain View Chocolate Factory. Among other things, it can make some pretty awesome charts and maps.

Since we here at SolarWinds subscribe to all sorts of geekery, we thought it only fitting to pump our topology and dependency data into it and see what came out. As you can see from the video below, the results are pretty awesome.

 

So how does one go about creating such a cool map and putting it in NPM?

 

First, you'll need the SolarWinds SDK installed (http://thwack.solarwinds.com/thread/39001)

 

Then open SWQL Studio and attach to SWISv3 with your Orion Credentials.

For topology data, use the below query:

 

 

SELECT d.Caption AS DestCaption, s.Caption AS SrcCaption FROM Orion.TopologyData t

JOIN Orion.Nodes s ON s.NodeID = t.SrcNodeID

JOIN Orion.Nodes d ON d.NodeID = t.DestNodeID

 

 

 


For Dependencies, you would use the below query:

 

 

SELECT dp.ParentDisplayName, dc.ChildDisplayName

FROM

(

SELECT d.DependencyID, d.ParentUri, p.DisplayName AS ParentDisplayName

FROM Orion.Dependencies d

JOIN System.ManagedEntity p ON p.Uri = d.ParentUri

) dp

JOIN

(

SELECT d.DependencyID, d.ChildUri, c.DisplayName AS ChildDisplayName

FROM Orion.Dependencies d

JOIN System.ManagedEntity c ON c.Uri = d.ChildUri

) dc ON dp.DependencyID = dc.DependencyID

 

 

 

 

Right click on the results and save as a CSV file to your local hard drive.

FusionTables.png

Now let's go over to Google and search for "Fusion Table"

 

Select "Create" (you may need to login with your Google account credentials)

Select "Choose File" and select the file you have saved from SWQL Studio and click Next.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table_data.png

 

 

Take a moment to admire your data, and click Next then Finish.

See your data in the Fusion Table?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Network_Graph.pngOn the "Help" Menu  Select "Switch to Classic View".  You should now see the "Labs" menu option

From the "Labs" menu, select "Network graph", and you should now see your beautiful map.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

publish.png

Click on the "Get embeddable code" button and select the "Change Visibility" link

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Select "Anyone with the link". Click "Save"

Change the Height and Width to your desired size.  This size will need to be smaller than your column width in your Orion Page you will be putting the resource on minus about 50 pixels.  So if my Orion page column in 850, then I set 800 Width here.

Copy the "Paste HTML to embed in website" text.  Keep in your clip board for future use

Go to NPM, navigate to the page you want to place your Fusion Graph Map on.

From here it's a simple process of creating a Custom HTML resource. This has been covered previously here: http://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2010/08/05/hidden-gem-the-custom-html-resource

Once complete, get ready to impress your friends, family, and co-workers. Well, perhaps not, but you likely won't be able to stop playing with the new map.

Filter Blog

By date: By tag: