Custom properties – How do you use them? SHOW US

solarwinds_worldwide_llc over 8 years ago Less than one minute read time

We are working to improve the onboarding process for NPM and SAM. As such, we are looking for real world examples of every-day practical ways our customers can use custom properties. We would like your real world examples of using custom properties to:

Set up alerts
Customize reports
Customize views

Please describe how you use custom properties and add a screenshot of how you are using custom properties in reports, alerts or views (a picture is worth 1000 words). As a thank you, we’ll get you 500 thwack points.

Top Comments

Parents

wluther over 8 years ago
Here is a link to the newest edition to our custom property uses.
Basically, we are now using custom properties to auto populate graphs, via some code I stol... errr... borrowed, from c.gura‌ and tdanner‌, and pieced together.
Every time we add the proper custom properties to an interface, or group of interfaces, a new graph is automatically populated.
We do not want to use multiple object graphs, showing several interfaces on a single graph.
We NEED to show several different interfaces, from several different nodes, all on a single page, and a different graph for each individual interface.
Ultimately, and eventually, I want to be able to have this based on a custom SWQL query resource, so the query can be easily edited from the browser. I also want to be able to use the current graph types instead of the old graphs. And, I would like for this to be a native feature of NPM.
Anyway, enough of that... here is a link to more detailed... well... details.
Custom SQL Dynamic Graphing Resource
Over the past few years, we have transitioned from simple monitoring tools, such as MRTG and Cacti, to the advanced future-tech of SolarWinds. Surprisingly, though, we found SolarWinds to be lacking some of the basics when it comes to graphing. Sure, they get check marks in a bunch of the advanced categories, but many users just NEED simple, quick loading graphs.
In my world, we have numerous graph intensive pages to load. Some of these pages not only take a long time to load, but also take a long time to edit.
Here is our scenario..
- Customer 1
  50 nodes
  3+ interfaces per node
  1 interface = main uplink
  1+ interface = subinterface vlan 100
  1+ interface = subinterface vlan 200
- Customer 2
  wash
  rinse
  repeat
We NEED a page, showing IN/OUT traffic graphs for each of the interfaces.
So, all of customer 1's main uplink interfaces will be on a single page, listed from interface 1 to interface 50.
Next, all of customer 1's vlan 100 subinterfaces will be listed on the next page, listed from 1-50+.
Finally, all of customer 1's vlan 200 subinterfaces will be listed on the next page, listed from 1-50+.
So, at the very least, we are manually building 3 pages, each with 50 different interfaces, from a total of 50 different nodes.
No problem, right? SolarWinds super advanced future-tech should be able to knock that out in just a minute or two, right?
Well... No... At least not that I can find.
Do we really have to manually build a new graph for every single interface?
No, not anymore...
-Will
- Cancel
- Vote Up +4 Vote Down
- Sign in to reply
- More
- Cancel

Comment

wluther over 8 years ago
Here is a link to the newest edition to our custom property uses.
Basically, we are now using custom properties to auto populate graphs, via some code I stol... errr... borrowed, from c.gura‌ and tdanner‌, and pieced together.
Every time we add the proper custom properties to an interface, or group of interfaces, a new graph is automatically populated.
We do not want to use multiple object graphs, showing several interfaces on a single graph.
We NEED to show several different interfaces, from several different nodes, all on a single page, and a different graph for each individual interface.
Ultimately, and eventually, I want to be able to have this based on a custom SWQL query resource, so the query can be easily edited from the browser. I also want to be able to use the current graph types instead of the old graphs. And, I would like for this to be a native feature of NPM.
Anyway, enough of that... here is a link to more detailed... well... details.
Custom SQL Dynamic Graphing Resource
Over the past few years, we have transitioned from simple monitoring tools, such as MRTG and Cacti, to the advanced future-tech of SolarWinds. Surprisingly, though, we found SolarWinds to be lacking some of the basics when it comes to graphing. Sure, they get check marks in a bunch of the advanced categories, but many users just NEED simple, quick loading graphs.
In my world, we have numerous graph intensive pages to load. Some of these pages not only take a long time to load, but also take a long time to edit.
Here is our scenario..
- Customer 1
  50 nodes
  3+ interfaces per node
  1 interface = main uplink
  1+ interface = subinterface vlan 100
  1+ interface = subinterface vlan 200
- Customer 2
  wash
  rinse
  repeat
We NEED a page, showing IN/OUT traffic graphs for each of the interfaces.
So, all of customer 1's main uplink interfaces will be on a single page, listed from interface 1 to interface 50.
Next, all of customer 1's vlan 100 subinterfaces will be listed on the next page, listed from 1-50+.
Finally, all of customer 1's vlan 200 subinterfaces will be listed on the next page, listed from 1-50+.
So, at the very least, we are manually building 3 pages, each with 50 different interfaces, from a total of 50 different nodes.
No problem, right? SolarWinds super advanced future-tech should be able to knock that out in just a minute or two, right?
Well... No... At least not that I can find.
Do we really have to manually build a new graph for every single interface?
No, not anymore...
-Will
- Cancel
- Vote Up +4 Vote Down
- Sign in to reply
- More
- Cancel

Children

No Data

Thwack - Symbolize TM, R, and C