want to make sure I do this right is there a method getting this set up correctly for example should I just start with servers or should i plan around mission critical apps?
I would recommend you start with monitoring you servers. Once those are managed by SAM you can then decide which applications running on those servers you wish to monitor.
Here is link to a site to help you get going. Server Discovery and Monitoring with Server & Application Monitor
Thank you when you did your installation did you follow a project plan?
aLTeReGo's advice is as specific as it can get kgalway, you're going to need people to start defining what applications and/or things they want monitored so you can assess what is needed to do so within Orion.
Example: if they want IIS, Exchange or SQL? There's specific configuration needed for that.
If they want something within the pre-built application templates? There's usually specific configuration for that.
If they want to do something custom with powershell? Again the same.
SAM by itself is a part of a solution and requires taken a step even further back in defining if application monitoring is what you want or what the scope is.
TLDR: You really need to scope out your plan and go from there. Also, monitoring is not designed to be a "ok, it's monitored, we're done". There is regular care and feeding required to continually stay up to date with the software, assess if the monitors are needed, assess if new monitors need to be added, disable any unnecessary components, create templates, etc. Effectively, monitoring has a lifecycle not unlike any other well known lifecycle.
so would you recommend professional services to get it off the ground and running? it sounds like power shell experience is good to have. ( in my case I will get a book on it and learn it) Yea my direction was to set up basic monitoring on the Windows , Unix (AIX, Solaris and Linux), Then work on DFS shares once i have that completed meet with the OS teams to verify we have what they are expecting. Then define applications in order of mission critical. at least that's the current game plan. we have about 70 victuals and 100 physicals servers the product doesn't look that hard but it may be time consuming. the time frame for getting the servers up and going with alerting is 4 weeks does that see realistic to you?
Thanks that gives me a start and a lot to think about.
I think you are going to be (pleasantly) surprised at how easy it is to quickly get monitoring up and running. The installer is stupid-simple, adding devices is pretty straightforward (although having your environment ready for adding devices - like having SNMP turned on, the VMWare credentials, and an AD account which has local admin available for you to use - may not be as easy as all that).
Just as a point of philosophy, "monitoring" is the ongoing collection of metrics from a target device. "alerting" is the happy by-product of first implementing "monitoring" and it can be a little more intense as you learn the in's-and-out's of triggers, thresholds, etc.
Can you get it (monitoring ~200 servers) done in 4 weeks? I know many people on Thwack who could. The odds are certainly in your favor. Will you run into hiccoughs that may jeapordize that timeline? You've been working in I.T. for more than 15 minutes, right? So you know the answer to that is "OF COURSE YOU WILL!"
Honestly, 4 weeks if you've never seen the software before is pushing it. However, 4 weeks for any OTHER monitoring solution, vendor-supported or open-source, is CLIFFS OF INSANITY INCONCEIVABLE.
I agree with designerfx, jumping into Powershell WHILE you are installing and learning this toolset is not your best bet. Most of the templates you are going to need are either provided, or easily found here on Thwack. I'd start there and only start to custom-build stuff after you've really gotten your sea legs under you.
Let me know if that helps.
Drop me a note if you want a copy of my project plan. Not sure it will help but it might be good as background.
yes this is great Thanks so much for the advice.
Yes on the project plan that would give me one to compare mine with to make sure I am on a good path. The product looks simple but I do want to make sure I do it right and get the benefit of the product.
one question new to this environment how do I drop you a note ? sorry if this is a stupid question but not sure if I have to communicate outside of the string or not.
BFE,
Would you happen to still have that project plan? We are implementing a new version of SW and I have been tasked with putting together a project plan. Anything you have would be great. Thank you!
My 2 cents:
1. Get NPM "up and running" (as suggested above) if you don't' already have it or if no one is monitoring the servers/network for "the basics". At last scope out if this is "a needed thing" from your team.
2. For application level monitoring, it would be "nice" to try to scope out how many apps and "things" you're going to want to monitor, but in my experience it just turns into a list of "well, everything everyone can imagine is an app or IT service or function". In my "real world" experience, *common* application monitoring requests/issues generally fall into these buckets:
- The common "apps" that everyone expects you to monitor, that usually have monitoring packages pre-built by the vendor, and that almost every monitoring tool has ways to monitor. Things like: Databases (MS SQL, Oracle), Webservers ( IIS, Apache), Core IT components everybody has (Active Directory, DNS). Maybe Remote access (Citrix, etc.) and/or whatever environments may be used to host VM's.
- The "big" apps. These are usually the "pain points" that caused monitoring to be considered as a necessity, or where the monitoring the app team was doing was not sufficient so people start looking for something else to handle it (augment it) for them.
- The "little" apps. Usually as each app has issues someone will request some small thing to be watched.
For all of the things above, there will usually be *something* already motioning them, even if it's just a script running on task scheduler or an app provided by a vendor. People using those systems might not want to use SAM as they already have it covered.
Regardless of my initial complaint about a "list", try to get the list of the above things together anyway and find out what "needs" monitoring via SAM and what other systems are already in place for monitoring apps. Maybe make a table or spreadsheet of "monitoring coverage by application" so you know where the gaps are. Check what things SAM can do with out of the box pre-built templates. If you have some areas not covered, look at the community templates. Then mark what things SAM can do "easily/with little custom effort". This will give you what you "need" SAM for as well as possibly what size of SAM installation you want to initially target. Spend about 0.01% of the time on the "little apps". Your critical apps and gaps will pop out. Have a few different people look at the list and see if magically a few new apps appear out of thin air.
With something like SAM, you can always script/build a custom solution, but try to refrain from doing too much of this early on. Focus on the pre-built templates and whatever is causing the most pain (if you have to build custom things). This gives you time to get used to SAM and how it works and to give you time to start thinking about how you want to standardize and manage the monitoring you have control of. It also gets other people used to SAM as a monitoring solution so you may end up porting monitoring a custom script(s) or other monitoring apps over to SAM. If you want to "take more over" you may want to spend some time "selling" SAM as a monitoring solution to internal departments or existing app support teams so they don't have to manage and maintain their monitoring. If you have some happy internal customers saying good things about the system, people tend to be easier to work with on migrations like this. Some teams will be happy with this (as they don't like managing monitoring), other teams will fight tooth and nail and never give you an inch (because they want control over their monitoring, or maybe they actually use all the metrics their system provides). Be aware that their monitoring tools may have more metrics and "useability" to those teams that SAM can easily provide for them (or they just may not want to change from what works for them). If they push back, I don't push back as I can come back at a later time and ask again. I try only to "take/migrate" the monitoring from teams who are happy/grateful to have me do it for them. If you try to force a team to move to your system and they don't want to, you will *waste a **TON** of time* pushing through management and meetings trying to get your way, and be leaving the people who want your help out in the cold. If your management wants to have you take something over from another team that does not want it, then you have my condolences. For some reason people can get really passionate about monitoring....this is getting to be a pretty large post...hmmm.
Long story short: For initial deployment use SAM as a tool to help others and augment monitoring where needed, don't use it to take anything over or do massive overhauls. It's not because SAM can't do it, it's because people/processes usually need time to absorb new monitoring tools and to become comfortable with them. You will probably need time as well.
After all that, slowly work on the custom things. Take on some of the smaller apps or apps that are important, but are not breaking enough for people to come to you asking for help. Learn how each component monitor works so you can do more esoteric monitoring. Once the "big" apps are covered it usually seems like there's a constant stream of "just watch this one thing" where it's 70% requests of "relatively easy to use a pre built monitoring component" like a windows service, and 25% "nothing exists and I have to build something by hand" like text log monitoring, and 5% "is this even possible?"
Here is the getting started guide for SAM. https://support.solarwinds.com/?title=success_center/Server_%26_Application_Monitor_(SAM)/Server_%26_Application_Monitoring_Getting_Started_Guide You can also attend free live training which occurs monthly, and there are plenty of videos to also help you. https://support.solarwinds.com/?title=success_center/Server_%26_Application_Monitor_(SAM)/Server_%26_Application_Monitor_(SAM)_Training
