What is the Nodinite Logging Service?
Unlock full visibility and control over your business transactions with the Nodinite Logging Service. This powerful service enables secure, searchable, and auditable logging of all events and messages, empowering your organization to meet compliance, performance, and business intelligence goals.
What you'll gain from this page:
✅ Instantly search and analyze all logged business transactions
✅ Re-index historical data to add new search fields or KPIs
✅ Built-in archiving and encryption for compliance and data protection
✅ Seamless integration with Microsoft BizTalk Server and custom solutions
✅ Real-time statistics, KPIs, and alerts for proactive decision-making
Throw away your crystal ball! With Nodinite you don't have to know everything in advance—everything logged can be reindexed. Make sure you log everything(!) The benefits of having Nodinite log all your business transactions are plentiful. For starters:
- You get Statistics and KPIs
- You can find your data and your errors
- You can get alerts for Non-Events
- You have the best data possible for decision support reports
- You can re-index if you find out that you need yet another Search Field
- You can create payment models if you need to split the costs for your system integration solutions based on your KPIs
In Nodinite v7 on Windows, the Logging Service is deployed as part of the Core Services web site/application stack installed and updated with the Core Services package. See Prerequisites for pre-installation related information.
| Protects your data | Archive | Find your data |
|---|---|---|
| Nodinite encrypts your data and the only way to read is through log audited operations | Archiving is built-in, store as much data as your business deems | Smart re-indexing support gives you the power to find what you are looking for even if it's old data |
Nodinite Logging Service is responsible for processing and reprocessing events and messages that have been logged by either the Nodinite Log Agents or from other solutions with your custom code using the Nodinite Asynchronous Logging pattern.
Diagram: The Logging Service processes, re-indexes, encrypts, deletes, shrinks, and rebuilds indexes for all logged data, supporting multiple BizTalk environments.
The Logging Service is your cleaning operative and keeps Nodinite at its best
Key System Parameters for Logging Service
Use these pages to tune processing throughput, retention, cleanup, and Log Database growth behavior directly from the Logging Service documentation:
- MessageProcessingBatchSize - Number of items processed per batch
- MessageProcessingMaxBodySize - Maximum message body size for processing
- MessageProcessingTimerInterval - Processing frequency interval
- CleanUpTimerInterval - Cleanup frequency for expired data
- DatabaseMaintenance - Automated reindex and shrink operations
- DaysToKeepMessageEventsDefault - Retention for message events
- DaysToKeepMessageDataDefault - Retention for message data/payload
- DaysToKeepMessageContextDefault - Retention for message context
- DaysToKeepErrorEventsWithoutData - Retention for error events without data
- DaysToKeepLogAudits - Retention for log audits
- DaysToSplitDatabaseOn - Time-based Log Database split threshold
- SizeToSplitDatabaseOn - Size-based Log Database split threshold
- LogLocations - Data and transaction log placement
- LogDatabaseName - Naming pattern for Log Databases
- LogDatabaseRecovery - Recovery model configuration
For operational cleanup automation, see Automating removal of old Log Databases.
Data Management
The Logging Service is the component responsible for everything that happens to data after it is ingested — processing, indexing, encryption, retention enforcement, archiving, and disposal. This section provides a consolidated overview for compliance and data governance purposes.
Data Ownership
All data stored in Nodinite is owned exclusively by the customer. Nodinite as a vendor:
- Has no access to any customer data — data never leaves the customer's infrastructure
- Does not replicate, transmit, or back up customer data to third-party systems
- Cannot initiate any read or write operation against the customer's SQL databases
Data ownership is governed entirely by the customer's own data classification and information security policies.
Data Sensitivity
Nodinite treats all logged data as potentially sensitive and applies the following controls:
- Encryption at rest – Message payload and context data can be encrypted in the Log Database. The only way to read encrypted data is through audited operations in the Web Client
- Role-based access – All data access goes through the [Web API][] and requires an authenticated session with [role-based permissions][Roles]. No direct database access is granted to end users
- Log Audits – All sensitive read operations (viewing message payloads, search results) are recorded in the audit log for compliance traceability
Data Retention
Retention is configured per data type using system parameters managed by the customer's administrator. The Logging Service enforces deletion automatically on the configured interval:
| Data Type | System Parameter | What is Controlled |
|---|---|---|
| Message events (transaction records) | DaysToKeepMessageEventsDefault | How many days to keep log event entries |
| Message data (payloads/bodies) | DaysToKeepMessageDataDefault | How many days to retain message content |
| Message context (search field values) | DaysToKeepMessageContextDefault | How many days to retain extracted context data |
| Error events without data | DaysToKeepErrorEventsWithoutData | Retention for failed events with no payload |
| Log audit records | DaysToKeepLogAudits | Retention for the audit trail itself |
Retention can be set independently per type, allowing shorter retention for large payloads (cost/storage) and longer retention for lightweight audit records (compliance).
Tip
Configure
DaysToKeepMessageDataDefaultto a shorter window thanDaysToKeepMessageEventsDefaultif you need to retain a record that a transaction occurred (the event) without keeping the full payload — common for GDPR and data minimisation requirements.
Access Audit Logging
Nodinite provides comprehensive audit logging of all sensitive data access, meeting compliance requirements for monitoring and detecting unauthorized access:
- Who accessed what – Audit logs record user identity, data accessed (entity ID, log event ID), timestamp, and action (view, search, download)
- When access occurred – Each operation records exact timestamp in UTC with timezone conversion for user reference
- Search & filter operations logged – All search queries (including filters, date ranges, entity types) are audited. Search refinements are recorded separately
- Sensitive payload access tracked – Viewing encrypted or masked payloads, exporting data, and running reports all generate audit records
- Modification & disposal logged – Manual data deletion, purge operations, and retention policy enforcement are recorded in audit logs
- User context preserved – Audit logs link each action to authenticated user account (Windows domain\username or OAuth subject)
- Tamper-evident design – Audit logs themselves are subject to retention policy (see DaysToKeepLogAudits) and cannot be deleted by individual users — only administrators can modify audit retention settings
Audit Log Retention:
By default, audit records are retained per the DaysToKeepLogAudits system parameter (typically 90 days). This ensures:
- Compliance window – Audit trails available for 90 days post-access for investigation and compliance audits
- Integrity verification – Long retention allows detection of suspicious patterns (e.g., after-hours access, bulk downloads)
- Forensics capability – Security team can trace data access history for compliance audits and incident investigation
See [Administration - Log Management][] for viewing and exporting audit reports.
Data Disposal
Disposal is automatic and operates at two levels:
- Row-level deletion — The Logging Service deletes individual log records that have exceeded their configured
DaysToKeep*threshold on each CleanUpTimerInterval cycle. No manual intervention is required - Database-level disposal — When a Log Database grows beyond SizeToSplitDatabaseOn or DaysToSplitDatabaseOn, a new database is created automatically. Old, fully-expired databases can be removed entirely using the Automating Log Database Cleanup procedure, which drops the entire SQL database once all its data has exceeded retention
Note
Because Nodinite runs on the customer's own SQL Server infrastructure, final physical disposal (e.g., secure drive erasure, database file deletion, backup tape destruction) is the responsibility of the customer's database and infrastructure team under their own data disposal policy.
Features - Tune the Logging Service to suit your needs and environment
- Logging from BizTalk - Get insights into your business transactions by logging all events from Microsoft BizTalk Server to Nodinite (in and out events with payload and context) without making changes to the existing BizTalk solutions using the built-in tracking capabilities
Logging from Microsoft BizTalk Server
Nodinite Logging Service supports logging from your Microsoft BizTalk Servers where global tracking is enabled. You can concentrate all BizTalk environments to a single Nodinite instance.
To keep performance goals and to scale, the Logging Service runs one thread per environment with your user-defined environment-specific settings. Nodinite supports multiple versions of BizTalk.
Diagram: Each BizTalk environment is handled by a dedicated LogAgent instance, ensuring scalable, environment-specific logging and synchronization.
The Logging Service hosts one thread (WorkerItem) for each configured BizTalk Environment (group) to log from
This topic is further detailed in the Logging from BizTalk.
Performance
The performance of this service heavily depends on the current workload on CPU, memory, network, SQL, and disk IO on involved machines.
User Configuration that affects processing comes from Message Types and Search Fields. The amount of work also depends on the size of the payload/Context, the current amount of data in the Log Database, and the current workload.
We have started to gather a list of KPIs, please feel free to contribute:
| Average processing time | Number of messages/second | SQL Disk Read performance MB/s (Volume for FileGroup Index) | SQL Disk Write performance MB/s (Volume for FileGroup Index) | #SQL Cores | #Cores Logging Service | #RAM SQL GB (memory limited) | #RAM Logging Service GB | Comment |
|---|---|---|---|---|---|---|---|---|
| 32 ms | >30 | >1350 | >52 | 2 | 2 | 7 | 7 | Azure Demo environment |
Frequently asked questions
Additional solutions to common problems and the Nodinite Logging Service FAQ exist in the Troubleshooting user guide.
How do I know if the Logging Service has stopped?
Information about the current state of the Logging Service is available for a Nodinite end-user in the following locations:
- The notification area of the Web Client

Status icon in the Nodinite Web Client notification area - From the Overview in the Administration of the Web Client

Logging Service status in the Nodinite Web Client Administration Overview - On the Update page of the Install and Update Tool
How do I know where the Logging Service is installed?
The actual whereabouts of the Logging Service can be found in the following places:
- From the Overview in the Administration of the Web Client (and all other installed components)
- On the Update page of the Install and Update Tool (Core Services)
How do I enable Logging from Microsoft BizTalk Server?
This topic is further detailed on the 'Logging from BizTalk' page.
Next Step
Related Topics
Monitoring Service
Message Types
System Parameters
Search Fields