Applies to
Summary
ApexSQL Audit is composed of light, unpretentious product architecture that can easily run in any given SQL Server environment with minimal configuration and impact. The entirety of ApexSQL Audit components run independently (separately) from the SQL Server processes, and does not add or modify native SQL Server files or services.
Architecture overview
Behind the single point of the access user interface, ApexSQL Audit provides a robust and simple product architecture that suits your environment regardless of the complexity level.
The below diagram visually interpret the ApexSQL Audit components and architecture:
Components description
Below, you can find more contextual and detailed information about the product components that are illustrated in the diagram above.
Application management console
The application interface is a comprehensive and easy-to-use console to configure auditing policies, create and run audit reports. The graphical user interface is a single point of access to both audit and configuration data, and as such also provides:
- A quick overview of the audit activities and audited instance status in real-time
- Access management to audit and configuration and determine the level of accessibility based on application roles
- Provide the history of user activities and configuration changes
- Demonstrate data integrity and compliance using reports
- Remote access from any client host in a domain
To get more in-depth information about the user interface, please consult this screen-shot tour article.
Central components
Central components are centralized processing units that do the following:
- Save auditing and configuration data into the Central repository database
- Send configuration updates to auditing components
- Communicate with the GUI to feed it with status, report, and alert data
- Execute scheduled activities – run the reports on a schedule, archive central repository data
- Raise e-mail notifications on alerts, report schedules, archiving, and other activities associated with e-mail notifications
The central components are composed of ApexSQL Server-side components which is a Windows service that is used to manage the ApexSQL Audit Processor Central background process on the Central instance client host. The ApexSQL Audit Processor Central is running under a specified Windows login that is used as authority to interact with the Central Repository Database and File System of the central instance and require certain permissions to be met.
Central repository database
The central repository database is a SQL Server database that is used to:
- Store configuration data such as configuration audit settings and history of changes, application users, and roles
- Store SQL Server auditing data in the tamper-evident form
Central repository database actively store the incoming data sets over time and can be also archived which creates an archive database that plays an inactive role in terms of writing new data but it can be used as a data source to read it while creating audit reports.
Auditing components
Auditing components are distributed processing units that interact with the Central components and the registered SQL instances to collect the auditing data and further send it to the Central repository database for data-keeping.
Auditing components consist of ApexSQL Server-side components which is a Windows service that manages the data collecting agent that is interpreted as the background ApexSQL Audit Processor Distributed Windows process. The collecting data agent is running under a specified Windows login that is used as authority to interact with the audited SQL Server and the File System of the audited instance. The Windows login used to authorize data collector activities requires the following permission set.
Audit data is collected from the session flat files that SQL Server feeds with the data based on the applied audit settings.
Temporary files locations
Temporary files location is a File System destination used to temporarily store data throughout the auditing data processing before it eventually is stored in a central repository database.
On the audited instance side, auditing data is stored on the File System as a session flat-file that is temporarily stored before the collecting agent consumes it and forwards the data to the central instance.
Temporary file location on the central instance is used as a buffer to load pending data stream in the central repository database in cases when the data stream is greater than the volume central components can write concurrently in a central repository database.
For an in-depth data flow overview and to learn more about components specifications, usage scenarios, and data security please consult this SQL auditing and data flow article.
