Options

Documenting system dependencies

lordylordy Member Posts: 632 ■■■■□□□□□□
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?
Working on CCNP: [X] SWITCH --- [ ] ROUTE --- [ ] TSHOOT
Goal for 2014: RHCA
Goal for 2015: CCDP

Comments

  • Options
    lordylordy Member Posts: 632 ■■■■□□□□□□
    Ok, that's a valid point icon_smile.gif

    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.
    Working on CCNP: [X] SWITCH --- [ ] ROUTE --- [ ] TSHOOT
    Goal for 2014: RHCA
    Goal for 2015: CCDP
  • Options
    RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    lordy wrote: »
    Ok, that's a valid point icon_smile.gif

    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.
  • Options
    EveryoneEveryone Member Posts: 1,661
    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.
  • Options
    RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    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...
  • Options
    lordylordy Member Posts: 632 ■■■■□□□□□□
    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 icon_sad.gif

    That's why I was looking for a different solution.
    Working on CCNP: [X] SWITCH --- [ ] ROUTE --- [ ] TSHOOT
    Goal for 2014: RHCA
    Goal for 2015: CCDP
  • Options
    Forsaken_GAForsaken_GA Member Posts: 4,024
    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)
  • Options
    EveryoneEveryone Member Posts: 1,661
    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 icon_sad.gif

    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.
  • Options
    Fugazi1000Fugazi1000 Member Posts: 145
    ITIL - Configuration Management (the process)


    A tool to consider:

    Atrium (CMDB engine under Remedy)
  • Options
    rfult001rfult001 Member Posts: 407
    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.
  • Options
    lordylordy Member Posts: 632 ■■■■□□□□□□
    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?
    Working on CCNP: [X] SWITCH --- [ ] ROUTE --- [ ] TSHOOT
    Goal for 2014: RHCA
    Goal for 2015: CCDP
Sign In or Register to comment.