Логирование в системе LinkLog

Принципы проектирования LinkLog

Область логирования:

• 1. Логирование печати (перекрытие).
• 2. Возврат логов интерфейса (перекрытие).
• 3. Отслеживание ссылок (перекрытие).
• 4. Мониторинг системы.

Принципы системы LinkLog:

• 1. На основе существующих ресурсов и стека технологий.
• 2. Снижение риска перестройки проекта.
• 3. Возможность быстрого внедрения.

Использование LinkLog

1. Параметры запуска JVM (конфигурация управления)

-Drocketmq.client.log.loadconfig=false  
-Dlinklog.env=sit   
-Dlinklog.kafka.json=kafkaJson   
-Dlinklog.kafka.servers=10.201.1.46:9092  
-Dlinklog.kafka.topic=linklog_std_log  
-Dlinklog.kafka.errortopic=linklog_common_error  

• rocketmq.client.log.loadconfig: прямое присвоение значения false для решения проблемы невозможности автоматического обновления logback.
• linklog.env: системная среда dev|sit|pre|pro.
• linklog.kafka.json: использовать ли режим kafkaJson, предоставляемый LinkLog, по умолчанию — обычный режим.
• linklog.kafka.servers: адрес кластера Kafka, по умолчанию 10.201.1.46:9092.
• linklog.kafka.topic: тема для печати логов, если не указано, по умолчанию linklog_std_log.
• linklog.kafka.errortopic: тема для печати ошибок, если не указано, по умолчанию linklog_common_error.

2. Конфигурация Logstash (конфигурация управления)

Примечание: используется режим ELK.

logstash.conf

3. Добавление jar-пакета (разработка требует внимания только к этому)

<!--Если локально есть logback, то не нужно настраивать-->
<!--start logback должен быть версии 1.2.2 или выше-->
    <!--  <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>

      l
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>${logback.version}</version>
        </dependency>
    -->  
<!--end logback-->

<!--start linklog-->
  <dependency>
      <groupId>io.gitee.reywong</groupId>
      <artifactId>ry-linklog</artifactId>
      <version>1.0.1-releases</version>
  </dependency>
<!--end linklog-->

<!--logback-kafka плагин-->
    <dependency>
            <groupId>com.github.danielwegener</groupId>
            <artifactId>logback-kafka-appender</artifactId>
            <version>0.2.0-RC2</version>
            <exclusions>
                <!--Если проект уже содержит kafka-clients, исключить-->
                <!--<exclusion>-->
                    <!--<groupId>org.apache.kafka</groupId>-->
                    <!--<artifactId>kafka-clients</artifactId>-->
                <!--</exclusion>-->
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

<!--logback-json плагин-->
        <dependency>
            <groupId>net.logstash.logback</groupId>
            <artifactId>logstash-logback-encoder</artifactId>
            <version>6.6</version>
            <exclusions>
                <!--Если в проекте уже есть jackson-databind, исключить-->
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-databind</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Примечание: версия logback и kafka-client должна соответствовать используемой версии системы.

4. Конфигурация logback

loback.rar

Описание полей журнала

<!--
                date: время печати журнала
                ip : java.rmi.server.hostname главного хоста
                env: среда приложения test | sit | pre | pro
                appname:имя приложения
                logtype: тип журнала LinkLogTrace | LinkLogMonitor | LinkLogData
                level: уровень журнала
                linkLog: информация о журнале
                thread: имя потока
                class: имя вывода Logger
                method:имя метода
                line: номер строки
                message: содержимое
                stack_trace "%exception{5}",
                -->

Назначение журнала

• Отследить системные сбои.
• Записать траекторию операции.
• Контролировать состояние работы системы.

2. Стандарты хранения журналов

1. Ошибки журнала печатаются отдельно, теоретически нормальная работа системы не должна генерировать журналы ошибок, журналы ошибок должны решаться своевременно, и журналы ошибок используются для оценки качества системы.
2. Журналы сохраняются в формате json.
3. Журналы унифицированы и отправляются в Kafka, в настоящее время используется система ELK (можно изменить).
4. Сторонние SDK исправлены до уровня ERROR.
5. Неэффективные журналы отключены (logback), что удобно для поиска журналов и отслеживания проблем.
6. Периодически перезагружать журналы, чтобы уменьшить количество печатных журналов (стабильный код может снизить уровень журнала, например, изменить на debug).

3. Стандарты сбора журналов

1. Локальная печать журналов, каждый тип журналов сохраняется в 10 файлах, каждый файл сохраняет 100M, автоматически очищается (предотвращает проблемы с Kafka).
2. Журнал одновременно отправляется непосредственно в Kafka.

4. Стандарты отображения журналов

1. Журналы используют ElasticSeacrh.
2. Журналы контролируются Grafana.

Примеры использования журналов

• После возникновения аномалии в системе необходимо сохранить текущую ситуацию (без перезапуска приложения), изменив уровень журнала на DBUG.

Например, измените INFO на DEBUG, эффект будет через 10 секунд.

• Когда параллелизм запросов относительно велик, разные запросы могут перекрываться в журналах, и требуется связать контекст запроса.

Можно использовать поток для запроса и сортировки по времени.

• Необходимо отслеживать использование каждого интерфейса в реальном времени. filterName: 打印类, 判断拦截器类型 content: отправленное содержимое.

Частые проблемы

Неполный вывод стека исключений

Добавьте в параметры запуска JVM -XX:-OmitStackTraceInFastThrow.

Проблема с повторением traceId при использовании пула потоков

Поскольку пул потоков используется повторно, ThreadLocal передаёт данные только во время инициализации, что приводит к дублированию traceId для каждого потока.

Решение: ExecutorService executorPool = TtlExecutors.getTtlExecutorService(new ThreadPoolExecutor(2, 2, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>(), new ThreadFactoryBuilder().setNameFormat("executor-pool-%d").build(), new ThreadPoolExecutor.AbortPolicy()));

Оберните пул потоков с помощью TtlExecutors.getTtlExecutorService().

Приложение

• logback.xml
• logstash.conf