Log Files
This section contains information about the log files and what each contains. The log files are stored in the
/opt/logs directory on the
Oracle Communications Session Border Controller.
log.sysmand
This log contains information about the system manager task. This task is currently responsible for writing the system log (acmelog), dispatching commands to other application tasks, and starting the application-level code.
log.bootstrap
This log records information about the boot process as the system becomes operational.
log.berpd
This log contains process logs for the berpd task or the redundancy health task. This file is primarily used for storing health messages and events and for determining whether a switchover is required.
log.brokerd
This log contains information about platform-level tasks. For example, when the ARP manager wants to log information in a place other than the console, it sends a message to log-brokerd. This is also true of the various host tasks related to communicating with the network processors and/or the CAM.
This log also contains messages from the IP fragmenter, which currently takes part in the SIP NAT process. brokerd forwards these messages through sysmand to the acmelog (the overall system log). Thus, log-brokerd contains a subset of the logs that acmelog contains.
log.lemd
This log refers to the local element manager (or local database server) processes. Information in log.lemd pertains to remote retrievals of and writing of configuration data.
log.mbcd
This log contains information pertaining to the application flow manager, such as the creation, updating, and removal of media NAT entries.
miboco.log
Tasks use MIBOCO protocol processing to communicate with the mbcd task. This log can be used to determine whether the mbcd has returned any error messages or other type of messages. It is possible that sipmsg.log and algd.log contain MIBOCO messages. However, the miboco.log is used infrequently because log.sipd and log.algd also report return codes from the mbcd.
log.radd
This log is used for the accounting daemon for RADIUS. It serves as a RADIUS client to the outside world. However, it also serves as a place to concentrate RADIUS records from various signaling protocol tasks running on the SBC. Its logs reflect the latter function.
log.sipd
This log contains information pertaining to the SIP processing task. The log contains information about how the system’s SIP proxy is processing messages.
sipmsg.log
This protocol trace log contains information about SIP messages that have been received, NAT’d, and sent by the SIP proxy. MIBOCO messages sent and received by the sipd process are also contained in this log.
log.SSH0-4
This log contains information about SSH processes. You can have one log for each instance.
log.bcm
This log contains information about the Business Call Management (BCM) logger used with the system to process call detail records (CDR).
log.ebmd
This log contains information about Common Open Policy Service (COPS) and Call Admission Contol (CAC) on the system. It is information about the External Bandwidth Manager (Radius/Diameter).
syslog
The term syslog refers to the protocol used for the network logging of system and network events. syslog facilitates the transmission of event notification messages across networks. Given that, the syslog protocol can be used to allow remote log access.
The syslog message functionality lets you configure more than one syslog server, and set the facility marker value used in the messages sent to that syslog server independently. All syslog messages are sent to all configured syslog servers.
Note:
Oracle recommends configuring no more than eight syslog servers. As the number of configured syslog servers to which the system sends logs increases, the system performance might decrease.Configured syslog servers are keyed (identified uniquely) by IPv4 or IPv6 address and port combinations. The Oracle Communications Session Border Controller is able to send logs to multiple syslog servers on the same host.
Process Logs
Each individual process running on the system has its own process log and a server where the system sends those logs.
HA Switchover Log
The switchover log provides historical information about the role of a High Availability (HA) Oracle Communications Session Border Controller in an HA Oracle Communications Session Border Controller pair. This log lists the last 20 switchovers on an HA SBC. The switchover log is not persistent across reboot(s). The switchover log message appears in the information provided by the show health command, and it also appears immediately on the terminal screen when a switchover takes place.
Log Message Graphical Display on the SBC
The switchover log message displayed on the High Availability (HA) SBC that has moved from the Standby to the BecomingActive state (has assumed the active role) indicates the date and time that the switchover took place. It also indicates from which peer the active role was assumed and why. The peer displaying this message took the active role because a health score fell below a set threshold, because a timeout occurred, or because it was forced by a system administrator via the ACLI.
Refer to the following example of a switchover log for an HA SBC whose health score fell below a configured threshold.
ORACLE# Mar 28 16:36:38.226: Standby to BecomingActive, active peer ORACLE2 has unacceptable health (50)
ORACLE#Refer to the following example of a switchover log for an HA SBC that has timed out.
ORACLE# Mar 29 13:42:12.124: Standby to BecomingActive, active peer ORACLE2 has timed out
ORACLE#The peer relinquishing the active role (becoming the standby system in the HA SBC pair) also displays the date and time that the switchover took place. The peer also indicates that it has moved from the Active to the RelinquishingActive state.
Refer to the following example of a switchover log for an HA SBC that is relinquishing its active role.
ORACLE2# Mar 28 16:38:08.321: Active to RelinquishingActive
ORACLE2#