Mastering the SolarWinds Platform

You've already got #1.

I'd stick w/ DB #2   but swap 3 and 4 based on what you said you want to accomplish with API (language is personal preference, though perhaps you could knock out some of 4 with 3 if you went powershell).

2. DB

3. Scripting

4. MS Server.

Actually having the MS SQL server run correctly is important but... you don't really need to be a SQLrockstar (that was intended btw) to support Orion effectively.  You should learn how to backup the database.  Since currently (until the linux SAM agent goes release) everything runs on Windows I'd say understanding how MS servers work (and troubleshooting them) is pretty important... maybe more important than the SQL especially if SAM is going to be used for a lot.  A perfect example... don't let your C drive run out of space... little things like that can burn you big time.

I would probably put it in this order, although the first three are all pretty important. A lot will depend on what your are trying to accomplish.

1. Scripting 

2. DB/SQL

3. Networking

4. MS Server

Networking is important, but you have that, so I'll skip on to the others... I'm in an applications heavy environment, so my priorities are going to be a little different.

SQL server is important if you have performance issues, but knowing how to mine SQL transfers into using the SDK. I've learned, and slowly accepted, that it's more important to query using the SDK/SWQL over SQL. Being comfortable in the DB and with the SDK is key for a good Orion admin.

As far as scripting, powershell is critical. If you have any LINUX, then you want to pick up a little perl as well. Powershell is great as you can take SAM to new levels, and you can use it when you get into the SDK for automating and simplifying administrative tasks. Powershell is also simple and elegant, as well as easy to pick up. I've just started exploring Python and REST APIs as I have some projects eyeballed this year to integrate with some of our orchestration tools. I would start with powershell because it's easy to learn, and more versatile as an Orion admin with SAM.

About MS server, it's more important to focus on application bottlenecks than OS level stuff. For me, understanding server architecture has been more beneficial than known Windows specifically. From here, understanding the eccentricities of WMI, as well as what perfmon counters are relevant to your supported applications, basically how to get at the stuff you need to monitor. One hint for monitoring anything running MSSQL, start with using stored procedures over writing straight up select statements in your monitors out of the gates, or you'll regret it later. They are more efficient, and would be a best practice for any custom queries you need to apply in SAM. AppInsight is great if you're DBAs will let you use it. =)

In my environment we have a DBA team who takes care of the SQLserver, and a server team that takes care of the OS

understanding networking is a given.

so...

1. the actual components in Orion

-- need to be able to use the trap and syslog viewers separately from the alert engine to get stuff done efficiently; use the database manager to view the data in the database, etc.

2. SQL

-- for report writing, and advanced triggers.

3. Scripting

-- for when you can't solve the problem with 1 or 2 above

4. SQLserver /MS-Server Admin

for those times when the Orion problem is caused by a server problem you uncover.

CHG0030582

When you say "stored procedures" are you referring to embedded select statements ? 

I would like to point out that Application monitoring (both Linux and Windows) will be in scope.  We also have DBA's manage SQL and a server team for the MS OS.  The entire app and all its capabilities/modules/patching is all me.  Thanks all.

Stored Procedures are stored queries in the Database. They are precompiled. When you request database to execute a stored procedure (SQL Server), SQL server already has the execution plan for the stored procedure. While simple queries need to create their execution plan on run time. You can find arguments that say they are equivalent, but we tend to err on the side of caution.

SQL Stored Procedures

Rumor has it that you can barter the more advanced queries and scripts with beer.

...Although what I'm really saying is make a friend in these departments. I love figuring this stuff out for myself, but sometimes it's nice to get an assist when you get stumped.

This is how I see it in terms of priorities (1 being most important)

1. Scripting - Scripting is critical when it comes to SAM and putting in custom scripts to monitor non-standard metrics using powershell/vb/python/linux shell/sql/etc.

2. DB/SQL - It is useful to have a good understanding of how SQL works.  All of the back end work is done in sql.  Most larger companies have DBA so you can leverage them for complex sql issues.

3. MS Server - to monitor beyond the basic cpu/memory/services/process/wmi - good working knowledge of powershell is critical.  If you have a powershell expert on staff, leverage that person.  One thing I would like to mention is that VMware/HyperV knowlege is a must.  The virtual machines operate much differently then physical boxes.  Long gone are the days of looking at task manager and CPU level.  Now it's more of CPU Ready, zombies, over/under allocated guest, and storage networks.

   a) VMware/HyperV - Working knowledge of how virtualization technologies work.

   b) Storage - working knowledge of storage arrays.

4. Networking - Since you have a strong networking knowledge, I'm assuming you're at the CCNP level; which is way beyond SolarWinds work (It's not like you'll be architecting the network).  

In this way, if a user says the app is running slow.  You would start looking at the AppStack (guest, host, vCenter, storage) to see where the issue is.

I have the same situation (Cisco networking (17 years), Microsoft (3 years), SQL (3 years), Linux(2 years)) - since I'm not actively doing networking, I'm focusing on scripting, SQL, Microsoft, VMware, Storage technologies.

Amit Shah

Loop1 Systems

You're going to get different answers here, based on what the various jobs the Thwackers do. Generally, the consensus seems to be you need to have (in no particular order):

1. Network knowledge (Cisco, Juniper, HP, whatever your network runs, you need to know how to manage the kit, or have access to someone who does)
2. Knowledge of SQL Server, and how to use it (it's not all about simple SELECT queries, you need to ensure that your database is maintained in good health, is backed up regularly and so on).
3. Knowledge of the SolarWInds API and how SWIS works, so you can start using scripts (THIS LINK will help here, it's a little old but still relevant, also view the SolarWinds SDK on GitHub).
4. Knowledge of the Orion platform and how it all hangs together (various training videos here on  Thwack, as well as on the SolarWinds YouTube page).
5. Knowledge of SNMP, up to and including v3 (it's the Force, as far as SolarWInds is concerned, surrounds and penetrates all devices, gives you the insight into what devices are doing).
6. Knowledge of Microsoft Server technologies, and potentially Active Directory management, if you use AD integrated groups for access.
7. Understanding of what you NEED to monitor! It's pointless monitoring something just because you can, every node, ever device has to have a reason to be in your Orion database, otherwise it's just taking up space.

Long story short, from the above list, you can see why SolarWinds is managed by people who wear a lot of different hats, as it were. You need to be a good IT generalist to get the most out of it, and have access to the experts in the fields you are not, when things go beyond your personal skillet. If you have the time, learn what you need to close the gaps, but if you have to know something RIGHT NOW then  post a question, or pop a ticket in to support via your SolarWinds Customer Portal.

If in doubt, ask. That's what we're here for