The eternal IT-services

[Aly]

May be some screens with your configuration of IT service?

[lamont]

make sure that in 1.6.x that you are using "Problem, if at least one child has a problem" in the status calculation, or in 1.4.x that you are using "MAX of childs"

[banderas20]

May be some screens with your configuration of IT service?

Sure! You'll find it attached.

[noxis]

Come on devs? You are claiming you have this working yet absolutely none of us end users are successfully using the IT Services feature? You advertise it on your main site as some epic feature:

Assuring SLA

* Hierarchial IT Services
* Real-time SLA reporting

BUT.IT.DOES.NOT.WORK.

Thanks

[gustav]

The same problem as most people, always 100% in the SLA report

Just wanted to say that I'm having the same problem as everyone else, just upgraded to 1.6.6, no change, still shows 100%.

[richlv]

"100% sla" seems to be reproducible in trunk. is there a report on the tracker ?

[gustav]

Found the "problem"...

Looked in the database and it seems to me that service alarms are only gathered after you create a service to monitor and that's why it's always 100% (at least from the beginning).

Well, it probably works as it should.
Do I like how it works? no,

There's obviously a lot of different solutions to the "problem", but I would believe that someone is already in to fixing this in another way?

/Gustav

[richlv]

i think people in this thread are referring to the fact that sla stays at 100% even when linked trigger event history clearly shows that not being the case - and for problems happening after the it service was created. at least i can reproduce such a problem in my trunk installation.

[gustav]

Are you sure it works like that?

Are you sure it works like that?

I have the same setup I believe, that is link to trigger checked...

When I tested it out I can see that it works, but only from the time I created the service.

When I check the database, there's a table called service_alarms and the rows within it is exactly what builds the SLA showing in the IT-service.

Can someone who wrote the code tell me if I understood it correctly?

Personally I think it would be better if it would actually have been linked to a the trigger for a particular host, so that one could generate SLAs retroactively.

[gedp]

I would second this message.

Is there a way take, retroactively, fill the services table with the data needed for sla calculation from the trigger or events table?

Geert

[richlv]

Are you sure it works like that?

I have the same setup I believe, that is link to trigger checked...

When I tested it out I can see that it works, but only from the time I created the service.

When I check the database, there's a table called service_alarms and the rows within it is exactly what builds the SLA showing in the IT-service.

we probably misunderstood each other. the idea is, it service should have the same events as the trigger it is linked against for the period it is linked.

Can someone who wrote the code tell me if I understood it correctly?

Personally I think it would be better if it would actually have been linked to a the trigger for a particular host, so that one could generate SLAs retroactively.

yes, generating sla would be very nice - maybe you can search the feature request tracker & enter a new request if one doesn't exist already

[emilode]

SLA calculation of parent

I have a question about the IT-services.

I have a parent with 15 childs (monitoring uptime). Everything seems to be working with the SLA reporting. However, if I have like 5% downtime on three different services, the parent (root) service shows 15%. However, 5% downtime for three different services distributed over 15 services isn't 15% in total. With this calculation, if all services had 10% downtime I would have had 150% downtime...

How can I get the parent-service to calculate the correct SLA % of all child services. In this case that would be 99%.

Is it possible? I'm currently running 1.6.5 of Zabbix.

[alixen]

I think that you misunderstand how SLA is computed.

Basically, you have 2 modes defined by "status calculation algorithm":
1. At any given time, parent is down if ANY child is down ("Problem, if at least one child has a problem" option)
2. At any given time, parent is down if ALL children are down ("Problem, if all children have problems" option)

I suspect that you have chosen option 1 and your three children were down at different times.

If all three children had been down at the same time, your parent downtime would have been 5%.

Hope this helps
Alixen