Audit Logs Viewer

S
Written by Sergiiy
Updated 1 year ago

General information

Audit log is a subsystem that records events on the Softswitch, with ability to filter by name/type/date.

It provides switch operator a tool to troubleshoot and investigate what changes were done, by whom and when to numerous components of the system, including Accounts, Customers, Tariffs etc.

Location on the Softswitch

The Audit Logs Viewer feature is available only for web users with Administrator privileges under Root Customer and can be accessed from System Management --> Tools --> Audit Logs Viewer

FlySip also has

Elements legend

Filter section:

  • Resource - WHERE the event happened
  • Action - WHAT exactly happened
  • Action by - WHO accessed the page/did the changes
  • Start Date/Time, End Date/Time  - WHEN the event happened

Data section:

  • Resource - WHERE the event happened. Contains the reference to affected subsystem, e.g. accounts or tariffs with corresponding ID of element that was touched.
  • Action - WHAT exactly happened. Hover mouse button to the action to get pop-up hint. List of actions with description and syntax could be found in table below:
Event Action Resource
Add a record to a table A table_name:key1=val1[,key2=val2...]:field1=newval1
Update a record U table_name:key1=val1[,key2=val2...]:field1=newval1
Delete record D table_name:key1=val1[,key2=val2...]
Restore record R table_name:key1=val1[,key2=val2...]
Successful auth AUTH_OK customer|account|vendor:username|email=value
Bad auth AUTH_FAIL customer|account|vendor:username|email=value
Successful auth using OTP AUTH_OTP customer|account|vendor:username|email=value
Reset one time password OTP_RST customer|account|vendor|system:
username|i_customer|i_accout|i_vendor
Web Password change PSWD_CHNG i_customer|i_web_user|i_account|i_vendor=id
Add funds/Debit/Credit FUNDS add|credit|debit|recharge:i_customer|i_account|i_vendor=
id:amount|voucher_id=val
Disconnect call CALL_DISC i_call|i_account=id
Billing run BRUN i_account=id
Billing restart BRSTRT i_account=id
Queue an action Q table_name:key1=val1[,key2=val2...]:field1=newval1
Execute an action E table_name:key1=val1[,key2=val2...]:field1=newval1
Clear First Use timestamp CLR_FSTUSE accounts:i_accout=id
Extend Lifetime EXT_LFTM accounts:i_accout=id
Issue SSL Certificate SSLCRT_ISS i_environment=id
Open TCP 80 port FW_OPEN80 i_environment=id
XMLAPI relayed to
another environment
RELAYED i_environment=id,method=methodName
[,methodSpecificResource]
MFA required MFA_RQRD customer|vendor|web_user:username:MFA_type
MFA pending until setup done MFA_PEND customer|vendor|web_user:username:MFA_type
[:MFA_type_specific]
MFA setup done MFA_SETUP customer|vendor|web_user:username:MFA_type
[:MFA_type_specific]
MFA verification passed MFA_VRFY customer|vendor|web_user:username:MFA_type
[:MFA_type_specific]
MFA required, but failed MFA_FAIL customer|vendor|web_user:username:MFA_type
Reset MFA configs,
tokens and validations
for ALL users
MFA_RST system
Reset MFA configs,
tokens and validations
for a specific user
MFA_RSTUSR user_type=type,user_id=id

  •  Action by - WHO accessed the page/did the changes. Example of syntax:

1. [letter that corresponds to system unit]:

  • u for Web Users
  • a for Accounts
  • c for Customers
  • v for Vendors
  • t for trusted XMLAPI call

2. [id of the entity]

e.g. for Web users it would be i_customer that owns this Web User. For Accounts, Customers, Vendors it would be i_account, i_customer, i_vendor correspondingly. For trusted xmlapi there would be 0.

3. [id of sub entry]

e.g. for Web users it would be i_web_user. For Accounts, Customers, Vendors, trusted xmlapi there would be 0.

4. [name of entry]

e.g. for Web users, Customers and Vendors it would have Web Login of Web User, Customer, Vendor correspondingly. For Accounts - Username, for trusted xmlapi there would be IP address of the Environment.

Examples:

u:1:3726:main_admin 

v:105532:0:1743624'22

c:1:0:000123

t:0:0:2.2.2.2

  • Date - WHEN the event happened. Date is displayed in timezone of web user that checks the Audit log
  • User IP/Node - where the request came from. Normally contains IP address of the user that participated in event, sometimes there could be a node-id of the system
Did this answer your question?