Announcement

Collapse
No announcement yet.

New Feature: Mirth logging replacement

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • New Feature: Mirth logging replacement

    Functionality
    This library eliminates Mirth logging limitations by replacing the logging mechanism.


    • All log messages created by a channel will be placed in a separate log file named like the channel itself.
    • Messages that are not caused by a channel (e.g. global deploy script) are logged to the standard log file mirth.log.
    • All messages on log level ERROR are accumulated in a specific log file called mirthErrors.log.
    • All messages that are logged to the console or administrator dashboard are enriched with the name of the channel causing the message.

    How to use:
    1. Copy the attached library MetaAppender.jar to the custom-lib subfolder of your mirth installation
    2. Add the following code to the global deploy script:
      Code:
      Packages.lu.hrs.mirth.MetaAppender.activate();
      (just needs to be called once after the service is started but multiple calls do not do harm)
    3. If you are using the function activateChannelLogging(), remove it or remove it's content if already referenced in many places
    4. restart the mirth service


    Customization:
    By default the logging configuration of log4j.properties in the subfolder .\config is used. It is however possible to overwrite certain parameters by providing them to the activate() call:

    Packages.lu.hrs.mirth.MetaAppender.activate(<customLogPath>, <customMaxFileSize>, <customMaxBackupIndex>, <customLogPattern>, <logAllToMainLog>);
    customLogPath - Defines a custom location for the log files
    customMaxFileSize - Defines a custom maximal size per log file
    customMaxBackupIndex - Defines a maximum number of log files that will be created per channel till the oldest is overwritten (round-robin)
    customLogPattern - Defines a custom structure for the log file entries
    logAllToMainLog - If this flag is set, all log entries (also channel-specific ones) will also be logged to the main log. (off by default)

    All parameter are optional and can be expressed by null. Tailing parameters can be omitted.

    Examples:
    Writes the channel-specific log entries in a custom structure:
    Code:
    Packages.lu.hrs.mirth.MetaAppender.activate(null, null, null, "%d %-5p %c: %m%n");
    Extends the size of all log files to 5MB and logs all channel data also to the main log file (mirth.log):
    Code:
    Packages.lu.hrs.mirth.MetaAppender.activate(null, '5MB', null, null, true);
    New Feature:
    If many channels are logging to the dashboard, you might want to focus on the log output of one specific channel if e.g. an issue occurs. This can be done by:
    Code:
    Packages.lu.hrs.mirth.MetaAppender.setFocus(<Channel name or id>);
    Focus can be removed by:
    Code:
    Packages.lu.hrs.mirth.MetaAppender.removeFocus();
    • Setting a focus does not influence the logging to the channel log-files.
    • If a focus is set, this is indicated by a "FOCUSED: "-prefix before the channel name of each log entry.



    Additional Information:
    • The meta appender "hijacks" the mirth logging mechanism and gains that way full control over all logging activities.
    • It thus substitutes the approach I posted some time ago. It overcomes all weaknesses of this initial approach (no exception logging to channel logs, no automated integration for transformers).
    • It solves all issues mentioned here in Mirth Jira
    • Source code is included in the jar file

    This project can now be found on GitHub
    Attached Files
    Last edited by odo; 02-13-2020, 01:19 AM. Reason: Added reference to GitHub-page (latest Version can be found there)

  • #2
    Thats awesome!

    Since it extends the Log4J appender, does it automatically rotate logs based on log4j.properties?

    What license is this code under?
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

    Comment


    • #3
      Originally posted by jbartels View Post
      Thats awesome!
      Thanx


      Originally posted by jbartels View Post
      Since it extends the Log4J appender, does it automatically rotate logs based on log4j.properties?
      Yes. It uses the configuration in .\conf\log4j.properties and .\conf\log4j-cli.properties as master for all logs (also the channel-specific ones).

      It can however be customized at runtime by providing the parameters described in the first post to the activate() call.


      Originally posted by jbartels View Post
      What license is this code under?
      MPL-1.1 (same as Mirth)

      Comment


      • #4
        Added "focus"-functionality to temporarily limit dashboard logging to a specific channel.

        View first post for details.

        Comment


        • #5
          Works like a charm! Really like it.
          I did have a problem getting it to run, don't know why. Got a null reference exception but no further info (was wrapped in the deploy script trace).
          Could not get it working until i changed one of the log levels to "WARN", i had them all on "ERROR".

          Comment


          • #6
            Originally posted by V3nn3tj3 View Post
            Works like a charm! Really like it.
            I did have a problem getting it to run, don't know why. Got a null reference exception but no further info (was wrapped in the deploy script trace).
            Could not get it working until i changed one of the log levels to "WARN", i had them all on "ERROR".
            That's strange as it should work out of the box w/o the need of any modification of the configuration file. But glad to read you got it working!

            Unfortunately I have not been able to reproduce this exception. What are your specs (mirth version, OS, Java version)? Are you able to reproduce the Exception with more details?

            Comment


            • #7
              It's awesome that is a way to extend the functionality of the Log4j Appender.

              I've tryed it at my mirth, but i getting an Transformer error when i call the logger function.
              Do you have any idea to fix this?
              I'm running a Mirth in the version 3.5.2.

              Here's the stacktrace of the exception:

              Transformer error
              ERROR MESSAGE: Error evaluating transformer
              com.mirth.connect.server.MirthJavascriptTransforme rException:
              CHANNEL: KOKKM_GenericMDM
              CONNECTOR: sourceConnector
              SCRIPT SOURCE:
              SOURCE CODE:
              725: var appender = appenderList.nextElement();
              726: // and look for a file appender
              727: if (appender instanceof org.apache.log4j.FileAppender){
              728: logPath = appender.getFile();
              729: // file appender was found, extract path
              730: var index = (logPath.lastIndexOf('/') != -1) ? logPath.lastIndexOf('/') : logPath.lastIndexOf('\\');
              731: logPath = logPath.substring(0, index + 1);
              732: break;
              733: }
              734: }
              LINE NUMBER: 730
              DETAILS: TypeError: Cannot call method "lastIndexOf" of null
              at f9f09143-96ce-4fb4-8087-54e59eb77428:730 (getLoggingPath)
              at f9f09143-96ce-4fb4-8087-54e59eb77428:698 (getChannelAppender)
              at f9f09143-96ce-4fb4-8087-54e59eb77428:666 (activateChannelLogging)
              at f9f09143-96ce-4fb4-8087-54e59eb77428:740
              at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.doCall(JavaS criptFilterTransformer.java:154)
              at com.mirth.connect.server.transformers.JavaScriptFi lterTransformer$FilterTransformerTask.doCall(JavaS criptFilterTransformer.java:119)
              at com.mirth.connect.server.util.javascript.JavaScrip tTask.call(JavaScriptTask.java:113)
              at java.util.concurrent.FutureTask.run(Unknown Source)
              at java.util.concurrent.ThreadPoolExecutor.runWorker( Unknown Source)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source)
              at java.lang.Thread.run(Unknown Source)

              Comment


              • #8
                The reason is that you are using my old approach - activateChannelLogging() - in parallel.

                This is neither necessary nor recommended. Please remove the activateChannelLogging() function or, if you already referenced it in many transformers, simply remove the content of the function. I will emphasize this in the first post.

                There is no need anymore to reference a function in the transformer or anywhere else (well besides once in the global deploy script) for activating advanced logging.

                (I also added further functionality to the jar for focusing and filtering of multiple channel logs on the dashboard. It will be released as soon as I get some time)
                Last edited by odo; 01-23-2020, 02:36 PM.

                Comment


                • #9
                  Yes, you're right. I had the activateChannelLogging() in several transformer.
                  Thanks! Now it's working.

                  Comment


                  • #10
                    Not able to redirect log file path

                    Thank you for developing this useful tool!

                    I am trying to use it to make accessing Mirth's logs easier so that I can use them in unit tests of my channels.

                    I am running Mirth 3.8.1 on Ubuntu 18.04.3 LTS.

                    I have installed the plugin and activated it in my global deploy script - I can see the channel-specific logs now being generated in /opt/mirthconnect/logs.

                    However, I am not able to get the customLogPath feature to work. I have tried quite a few different variations in my activation call, providing paths with a file name and without, in my home directory and in subfolders of Mirth's default logging folder:

                    Packages.lu.hrs.mirth.MetaAppender.activate("/opt/mirthconnect/logs/test/test.log");

                    However, the logs always just go to the default folder and default channel-specific log files.

                    Any advice would be much appreciated.

                    Comment


                    • #11
                      Originally posted by hheldenbrand View Post
                      However, I am not able to get the customLogPath feature to work. I have tried quite a few different variations in my activation call, providing paths with a file name and without, in my home directory and in subfolders of Mirth's default logging folder:

                      Packages.lu.hrs.mirth.MetaAppender.activate("/opt/mirthconnect/logs/test/test.log");

                      In the current version, the meta appender is only created once, at the first call (usually the 1st time the global deploy script is called).
                      All subsequent calls will returned the cached instance. This is done for performance reasons.


                      Thus, if you would like a custom log path, you would have to provide this parameter where activate is called the first time. Alternatively you can simply change the log path in the configuration file (<MIRTH HOME>\conf\log4j.properties)

                      This custom path is however used for all log files. The logfile names are fix. (e.g. log files of channels are named like the channel). Thus, please provide the logpath without a filename.


                      I might change the code in a future version to detect, when parameters are changed. This, however, comprises a potential risk as two alternating calls from different locations with different values e.g. for the logfile location might result in unwanted behavior.


                      EDIT: When I think about it: An additional feature similar to the focus() feature might be a feasible way for securely supporting custom locations for single log files. I will have a look at that as soon as I get some time.
                      Last edited by odo; 01-29-2020, 06:46 AM.

                      Comment


                      • #12
                        odo, have you considered uploading your source code to github?

                        Comment


                        • #13
                          Originally posted by agermano View Post
                          odo, have you considered uploading your source code to github?
                          Project is now available on GitHub

                          Comment


                          • #14
                            Awesome!

                            Comment

                            Working...
                            X