In part-1 I installed the server and were able to login in. In this part I will do some basic configuration and start to add some hosts. Before you start you should consider how your network is setup. This may affect the layout later on and it will be harder to fix this afterwards. There are two major ways of arranging your hosts. Folders and host tags. One does not exclude the other. There are also host and service groups but you will need to use them what method you choose anyway.
Lets say I have 1000 network objects I would like to monitor on one site. You may have Windows servers, Linux, UPS, Storage etc. In this case you may want to create folders for each network type.
If you have 20 sites and 500 hosts you may want to create one folder for each site like London, New York, Paris and so on. And create subfolders for Linux, Windows UPS etc.
Another option would be to create host tags like below. You may also want to create host tags for the type or whatever you may need. In the end the folders and tags helps you create rules for settings, notifications or check parameters.
It might also be a good idea to create some host groups. Just create some like linux, windows, ups etc.
When the host groups is created you may want to add some rules. In hosts – rulesets create a rule for grouping. Add hosts with tag linux to the linux host group. Do the same for others as well.
Now when this is done it is time to add hosts. If you have created folders I would go to one folder and create a host. On the linux folder it self you may want to specify things like it should use the agent. Agents should be installed on Windows and Linux hosts. I will describe this in detail later but install the general agent now.
When the host is added a lot of services is added. You can choose what services to add. In the case below it is the server it self. And the agent is also installed on the OMD server.
Press ok, Apply the changes and check the hostgroups view in the menu. Your server should now have been added to the Linux hostgroup.
You can now continue to create more hosts. You can also just add any host and later create grouping rules on the folders orr tags to add them to host groups. In the next parts I will show how to add other types of hosts. Windows or linux is just the beginning. With Check MK I have added detailed information from:
UPS, IBM Megaraid IMM adapters, Domino servers, Steelheads, Switches, Routers and SAN hosts. The options are endless.
Hi planet4
just some of questions about the difference between tags, folders and hostgroups.
-Is prefereable to use tags instead folders?
-In WATO I see that rules can applied to tags and/or folders but not to (nagios) hostgroups that I created. What am I missing?
-I know that in Nagios, hostgroups are useful whenever you need to applly something to a group of servers but, because in check_mk there are tags and folders, why should I use them?
Hi! Sorry for the late reply. I was kind of confused about this as well when I started up my check mk installation. I even asked the support what way they recommended and the answer was that all ways are possible. I have arranged my hosts in folders called a location. In that way I can apply settings on the folders like contact groups. In the folder called Gothenburg for example I have more folders for Windows, SAN, Linux, Switches etc. After a while a started to add tags. For example I put a tag called IMM on all the IBM Management cards. I have put them directly in a location folder. I have then created a rule under WATO -grouping – “Edit rule Assignment of hosts to host groups”. And this is where the hostgroups of Nagios is found. I have a rule where host tag IMM is placed under IBM IMM Modules. In this way they are found in the left menu in hostgroups. To summarize this there are many ways to do the same thing. Tags are great, Folders may be nice to if you have many hosts. Hope this helps somehow. / Fredrik
This is the response I got when I asked about best practise:.
you
can use folders to organize your hosts and do the assignment to host
groups on folders. If you need an assignment to several locations, you
can create those folders as first level and add as second level windows,
linux and so on.
Example:
– Stockholm
– Windows
– Linux
– UPs
– London
– Windows
– Linux
– UPS
Another
solution would be the usage of host tags. If you create a new host, you
can assign host tags to it. You can make groups like windows, linux and
location. In those groups you can define the information you need.
Example
– Location
– Country: England, Sweden
– City: London, Stockholm
– Windows
– Windows Version: Windows 2000, Windows XP, Windows 7, Windows Server 2003
– Database: MSSQL 2003, Oracle 9
– Webserver: IIS 8, IIS 9, Apache
Linux
– Linux Distribution: RHEL 5, SuSE 12
– Database: Oracle 9, MySQL
– Webserver: Apache 2.2, Apache 2.4
With this tags you can create rules for the correct assignment to the host groups.
We
suggest, that you use the folders for a basic organization of your
hosts and group the same functionality with it. A detailed configuration
is done easier with host tags. There you can create rules which can
make use of the host tags with logic operators.
Hi Planetfour
Thank your for you excellent explanation, now I have understood. To sum up all of them (tags, folders, hostgroups) are just options and, combining between them, you can create sophisticated rules.
This is the response I got when I asked about best practise:
you can use folders to organize your hosts and do the assignment to host groups on folders. If you need an assignment to several locations, you can create those folders as first level and add as second level windows, linux and so on.
Example:
– Stockholm
– Windows
– Linux
– UPs
– London
– Windows
– Linux
– UPS
Another solution would be the usage of host tags. If you create a new host, you can assign host tags to it. You can make groups like windows, linux and location. In those groups you can define the information you need.
Example
– Location
– Country: England, Sweden
– City: London, Stockholm
– Windows
– Windows Version: Windows 2000, Windows XP, Windows 7, Windows Server 2003
– Database: MSSQL 2003, Oracle 9
– Webserver: IIS 8, IIS 9, Apache
Linux
– Linux Distribution: RHEL 5, SuSE 12
– Database: Oracle 9, MySQL
– Webserver: Apache 2.2, Apache 2.4
With this tags you can create rules for the correct assignment to the host groups.
We suggest, that you use the folders for a basic organization of your hosts and group the same functionality with it. A detailed configuration is done easier with host tags. There you can create rules which can make use of the host tags with logic operators.
Planet4 I have another question, this time related to switches/router interface monitoring.
Check_mk per default remember the state found during first inventory and a CRIT is generated if the port status change.
In my opinion this is not the best way to monitor switches port
status or, at least, not always. I spoken with many network engineers
and they confirmed to me that a “general” and good way is to monitor
operational status ONLY for those interfaces that also are
administratively up. The problem is that I have never been able to understand if this is
possible or not with check_mk. I tried many combinations playing with
WATO…”Check operational state+Ignore operational state” but never
figure it out.
I also posted in the mailing list in which I usually got excellent replies and explanation but noone has been able to reply to this question but…maybe you will 🙂
Do you have any idea/suggestions? How do you monitor network interfaces on your devices?
I am not really sure I understand the question. For example I monitor all our switches. In some cases I have 48 port clients switches and I want to make sure everything works. When first connecting to the switch I may get info like uptime etc including 30 ports of clients. When a client turns his computer off the port will be in a critical state. So for my server switches I keep monitoring all ports but for the clients I go to WATO-Services and untick all ports that may be changing. And manually save this. This may look like this. However I am not sure this was really the thing you were asking for…
Ok I’ll try to explain better and please apologize my poor english.
You know that on network devices, there are status:
administrative up/down (no shut on cisco devices)
operational up/down
In many environment, network engineers configure their devices so that ports administratively up shouldn’t be never down. If they are sure that a port is unplugged, they will put the port administratively down (shut command in cisco)
Now…speaking about check_MK:
When you add a switch in check_MK, it gets (during first inventory) the current state of all ports regardless the administrative status and, whenever there is a change, a CRIT is generated; exactly as you described about your clients switches
This means that if you have a port 10 (just as example) administratively up but operational down, you won’t get CRIT. Only if port 10 will change its status (operational up) you will get a CRIT.
Maybe this is a good way as default behavior but it’s not what I need
What I need is to get critical status ONLY for those interfaces administratively up but operational down.
I hope now it is a little bit more clear.
Sorry but I am not really sure here. I understand what you mean but do not really have the same problem. In WATO-Rules – Network interfaces and switch ports there is a setting like below you can apply to ignore the operational state. Would that help? There is also a discovery rule you can apply like in the other image what ports to scan.
Yes I already tried to play with “ignore the operational state” but didn’t work. Anyway no problem I was just curious if you had the same problem. Now I’m working on a test environment and as soon as the “test phase” will be finished, we’ll purchase the enterprise version and I’m sure the support will help us with that.
Thanks again for your kind reply