Action configuration in 1.1.2

[rxm8028]

I've seen a lot of discussion about actions in these forums. I was having problems myself, and discovered that adding a 'Trigger severity' condition the actions seems to be neccessary for notifications to be executed. I was attempting send a notification under the condition that ANY trigger fro a particular host occured, but it refused to work until I added Trigger severity >= Not Classified to my list of conditions.
Does anyone know if this is the normal behavior?

Thanks,

[tzi]

Hi!

Thanks for posting this. This was the cause why no actions have been working since ages :-/

Thanks again!

Thomas

[Alexei]

Does anyone know if this is the normal behavior?

No, it is not normal! Please post the non-working list of conditions and fixed one.

[rxm8028]

OK, here's the list

Non-working conditions for action:

==== non-working conditions 1 =====
Host = "MAXIMO"
Trigger description like "MAXIMO"
Trigger value = "ON"

==== non-working conditions 2 =====
Host = "MAXIMO"
Trigger = "MAXIMO is unavailable"
Trigger value = "ON"

==== conditions that work ====
Host = "MAXIMO"
Trigger severity = "Information"
Trigger value = "ON"



Alexi, I tried a few more combinations of conditions, but I don't remember them all. None worked the way I expected them to, until I added the 'severity' condition.

Thanks

[colin7151]

Also something to check it make sure the time and date are correct and maintane a linear pace. I have had issues with putting zabbix on vmware (which is notoriously bad at keeping good time on RHEL4) and actions working inconsistantly. The problems went away when i moved it to RHEL3 (which works better at keeping time on vmware).

[rxm8028]

no vmware

I'm runnig Zabbix on a real machine, not virtualized. SuSE 9.3, to be exact. I tried several different sets of conditions, but none of them worked unless I included the 'severity' condition.

[Alexei]

Non-working conditions for action:

==== non-working conditions 1 =====
Host = "MAXIMO"
Trigger description like "MAXIMO"
Trigger value = "ON"

==== non-working conditions 2 =====
Host = "MAXIMO"
Trigger = "MAXIMO is unavailable"
Trigger value = "ON"

It works perfectly on our test system. I cannot confirm this problem.

[James Wells]

Greetings,

Also something to check it make sure the time and date are correct and maintane a linear pace. I have had issues with putting zabbix on vmware (which is notoriously bad at keeping good time on RHEL4) and actions working inconsistantly. The problems went away when i moved it to RHEL3 (which works better at keeping time on vmware).

Easiest way to solve this is to run a NTP client on the VMWare server and have the VMWare guests use host time. This way they will always use the same time as the VMWare server. You can enable this by setting the following entry in your VMWare guest vmx file;

Tools.syncTime = "TRUE"

Alexei,
Now that you have the actions configured, go in and change one of the triggers. We are also experiencing this issue, but only when we altered a trigger after the action was configured.

[Wolfgang]

Hello,

Greetings,

Easiest way to solve this is to run a NTP client on the VMWare server and have the VMWare guests use host time. This way they will always use the same time as the VMWare server. You can enable this by setting the following entry in your VMWare guest vmx file;

Tools.syncTime = "TRUE"

...

Timesync in Vmware can become a real problem.
According to the issue mentioned in this thread with RHEL4, i am pretty sure the issue is the kernel version used.
RHEL3 uses by default an 2.4.x kernel with an 100Hz Timer, where RHEL4 uses a 2.6.x kernel with an 1000Hz Timer ("Timer frequency").

Dependig on the Host-OS and vmware version, this leads to timeing issues that cannot be covered using ntp. (using a windows host with vmware workstation and a kernel 2.6.x guest, i have seen a timedelta of >15min in less than 60min).

Workarounds:
- Use Vmware ESX-Server
- Use Vmware Server on a 2.6.x Kernel (you might need to run guests with 2.4 kernel or patched 2.6 kernel)
- Use Guests with patched 2.6.x Kernel (to use a 100Hz Timer)
- Use Guests based on Kernel 2.4.x


Regards

Wolfgang

[James Wells]

Timesync in Vmware can become a real problem.
According to the issue mentioned in this thread with RHEL4, i am pretty sure the issue is the kernel version used.
RHEL3 uses by default an 2.4.x kernel with an 100Hz Timer, where RHEL4 uses a 2.6.x kernel with an 1000Hz Timer ("Timer frequency").

Yes, the kernel timer freq is part of the problem, but this issue existed even in GSX 2 and GSX 3 under RHEL 3u5 (2.4 Kernel). In fact, we had that issue until about 18 months ago, when I implemented the change I listed above. Since that time, my VMWare servers have acted as NTP clients, and the VMWare guests use the Tools.SyncTime. Since then, my VMWare guests have remained within 0.2 seconds even under the heaviest loads.

Please note I use a very mixed environment, but all of my VMWare servers are running GSX 3.2.1 under RHEL4u2. The VMWare guests are all over the Linux kernel map, as well as a few Win2K, WinXP machines. In my environmnets, if the Linux systems and the Win2K systems get out of sync by more than 0.45 seconds the application, that we are testing, breaks.

[colin7151]

Hello,




Timesync in Vmware can become a real problem.
According to the issue mentioned in this thread with RHEL4, i am pretty sure the issue is the kernel version used.
RHEL3 uses by default an 2.4.x kernel with an 100Hz Timer, where RHEL4 uses a 2.6.x kernel with an 1000Hz Timer ("Timer frequency").

Dependig on the Host-OS and vmware version, this leads to timeing issues that cannot be covered using ntp. (using a windows host with vmware workstation and a kernel 2.6.x guest, i have seen a timedelta of >15min in less than 60min).

Workarounds:
- Use Vmware ESX-Server
- Use Vmware Server on a 2.6.x Kernel (you might need to run guests with 2.4 kernel or patched 2.6 kernel)
- Use Guests with patched 2.6.x Kernel (to use a 100Hz Timer)
- Use Guests based on Kernel 2.4.x


Regards

Wolfgang

A combo of ntp and passing the kernel (2.6) the clock=pit arg is the best solution I have found without having to run modified kernels.

see: http://www.vmware.com/pdf/vmware_timekeeping.pdf for more.