Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

The article refers to https://github.com/hivemq/helm-charts/tree/master/charts/hivemq-platform (HiveMQ Platform) version:

NAME                           	CHART VERSION	APP VERSION	DESCRIPTION
hivemq/hivemq-platform         	0.2.18       	4.30.0     	HiveMQ Platform Helm Chart (new)

The article explains how to deliver a customized logback.xml to the HiveMQ Platform containers.

\uD83D\uDCD8 Instructions

  1. Prepare the logback.xml and test it locally first.

  2. Create a configMap logback-configuration from the custom logback.xml configuration file:

    kubectl delete configMap logback-configuration --namespace hivemq
    kubectl create configMap logback-configuration --from-file logback.xml --namespace hivemq

  3. Override the default HiveMQ Logback folder by adding the element to the env array in the hivemq-platform’s values.yaml. The default Logback folder is /opt/hivemq/conf and the following example will override the default value with /opt/hivemq/logback-my-configuration:

    nodes:
  env:
    - name: HIVEMQ_LOGBACK_CONFIG_FOLDER
      value: /opt/hivemq/logback-my-configuration

  4. Add the element to the additionalVolumes array in the hivemq-platform’s values.yaml:

    additionalVolumes:
  - type: configMap
    name: logback-configuration
    mountName: logback-configuration
    containerName: hivemq
    path: /opt/hivemq/logback-my-configuration

  5. Execute the helm upgrade command to pick up the changes:

    helm upgrade my-broker --install hivemq/hivemq-platform --values hivemq-platform-values.yaml

If everything is correct the rolling restart will happen.

End-to-end test

Updating the logback.xml configuration file

In order to test end-to-end it is necessary first to apply the custom logback.xml configuration and then make sure it is applied. For example, it is possible to add a test log file to the logback configuration, which name differs from the standard log filenames. Then, if, after applying the new logback configuration the test log file exists, it proves that the new logback configuration is working. If the test log file does not exist, it denies that the new logback configuration is working. To add a test log file it is necessary to append the following to the logback.xml:

    <appender name="FILE2" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${hivemq.log.folder}/hivemqXXX.log</file>
        <append>true</append>

        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- daily rollover -->
            <fileNamePattern>${hivemq.log.folder}/hivemqXXX.%d{yyyy-MM-dd}.log</fileNamePattern>

            <!-- keep 30 days' worth of history -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%-30(%d %level)- %msg%n%ex</pattern>
        </encoder>
    </appender>

Note that everything is a copy of the hivemq.log configuration except of the test log file name, which is hivemqXXX.log instead of the usual hivemq.log.

In order to write the actual data to the log you need to update the following section in the logback.xml:

    <root level="${HIVEMQ_LOG_LEVEL:-INFO}">
        <appender-ref ref="FILE"/>
        <appender-ref ref="FILE2"/>
        <appender-ref ref="CONSOLE"/>
    </root>

This will write the hivemq log not only into the default FILE but also into the test log FILE2.

The example logback.xml is attached hereby:

  1. Create a configMap logback-configuration from the custom logback.xml configuration file:

    kubectl delete configMap logback-configuration --namespace hivemq
    kubectl create configMap logback-configuration --from-file logback.xml --namespace hivemq

  2. Override the default HiveMQ Logback folder by adding the element to the env array in the hivemq-platform’s values.yaml. The default Logback folder is /opt/hivemq/conf and the following example will override the default value with /opt/hivemq/logback-my-configuration:

    nodes:
  env:
    - name: HIVEMQ_LOGBACK_CONFIG_FOLDER
      value: /opt/hivemq/logback-my-configuration

  3. Edit the values.yaml, add a new element to the additionalVolumes array in the hivemq-platform’s values.yaml:

    additionalVolumes:
  - type: configMap
    name: logback-configuration
    mountName: logback-configuration
    containerName: hivemq
    path: /opt/hivemq/logback-my-configuration

  4. Execute the helm upgrade command to pick up the changes:

    helm upgrade my-broker --install hivemq/hivemq-platform --values hivemq-platform-values.yaml

  5. Check the container for the test log file:

    kubectl exec pod/broker-0 -c hivemq -- ls -la log

    If there is the test log file, the filename hivemqXXX.log will be present and it means that the override is working:

    # kubectl exec pod/broker-0 -c hivemq -- ls -la log
total 20
drwxrwx--- 2 root  root 4096 Jul 23 16:22 .
drwxrwx--- 1 root  root 4096 Jul 23 16:22 ..
-rw-r--r-- 1 10000 root    0 Jul 23 16:22 event.log
-rw-r--r-- 1 10000 root 1594 Jul 23 16:22 hivemq.log
-rw-r--r-- 1 10000 root 1594 Jul 23 16:22 hivemqXXX.log
-rw-r--r-- 1 10000 root    0 Jul 23 16:22 migration.log
-rw-r--r-- 1 10000 root    0 Jul 23 16:22 script.log

    If the hivemqXXX.log is absent, it means that the override is not working.

  • No labels