Hello. I'm looking for detail regarding the log files a VVX produces. This article:
Gets the closest to what I'm after. Specifcally the part that breaks down the fields in an event as:
Using this event as an example:
0901024537|cfg |5|00|Prm|Parameter feature.validate.peer.cert requested type 0 but is of type 7
That would suggest we have the following:
However, that leaves some questions, like:
Anyway, I think all of this comes down to are the log file formats documented anywhere? I've searched, but certainly may have missed it. Anyone have any input/pointers?
welcome back to the Polycom Community.
Your understanding is correct and missed events happens when the phone is to busy. The Event Class is the logging Level and the ID is the logging module. In this example the Configuration module.
Polycom does not provide more details to End Users.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Polycom Global Services
As always, Steffen, thanks for your input.
Now, trying to respect the limited information shared with End Users, could you confirm what may be at least available via observation? For example, the the VVX web browser, under Settings, Module Log Level Limits, there is quite a list of modules. Configuration is one of those. Is it fair to assume that these map, via some 5 letter code, to the ID portion? So Configuration, for example, might map to "cfg", as in this example?
Similarly, if Event Class is 5, from that same example, would it be accurate to infer that:
I understand there is likely no more data about the field occupied by PRM, but if what I have listed is on target, that goes a long way to helping understand this log files!
Were you ever able to update the FAQ document? I can't tell if the date in the top right is the original posting date, or the last modified date, so I wasn't sure.
I did not have a chance to update anything and looking over it now I believe End Customers should be OK with what is documented.
Again the logs are there for Polycom to analyze and not really for end users to look at as they can be miss interpreted by an untrained or inexperienced person.
OK. Makes sense. One question related to this. Apart from the format, one other challenge is that the option for forwarding to a syslog server are somewhat limited. We can define the IP, and the protocol, but not the port. For example, when building a log aggregator, we have lots of syslog stuff destined to the same IP. Being able to change the destination port makes building parsers easier because you can definitively know what the sender is based on the port the event came in on. Then, we don't have to try to interpret multiple events and messages strings from different devices all coming in on the same port. We could put another IP on the aggregator itself, and send one device to port 514 on one IP, and another device(which also may not allow defining the port, such as Avaya phones) to 514 on another IP, but it's so much more elegant to be able to just change the destination port. Is it possible to put that in as a feature request, perhaps?