Was wondering if anybody has created a new custom table (non-relational to Orion tables) in thier SQL DB?
Anybody know if this would cause a problem with NPM ?
Thanks,
BobL.
Yes, we've created several new tables to track inventory of all network infrastructure devices at our remote facilities using the Orion SQL instance, and have had no problems at all. Also, since it's the same instance, we can easily inter-mingle Orion data with user-defined data in the other tables. Along with this, we created several custom web resources for our Orion web site to view and alter the info in these tables. It really works quite well.
We are just about to start building out a new 8.5 installation of Orion (currently 7.8.5), so the additional ability to collect custom mib data will allow us to present even more dynamic data in our site database. Once the new Orion installation is complete, we will also be installing Cirrus, with the database component installed on the same SQL server as Orion. Once this is done, hopefully we can integrate some of the Cirrus info into our site database and view it from the web as well. We'll see...
Great news, thanks for the input.
I am trying to come with an easy way to allow our Network Ops folks to easily account for Outage exclusions after the fact. I've got several ideas, but the most direct approach would be to add a table (or two) to Orion and use it to manipulate a custom availablity report.
Right now I'm working on a concept of using a MS Access database with ODBC linked tables to Orion DB and a couple of other local data sources. The plan is to then create a simple interface that the Ops folks can use to select the Nodes to be exluded by indivdual node name, Facility (to include all switches in the facility) or something they maintain here called 'Next Higher Assembly', (basically the upstream equipment that a switch is hanging off of).
After the monthly inputs are made and collected in a table I can use that table to generate a SQL statement that will generate the report. It would be nice if it was possible to script a SQL statement into Orion from an external souce instead of manually copying the SQL code and pasting it into a Custom report, but oh well.
Anyhow, looks like this might be possible, thanks again for the input.
Bob,
We'd like to add this functionality to the product in the future. Could you give us a little more detail on the usage scenario--that is, what is the problem you're trying to solve and what would the solution ideally look like.
Denny
Hey Denny,
I am actually just starting development on this idea, I can keep you informed as to my progress if you like.
It's actually fairly simple in concept however it is going to be more complicated in practice due to the way things are done at my location.
Basically, I am trying to come up with a solution to doing Outage Exclusions after the fact. This solution should allow the person responsible for providing the Service Level Agreement Metrics to do so without having to be a SQL expert or having to painstakingly deal with exclusions for the monthly report on a one by one basis (when an outage effects multiple nodes). Obviously the preferred method would be to account for planned outages beforehand. This is very easily accomplished in Orion NPM by selecting Node Details and entering a time frame to declare the node 'Unmanaged' (but is still done on a node by node basis I believe). Unfortuanately this will not always be the case.
If the following were all true...
1. All nodes subject to SLA metrics responded to SNMP queries
2. All information entered into node configurations was complete and accurate
3. All info entered into node configurations was done consitently
...I think it would be a fairly straight forward process to use an external (to Orion) app to construct a SQL statement to exclude certain Nodes via:
1. Individual Node Name or IP Address
2. All nodes in a facility in the event of a facility outage
3. Other criteria available that describes a collection of Nodes.
This SQL statement could then be manually copied/pasted into a Advanced Custom SQL Report or even better a file written to the Orion Server if this post I found is true:
<start quote>
It sounds like you are editing the *.OrionReport file in the \Program Files\SolarWinds\Orion\Report directory with notepad. I know opening these in notepad shows you the SQL query (which you can also see in Report Writer from the Report drop-down menu choosing 'Show SQL'), but by design you cannot edit the SQL in predefined report types. You can, however, copy (or create your own) the SQL query and paste it in an Advanced SQL report type. This will allow you to edit the SQL directly.
<end quote>
How succesful this endeaver will be in my particular circumstance remains to be seen, but I'm going to take my shot at it.
Is this the info you were after?
So if an Orion report allowed you to exclude a set of "outage" times for specific nodes/interface would that solve your problem?
Denny,
That would be a big step forward.
The current method of accounting for post outage exclusions from the availability reports is cumbersome at the least. It requires manually adding and editing a 'Complex Condition' and up to 5 'Elementary Conditions' into report writer to exclude a single specific node for a specific date/time period.
Ideally, there would be an 'Outage' table in the schema that contained From/To Date and Time fields along with other fields like Node Name and IP Address.
This table should have the ability to be customized like the other tables in the Orion DB.
This table should also be exposed to 'Import' routines.
Then if an option could be added into report writer somehow to make conditions like the following easily enterable...
'...WHERE NOT ((tblOutage.FromDateTime >= 'datetime' AND tblOutage.ToDateTime <= 'datetime') AND Table_X.Field_X Like 'xxxxx')
I'm am by no means a SQL Programmer but hopefully you see where I'm going with this.
Field_X could be a default field in the Outage table, a field in the Nodes table or a user created custom field.
A few 'Where' clauses like the one above could account for many affected nodes without having to deal with each one individually. This would cover facility outages etc. Basically, this could be used against any group of nodes that could be defined by a parameter other than the individual node itself.
I was also going to include a 'Reason' field in my table as others have suggested. Besides the obvious, this could be used to easily generate a report for management that shows how a particular event has affected the network, be it a facility HVAC/Elect outage, Sub station going off-line, Cable plant outage/damage, etc.
The Outage table could then be modified at any time without affecting the reports written against it or causing the report to be modified every time.
Allowing customization of the fields used in the exclusion 'Where' clause would hopefully allow this generic exlusion process to be useful for folks like myself who have 'special considerations' to contend with. I think there are a lot of users that fall into this category and without a way for them to customize the outage accounting in the system to thier particular needs the full potental of this idea would not be realized.
The ability to give a reason when an alert and/or event was acknowledged would be very helpful. It would be nice to have a set of convenient reasons in a drop down list (that is configurable) but also have an "Other" option that allowed manual entry of reason for an outage. The ability to then report on those outages with the reasons listed (and the ability to exclude based upon those reasons) would help give more insight once an outage report is generated.
SamuelB
