Trunk DN OOS Alarm

[raza990]

Hi,

I'm settingup an alarm in SCI where if  SIP trunk goes down then alarm will be generated in SCI.

For this I simply setup active OOS detection parameters in trunk DN;

oos-force=20
oos-check=10
recovery-timeout=5

Now, When I put wrong IP address of gateway in contact paramtere of Trunk DN, SIP server makes the DN Out Of Service - and got below:


[b]Std 52000 Device GatewayTrunk is out of service[/b]

Just create alarm condition where I put log event ID 52000 on application type T-Server.

Problem is that I can't see alarm on SCI when the log event ID is present in logs 

Can you guys help me if you have experienced this before OR guide me if I do something wrong OR suggest me if you have a better way to do this.

[u][b]NOTE:[/b][/u]
This alarm will only work when gateway is not reachable on network.

[Kubig]

Have you configured logging to the network at the SIP Server application object level?

[raza990]

Network logging was missed at SIP Server.

Thanks Kubig for help - You are a Champ 

[raza990]

Hi,

Do Network logging mandatory for this solution ?

I don't want to save alarms into database. But I read that networking is necessary is you want to show alarm in SCI as SCS will aware of alarm if network logging is enabled but my boss said  "If network logging is required, then you have set up the solution incorrectly." 

Can we show alarm on SCI without network logging ?

[cavagnaro]

I also find it weird as the message is there by internal messaging, otherwise SCS would never receive messages.
Or is there something else missing on why it is needed?

[Fra]

[quote author=cavagnaro link=topic=9196.msg41412#msg41412 date=1447079374]
I also find it weird as the message is there by internal messaging, otherwise SCS would never receive messages.
Or is there something else missing on why it is needed?
[/quote]
oi?
You need to configure network logging in order for an application to *propagate* GCTI events to Message Server; else, they won't be sent to it.
Message Server  only purpose is a) to buffer those messages and b) for the alarm conditions you have set up to signal SCS, which will execute the alarm reaction you may have configured against them.
If you don't configure network logging, SCS will never know about whatever messages are generated by each application (except for host conditions, but that is a different story).

Fra

[cavagnaro]

By network logging you mean just add Message Server or store events on DB?

[Fra]

[quote author=cavagnaro link=topic=9196.msg41414#msg41414 date=1447087824]
By network logging you mean just add Message Server or store events on DB?
[/quote]
<log level output> = network
plus
connection to Message Server

[raza990]

I agreed that Message server is used for database logging, but SCS is not responsible for database logging. As Genesys also said in the tickets that network logging means to send event information to message server, SCS, or the management layer.

[img width=640 height=419]http://s23.postimg.org/atmx9dm2z/netlog.jpg[/img]

So network logging seems to be mandatory if you want to show alarm in SCI, but it also saves events in database .. so we have no other option - we must go with both database logging and sci alarm OR we forget this alarm.

[Fra]

[quote author=raza990 link=topic=9196.msg41417#msg41417 date=1447147019]
I agreed that Message server is used for database logging, but SCS is not responsible for database logging. As Genesys also said in the tickets that network logging means to send event information to message server, SCS, or the management layer.

[img width=640 height=419]http://s23.postimg.org/atmx9dm2z/netlog.jpg[/img]

So network logging seems to be mandatory if you want to show alarm in SCI, but it also saves events in database .. so we have no other option - we must go with both database logging and sci alarm OR we forget this alarm.
[/quote]

You are confusing storing logs  in the database with showing active alarms. These are two different features.
No one has said that SCS is responsible for logging into the log database; however,  if you want to have *alarms*, then you need network logging + alarm conditions set up.

[list]
[li]The storage of logs depends just on a. setting up a DB & its DB Server and b. enabling Message Server to insert them into it.[/li]
[li]The display of alarm conditions would take place even if you didn't have a database, as long as network logging and alarm conditions exist.[/li]
[/list]

[cavagnaro]

So if we disable DBServer would be the only way not to store data?
When you say
<log level> = network, all should be it or those messages have a specific level?

Never took a deep look at this :S

[Fra]

[quote author=cavagnaro link=topic=9196.msg41421#msg41421 date=1447175866]
So if we disable DBServer would be the only way not to store data?
When you say
<log level> = network, all should be it or those messages have a specific level?

Never took a deep look at this :S
[/quote]
Stop with the mojitos, get back to Framework :PP lol

Disabling DB Server is not the only way not to store data: the db_storage option at Message Server level is the one that dictates whether logs are stored in the database.
With regard to verbosity level, usually 'standard' is enough to get the main alarms come through; you can increase it to Interaction / Trace, but with obvious consequences. If you set it to all, network logging intrinsic capping won't send any debug-level messages to Message Server.

Fra

[Kubig]

You disable the logging into the database via message server option (do not remember the exactly name of the option, something like "db_storage=true/false"). In general, the logging into the database is good, but you has to be aware and schedule some maintenance on LOG database to archive or prune the old records.

[cavagnaro]

But mojitos are so good lol
Need to review my concepts never paid too much attention to Framework honestly