Monitor settings
Explains all Monitor Settings including GPDR relevant settings, Call History (CDR), Databases and Event Log settings.
Enter Monitor Settings
To access the Monitor Settings, switch from Monitor Mode to Configuration Mode after logging into your anynode.
Navigate to Extras and choose Monitor Settings.
Call history settings
The call history tab allows you to configure data storage, cleanup, and database usage. The call history is a collection of Call Detail Records (CDR), which are also used to display various statistics in the anynode monitor.
The call history can display details on the SIP call flow and timestamps.
anynode stores call history by default and automatically deletes the oldest record during the cleanup cycle when the maximum number of records, which is set to 500,000 per default, is reached. The call statistics displayed in monitor mode are also affected by this. This ensures that the call history records remain at 500,000. If there are only records from the last month available, you can only view the statistics for that period.
You can select a value between 10,000 and 2,147,483,647 records.
A database with 500,000 entries, mostly only the source and destination dial strings are saved, has around 500MB. But this size can vary with how much Information is in every CDR entry. If Asserted-Headers, Custom-Headers, Redirect-History, and other information is saved, it can use more space.
This activity will create an event log entry with ID 123, including the maximum value and the number of deleted records.
The maximum retention time determines how long a record is retained. This value is not affected by the maximum number of records option. Deletion time is determined by the condition that is met first. The default time is set to unlimited.
This activity will create an event log entry with ID 124, including the maximum number of days and the number of deleted records.
The maximum retention time for recorded files is the length of time a media recording file is kept in a call history entry.
The associated recordings are also deleted when a call history record is deleted. The default time before deleting the recordings is set to unlimited.
This activity will create an event log entry with ID 125, including the maximum number of days and the number of deleted recordings.
It has no effect when this number exceeds the Maximum retention time for call history entries.
The value of the Cleanup Interval specifies how often the call history database should be checked to determine whether a deletion condition has been met. The default is 1440 minutes before the next check. The interval starts with starting the anynode monitor service.
The Custom SIP header name field is used to put fixed SIP Headers including fixed values into call history records. This can be useful to distinguish call history records in a human readable format from each other when a database is used for multiple anynode instances with an external Database.
With the Custom SIP header names option, you can add extra headers to the call history. Some providers or IP devices require user-specific X-headers for billing or authorization purposes. You can store these headers in the call history for future use. If you have more than one header, each header should be on a separate line. The format in the database is JSON, like this:
Before using a custom header, anynode needs to know which headers will be forwarded to the next node.
You can configure this in the Routing Forward Profiles -> Telephony Forwarding -> Additional forwarding settings.
Every X-Header must be listed before this header is forwarded and added to the CDR record.
With anynode Release 4.12, you have the Store signaling messages option, where you can save the SIP Flow of each call in the CDR database. The SIP flow can help you analyze a call without a trace file. No media or other details are included.You can download the SIP messages as HTML, PCAP, JSON, text file showing the message flow and textfile showing the messages.
The Maximum message length in bytes can restrict the data of a single flow because SIP messages can be very large in some situations. With the Maximum retention time for messages, you can set the time in days before the SIP flow message is deleted.
You can clear the call history and statistics with one click on button. A confirmation prompt will ask you to verify the clearing of the call history.
This function resets a whole table in an external database as well. If multiple anynode instances share the same database, the data of all will be erased.
This removes all call history and statistics entries from the database, including Global Statistics, Route Statistics, and Node Statistics. You can see these statistics in the statistics tab of Monitor Mode. The activity will generate an event log entry with ID 122 that includes the username and IP address of who did this.
You cannot undo a cleared Call History. Make sure you back up before.
Configure database for Call history
To configure the call history database or change the optimization mode of the current database, open the option.
anynode uses an internal database for the call history by default. This database is an SQLite database, and is named anynodeCallHistory.db on both systems (Windows and Linux).
In Microsoft Windows it is saved in the following directory:
C:\ProgramData\TE-SYSTEMS\anynode monitor\storage\databases
For Linux the following directory is used:
/var/opt/tesystems/anynodemon/storage/databases/
When you use an external database, you can change its name. The default name is anynodeCallHistory. Changing the name will store new events there, but not move old events. To initialize the database and create the required tables, select Initialize database.
You need to enter the hostname, port, and credentials to connect, depending on the database type. PostgreSQL allows additional parameters for the connection.
Use the button to check the connection with all parameters. This confirms that the database user has permission to create or reset databases, tables, and records. If the connection fails, you can see the error details in the state area. If the connection fails later in production due to infrastructure changes, anynode will create an event log entry with ID 130 that includes the database name and a specific error message.
As additional info, you will find an error message at the top right corner of the anynode user interface showing a connection error.
The reconnect interval sets the time between anynode’s attempts to reconnect after losing the connection and to keep it alive.
Remember, when the database connection fails, anynode will write new entries to the RAM until it reconnects.
If a connection disconnects, anynode will create an event log entry with ID 131 that includes the database name and a specific error message from the database. When the connection succeeds again, an event with ID 132 will be created.
When choosing an external database for CDR, the records can be kept apart by anynode's System Identifier. This is useful if the same database is used for different anynodes. The System Identifier can be found in the Information tab of anynode.
By default, the Optimization mode for all database types is set to Insert Optimization. This means that anynode will create an index in the database, regardless of the database type used, to ensure fast insertion of new records.
The Query Optimization mode is used to query records more quickly by indexing the StartTimeStamp column in the databases. This helps to filter Call History entries more efficiently, but it can also lead to slower performance in other areas.
Event log settings
All types of activity are recorded in the Event log. This log can trace activities such as changes to configuration, losing connections, or user activities.
In the Event log settings, you can set the maximum size of the event log, enable or disable the anynode and system logs, include or exclude events, and configure conditional events.
The event log has a default maximum size of 10 MB, which is usually enough. You can increase the size if needed. When the log is full, the oldest entries are removed.
This limit is only for the internal database. For an external database, we estimate the limit by assuming 200 bytes per event, since we don’t know the exact size.
The Log enabled option is on by default. If you turn it off, anynode will not write events to the event log in Monitor Mode. The Log system enabled option lets you write events to the OS-specific event log. This can be either the Windows Event log or the Linux syslog. In Windows, you can see the entries in the Event viewer of the OS. Look for the Windows log with the source anynodemon.
Syslog is a protocol for collecting and forwarding messages from devices such as anynode SBC to a server running a syslog daemon. Syslog normally uses UDP port 514 for communication. Syslog servers provide a central logging facility and long-term protected storage for logs, which is useful for routine troubleshooting and incident handling.
Please note that Debian 12 has completely replaced syslog with journalctl. However, it remains compatible
with anynode.
You can use either the internal or external log to monitor all activities, depending on your preferences. Some companies already have a monitoring tool for the Windows event log and can integrate these messages easily. You can clear the Event log with one click on button. A confirmation prompt will ask you to verify the clearing of the log.
This function resets a whole table in an external database as well. If multiple anynode shares the same database, the data of all anynodes will be erased.
This removes all log entries from the database. This activity will create an event log entry with ID 121 including the username and IP address of who performed this.
You cannot undo a cleared Event log. Make sure you back up before.
Configure the database for the Event log
anynode uses the internal SQLite database for events by default. The database has a default limit of 10MB. If this limit is reached, older events will be deleted to make room for newer ones.
When you use an external database, you can change its name. The default name is anynodeEvents. Changing the name will store new events there, but not move old events. To initialize the database and create the required tables, select Initialize database.
You need to enter the hostname, port, and credentials to connect, depending on the database type. PostgreSQL allows additional parameters for the connection. Use the button to check the connection with all parameters. This confirms that the database user has permission to create or reset databases, tables, and records. If the connection fails, you can see the error details in the state area. If the connection fails later in production due to infrastructure changes, anynode will create an event log entry with ID 135 that includes the database name and a specific error message.
The reconnect interval sets the time between anynode’s attempts to reconnect after losing the connection and to keep it alive.
Remember, when the database connection fails, anynode will write new entries to the RAM until it reconnects.
If a connection disconnects, anynode will create an event log entry with ID 136 that includes the database name and a specific error message from the database. When the connection succeeds again, an event with ID 137 will be created.
Include and Exclude events in the Event log
To log only certain events or exclude some, turn on the Only log specific events option. Click for the option you want to open the event options.
Pick the events to include or exclude. You can filter by categories or use the Message filter field to search for the events you want. This feature helps to lower the number of events that anynode creates. If you use external logging, you may only want messages out of the error category.
Conditional events
Conditions are a powerful feature to keep track of the anynode installation. Based on conditions you can optimize routing or other traffic decisions. anynode allows events based on a condition set within the platform. Whenever a condition matches a specific value, an event can be written into the event log. Based on this entry, a third-party application that monitors the event log can create new activity or alarm.
To add a new conditional event, click the button and define the severity and message for when the condition is true or false.
The best practice for severities is using a warning or error message whenever the condition comes true. When the condition is back to normal an informational warning is used.
The three different severity states are:
-
Error
-
Warning
-
Information
After creating a conditional event, both the true and false states receive their own event ID. If you only work with included events, be sure to include the event ID in the included events list.
Conditional Event IDs starting at 10.000
The Monitor configuration in the Event Log tab displays a list of all defined conditional events, which can be selected for removal or editing.
Licenses
anynode will alert you if your license is about to expire. Configure when anynode should issue warnings, including critical warnings, and how often they should be repeated.
anynode will log an event with ID 300 when the warning level is reached, showing the license name and the days this license will stay valid. When the expiration days fall below the critical level, anynode will log an error event with ID 301.
anynode will issue a warning 15 days before a license expires and a critical warning 7 days before expiration. By default, these warnings are not repeated, but the frequency can be adjusted.
After the license is expired, anynode will log an event with ID 304, showing the license name and the days this license is expired.
Certificates
anynode will alert you if a certificate is about to expire. Configure when anynode should issue warnings, including critical warnings, and how often they should be repeated.
anynode will log an event with ID 302 when the warning level is reached, showing the serial number and the days this certificate will stay valid. When the expiration days fall below the critical level, anynode will log an error event with ID 303.
Per default configuration, anynode issues a warning 30 days before a certificate expires and repeats the warning every three days by default. The critical warning time is set to 14 days before expiration. The warning frequency can be adjusted to generate warnings after a different number of days. A warning will not be repeated if set to 0 days.
After the certificate is expired, anynode will log an event with ID 305, showing the serial number and the days this certificate is expires.
To avoid expiration and renew certificates on time, anynode has the built-in ACME service that many certificate authorities support. By default, anynode refreshes certificates five days before they expire when you use the certificate issuance function.
Active sessions
In Monitor Mode, the Active Sessions tab displays any active session for a specified time after the call has been disconnected. This is useful if the call immediately disconnects because the user is busy, or the destination is not reachable.
The default time is set to five seconds, which can be adjusted to your personal preference. If set to 0 seconds, the call will be removed immediately upon disconnection.
Some countries have specific regulations like DSGVO or GDPR for storing personal data. anynode can anonymize entries in the call history and in the active calls overview. By configuring a specific number of digits to be anonymized, the corresponding number of phone numbers and user parts will be replaced with XX's from the right side. This means, +49536381950 would be changed to +49536381XXX when Anonymize address digits are set to 3.
If the Anonymize address digits setting is not set to 0, display names and numbers in the call history and in the active sessions tab will be anonymized using X's.
After changing the anonymize option, all future entries will be written with the X characters. All old entries will stay with the full number. Keep in mind this is not reversible.
Disk Space
anynode will warn you if you run out of disk space.
anynode only warns about the disk space of the path where it is installed.
Set when anynode should warn you, including critical errors, and how often to repeat them. anynode will log an event with ID 80 when the warning level is reached, showing the available space.
When the space falls below the critical level, anynode will log an error event with ID 81, showing the available space. anynode will warn you when the disk space is low, with a default limit of 2048 MB. The default critical limit is 1024 MB. These warnings are repeated daily by default, but you can change the frequency. A value of 0 means no repeat warnings.
