Documenting system dependencies

Dear all,

I am currently looking for a solution (maybe XML?) to document system and service dependencies.

As an example I have an FTP server on Host A and an application APP on Host B that is uploading files to it. So you could say that APP on B depends on FTP on A.

If I now reboot server A or it goes down then I would like to get the information that APP on B is influenced by this outage. Is that somehow understandable? Are there any existing solutions for documentation like this?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Everyone

Nagios.

lordy

Ok, that's a valid point

I was more thinking in the direction of "I am planning to do maintenance on Host X, what is impacted if it is unavailable?". Nagios would tell me when it's too late, I guess.

RobertKaucher

lordy wrote: »

Ok, that's a valid point

I was more thinking in the direction of "I am planning to do maintenance on Host X, what is impacted if it is unavailable?". Nagios would tell me when it's too late, I guess.

These relationships can be viewed in Nagios if you configure A as a child of B or it could be done in the comments field. This does not give you a very good report style list, though. So if your boss says send me a list of all systems that will be impacted if we decomission system XYZ, you have to type things up manually. I also don't think there is any sort of search functionality.

If you have SharePoint in your environment you can also express this in a list using a "lookup column" linked to other items in the list. The knowledgebase template in SharePoint uses this, for example, in the "related articles" field. That might be a better way of going about it.

Everyone

It can all be configured inside of Nagios. Maintenance windows, dependencies, everything. I'm not all that involved in the project, so couldn't give you too much detail on it, but our Linux admin is currently in the process of making sure all of our 400+ servers are documented in Nagios. This includes names of who is responsible for each server, what is on the server, and what dependencies each one has.

It is a LOT more than a reactionary tool.

If you need reports other than what is already available, just build them off the database.

RobertKaucher

Everyone wrote: »

It can all be configured inside of Nagios. Maintenance windows, dependencies, everything. I'm not all that involved in the project, so couldn't give you too much detail on it, but our Linux admin is currently in the process of making sure all of our 400+ servers are documented in Nagios. This includes names of who is responsible for each server, what is on the server, and what dependencies each one has.

It is a LOT more than a reactionary tool.

If you need reports other than what is already available, just build them off the database.

This may represent an exceptional learning curve for the typical Windows admin. For someone who is not really familiar with Linux just getting Nagios set up can be a walk through the vally of the shadow of death... Of course with his Sun/LPI certs it might be quite easy for him...

lordy

I actually have Nagios running, although with a small number of hosts/services.

The problem is that our business runs Zenoss as a monitoring solution and setting up Nagios has already been discussed and denied

That's why I was looking for a different solution.

Forsaken_GA

Everyone wrote: »

It can all be configured inside of Nagios. Maintenance windows, dependencies, everything. I'm not all that involved in the project, so couldn't give you too much detail on it, but our Linux admin is currently in the process of making sure all of our 400+ servers are documented in Nagios. This includes names of who is responsible for each server, what is on the server, and what dependencies each one has.

It is a LOT more than a reactionary tool.

If you need reports other than what is already available, just build them off the database.

I personally love nagios, always have.

Word of advice to anyone implementing hierarchies for alerting and notification - make sure you have a plan in place in case nagios screws up.

I had one issue with a distributed nagios monitoring infrastructure, where an admin patched and rebooted the master nagios server without bothering to tell anyone about it. All of a sudden, I'm seeing 3000+ alerts instead of the normal 20ish, and it takes me a few to realize that the infrastructure isn't screwed up, nagios is. It took a few hours to get everything sorted back out and the passive checks to roll back in to get nagios current

My personal solution for any nagios distributed environment is to run a vm with a small VM of nagios that only monitors nagios. That way I can tell at a glance whether my infrastructure is going down the tubes, or if nagios is having issues. The likelyhood of both setups going haywire at the same time is very small, and my little hidey hole 'who watches the watchers' install is not subject to the whims of linux admins who don't bother informing the people who actually use the toys that they'll be playing with them for awhile.

(protip - for the love of god, do NOT run your nsca and nrpe services out of inetd/xinetd. Run them as standalone daemons. xinetd/inetd can get flaky, and they add another point of complexity(failure) to your setup. You do NOT want this in your primary monitoring solution)

Everyone

lordy wrote: »

I actually have Nagios running, although with a small number of hosts/services.

The problem is that our business runs Zenoss as a monitoring solution and setting up Nagios has already been discussed and denied

That's why I was looking for a different solution.

If they denied a solution that doesn't cost them anything, how likely are they going to be to accept a different solution?

It sounds like someone has a love affair with Zenoss, and they're probably going to want you to figure out a way to make Zenoss get the job done.

Fugazi1000

ITIL - Configuration Management (the process)

A tool to consider:

Atrium (CMDB engine under Remedy)

rfult001

Fugazi1000 wrote: »

ITIL - Configuration Management (the process)

A tool to consider:

Atrium (CMDB engine under Remedy)

CMDB (or CMS) is where you would document the relationships between assets (computers, services, etc...) and configurable items (peripherals, parts of services, etc...). Once you have that is place you are looking for an impact analysis tool. I know Remedy (expensive) has all of this OOTB since 7.5, I am sure you can find other tools to do the job though.

I am pretty sure Spiceworks (free) does this for you as well after you go through the autodiscovery phase.

Hope this helps.

lordy

Remedy is awful software. I would rather hit my head to a brick wall then work with any of their, so called, products.

However, I have found something that comes close to the picture I had in my mind: Blueprints
Pathway Systems - Dependency Mapping of Business Process and IT Systems

Does anybody know them or use their software?