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 Server, the Logging Service is one of the Core Services: its own IIS web site, on a port and with a service identity that you set in the Nodinite Portal (Step 4: Servers). It is installed and updated with the generated Core Services package. See Prerequisites for the SQL Server, Windows, and firewall requirements.

Nodinite Logging Service is responsible for processing and reprocessing the Log Events and messages that have been logged by either the Nodinite Log Agents, the Log API, or from other solutions with your custom code using the Nodinite Asynchronous Logging pattern. It reads its settings from the Configuration Database and stores the processed data in the Log Databases, which it also creates, splits, cleans, and maintains.

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

The Logging Service reads the following System Parameters from the Configuration Database. This table is the one list of them; the other Logging Service pages link here. Change a value in the Web Client under Administration › Settings › System Parameters, as described in Manage System Parameters. No System Parameter needs a restart: the service picks up a new value within about 15 seconds, and each parameter page states when a change takes effect.

System Parameters read by the Logging Service, grouped by purpose.

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. 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 set by System Parameters. The three DaysToKeepMessage*Default values only seed each new Message Type; after that, each Message Type's own Days to keep values apply, which you change in Add or manage Message Type. Changing a default never affects existing Message Types. The Logging Service deletes expired data on each cleanup run:

Monitor Events are not part of this cleanup: the Monitoring Service purges them hourly, based on DaysToKeepMonitorEvents.

Tip

Configure DaysToKeepMessageDataDefault to a shorter window than DaysToKeepMessageEventsDefault if 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 (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 Log Audit Search 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 worker thread 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:

Message Processing

The Logging Service checks the active Log Database for unprocessed Log Events every 30 seconds, and the archive Log Databases every 5 minutes (fixed intervals; MessageProcessingTimerInterval has no effect). Each run fetches batches of MessageProcessingBatchSize Log Events until the backlog is empty, and processes each batch with at most 25 threads. For each Log Event it determines the Message Type, extracts Search Field values with the expressions bound to that Message Type, and marks the event as processed. Messages larger than MessageProcessingMaxBodySize are not processed; they get the Error processing state, a Comment, and a Log Audit entry. For BizTalk Server, a body over the limit is not copied at all; the event is processed from its context and gets the Completed with warnings processing state.

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:

1. The notification area of the Web Client
   
   Status icon in the Nodinite Web Client notification area
2. From the Overview in the Administration of the Web Client
   
   Logging Service status in the Nodinite Web Client Administration Overview

On the server, check that the Logging Service IIS web site and its application pool are started. The Troubleshooting page lists more checks.

How do I know where the Logging Service is installed?

The actual whereabouts of the Logging Service can be found in the following places:

1. From the Overview in the Administration of the Web Client (and all other installed Core Services)
2. In the Nodinite Portal, on the environment's Step 4: Servers page: the server that hosts the Core Services, the install path, and the Logging Service port

How do I enable Logging from Microsoft BizTalk Server?

This topic is further detailed on the 'Logging from BizTalk' page.

Note

Nodinite v6 is no longer supported. To move an existing v6 installation, follow Updating from v6 to v7.

Next Steps

• Prerequisites
• Install Logging Service
• Managing Logging Service
• Manage System Parameters

Related Topics

• Core Services
• Configuration Database
• Log Databases
• Log API
• Web API
• Monitoring Service
• Message Types
• System Parameters
• Search Fields
• Update Logging Service
• Troubleshooting