As MD Link runs, it logs messages pertaining to many different kinds of activity. When running the MD Link Studio, these logs are visible in the Studio's log window. When running the MD Link Server, the logs are written to MD Link's internal persistence database (viewable from the Monitor) and also to plain-text files in the logs sub-folder of the data folder.
Each log record has several fields. Some fields are present in all log records, and some are not. These are documented below.
This indicates the severity of the log record. There are five possible values for this: AUDIT, ERROR, WARN, INFO, and DEBUG.
AUDIT - Log messages at this level indicate incidents of system-wide significance. AUDIT-level incidents are not generally errors - in fact, they rarely are, in themselves - so the fact that this log level is "greater than" the ERROR level can be misleading.
Generally AUDIT incidents are initiated by users - for example, a solution being loaded, or a component suspended. Sometimes non-user-initiated incidents are logged at the audit level - for example, the periodic memory logging. AUDIT logs messages are never triggered by message traffic, so your MDLink instance will tend to produce the same (small) number of AUDIT log messages regardless of your message volume.
The AUDIT level is very low traffic and has a negligible impact on performance and disk space.
Technically, audit logs exist whether the solution is running in either the Studio or the Server, but audit logs tend to be irrelevant when the solution is running in the Studio.
This list of incidents logged at the AUDIT level is:
- Server start / stop
- Solution start / stop
- Component suspend / resume / reload
- Resubmit messages (bulk or individual)
- Clear queue / delete individual queue elements
- Modify queue element
- Global log filter level changed
- Manual purge
- Export / import messages from / into persistence database
- Solution upload / rename / delete
- Memory usage (logged periodically, rather than in response to a user action)
ERROR - Solution errors – for example, task execution failed. Unlike AUDIT logs, ERROR logs (as well as all log levels below it) are often initiated by message traffic - so your MDLink instance will tend to produce an amount of ERROR (and WARN, etc.) logs proportional to your message volume.
WARN - Potential issues – for example, that an HL7 Socket Event port could not be acquired for listening.
INFO - Information about the normal processing – for example, that an event fired or a task is being executed. The INFO log level includes a lot of information. In production, if performance or disk space are a concern, you should consider setting your log level to WARN or above.
DEBUG - Designed to help debug the solution – for example, this displays the pre-datamapping and post-datamapping input of execution of each task, as well as the output of each task. This log level is very verbose and should generally not be used in production, except for short-term problem solving.
This is simply the date and time that the log record was emitted. It has millisecond precision and is stored in the time zone of the machine on which the MD Link engine (or server) is running. Every log record has a date and time associated with it.
This is as ID assigned by the engine in order to keep track of solutions when multiple solutions are loaded. Since only the MD Link server (and not the Studio) can load more than one solution at a time, solution IDs are only shown in the server and monitor - not the Studio. Solution IDs look like this: SOLN0, SOLN1, SOLN2, etc. Some log records do not have a solution ID set. These log records are global to the engine and are usually about logging memory usage (a non-solution-specific issue) or similar.
This is an ID, assigned by the Studio at solution design time, which uniquely identifies a component, whether it's an event, task, or resource. Component IDs that refer to events start with 'E' (eg. E2), those that refer to tasks start with 'T' (eg. T3), and those that refer to resources start with 'R' (eg. R5). Not all log messages have a component ID, as not all log records originate from a particular component.
Component IDs are unique within a solution, but are not unique within the engine. That is - solution SOLN0 may have a component T5, and SOLN1 may also have a component T5, but no single solution can have two T5s.
This is a text string that the user can define in the Studio alongside each component's properties. This is also sometimes called the 'logging name' of a component. MD Link provides this field so that the user has a means to identify their components in a way that is more flexible than the MD Link-supplied component IDs. Nothing critical hinges on this name - unlike solution IDs and component IDs, which have ramifications regarding input queues and restoring from the database). This name is provided as a convenience only. The component names will not tend to be unique, unless one imposes a unique naming convention on them, manually. If you don't specify your own component name in the studio, the default will indicate the type of the component eg. 'Text Splitter Task'.
This field will be present only when the component ID field is present.
A transaction is a particular firing of an event and all of the consequences of that particular firing. Transaction IDs are assigned by the engine at runtime, as events fire. They are unique within a solution, start from 0 with the first event firing, and increase from there - eg. TRANS0, TRANS1, TRANS2, etc. If an event firing is assigned the transaction ID TRANS99, for example, then all of the log messages (and also persistence database activity) that are a consequence of this event firing will be tagged with TRANS99, too. This makes it easy for both the user to see the relations between log messages. Transaction IDs are also crucial to the engine's internal bookkeeping regarding the persistence database.
A transaction ID will be present when the log message pertains to a particular message. Log messages concerning things like solution loading / unloading, or component suspending / resuming, will not have a transaction ID. Log messages concerning things like task execution success or failure will have a transaction ID.
A queue element ID is assigned by the engine to each task input queue element that ever exists. Even if an input queue element exists only momentarily before being consumed by the task in question, it will have an queue element ID. The queue element ID is unique across the solution ID's lifetime. This is ensured from the way that queue element IDs are constructed by the engine. They contain the transaction ID, the ID of the task in question, and also the IDs of every upstream task in the chain of task executions that led to the creation of the input queue element in question.
Also reflected in queue element IDs is each task's ability to output more than one message for a single input message. Most tasks do not exploit this behaviour; those that do include the Custom Task (if coded as such), the Text Splitter Task (if the 'split input text into separate messages' option is enabled) and the JDBC Select Task (if the 'output one message per database row' option is enabled). For example with a queue element ID such as:
QELEMID-TRANS7-E2-T3-0-T4-9-T6
we know that this queue element ID resides in the input queue of task T6, and that this was caused by event E2 firing and causing executions of T3, then T4, then T6, in that order. The '0' after 'T3' identifies that this concerns the first (and possibly only) output message of that execution of task T3. The '9' after 'T4' indicates that task T4 output at least 10 messages on that execution, and this is the 10th.
Queue element IDs are also used to identify task outputs. The queue element ID of a task output is equal to the queue element ID of the input queue element that caused the task execution which resulted in that output.
The queue element ID field will generally be present when the transaction ID field is present.
Finally, the text field is the human-readable log message.