Статьи

5 методов улучшения регистрации вашего сервера

В последнее время мы увидели множество инструментов, которые помогут вам разобраться в ваших журналах. Проекты с открытым исходным кодом, такие как Scribe и LogStash, локальные инструменты, такие как Splunk, и размещенные сервисы, такие как SumoLogic и PaperTrail. Все это поможет вам уменьшить объем данных журнала в нечто более значимое.

И есть одна вещь, которую они все разделяют. Все они зависят от данных, которые вы фактически вносите в журнал. Эта задача по обеспечению качества и количества данных сразу же ложится на вас. Имея это в виду, вот 5 вещей, которые вы должны постоянно помнить при входе в систему:

1. Здравствуйте, меня (Тема) зовут ..

Свойство Thread name является одним из самых недооцененных методов Java, поскольку оно в основном носит описательный характер. Место, где это играет большую роль, находится в многопоточной регистрации. Большинство каркасов регистрации автоматически регистрируют имя текущего потока. Однако это будет выглядеть примерно так: «http-nio-8080-exec-3» — имя, назначаемое пулом потоков или контейнером.

Название потока — это главное имя в вашем журнале, и вы хотите убедиться, что используете его правильно. Это означает присвоение ему подробного контекста, такого как сервлет или задача, которую он выполняет прямо сейчас, и некоторого динамического контекста, такого как идентификатор пользователя или сообщения.

Таким образом, точка входа в ваш код должна начинаться примерно так:

1
Thread.currentThread().setName(MyTask.class.getName() + “: “+ message.getID());

2. Распределенные идентификаторы

В SOA или архитектуре, управляемой сообщениями, выполнение задачи или запроса может охватывать несколько компьютеров. Если обработка одного из них не удалась, соединение точек между машинами и их состояние будет ключом к пониманию того, что произошло.

Чтобы анализаторы журналов группировали соответствующие сообщения журнала на разных компьютерах, вам необходимо предоставить им уникальный идентификатор, с помощью которого они могут это делать, как часть каждого сообщения журнала. Это означает, что каждая входящая операция в вашей системе должна иметь уникальный идентификатор, который будет сопровождать ее до тех пор, пока она не будет завершена.

Постоянный идентификатор, такой как идентификатор пользователя, не может быть хорошим судном, так как один пользователь может иметь несколько операций, выполняемых для него, что усложнит изоляцию. UUID (хотя и длинные) могут быть хорошим выбором здесь, а также могут быть загружены в имя потока или выделенный TLS.

3. Не текст + диск. Не входите в систему + петля.

Часто вы увидите фрагмент кода, работающий в узком цикле и выполняющий операцию журнала. Основное предположение заключается в том, что код будет выполняться ограниченное количество раз.

Это вполне может быть тот случай, когда все работает хорошо. Но когда код получает неожиданный ввод, цикл может не прерываться . В этом случае вы имеете дело не только с бесконечным циклом, но и с кодом, который записывает бесконечные объемы данных на диск или в сеть.

Если оставить это на свое усмотрение, это может привести к остановке сервера или всего кластера.

По возможности не входите в узкие петли. Это особенно актуально при отлове ошибок.

01
02
03
04
05
06
07
08
09
10
11
void readData {
    while (hasNext()) {
        try {
            readData();
        }
        catch (Exception e) {
            // this isn’t recommend - you can catch, but log outside the loop
            logger.error("error reading " X + " from " Y, e);
        }
    }
}

4. Необработанные обработчики

У Вестероса есть Стена, последняя линия защиты (хорошая вещь, которая им поможет). У вас есть Thread.uncaughtExcceptionHandlers . Поэтому убедитесь, что вы используете их. Если вы не установите один такой обработчик, вы рискуете выбросить исключения в эфир с очень небольшим контекстом и очень небольшим контролем, если и где они в конечном итоге будут регистрироваться.

Обратите внимание, что даже в обработчике необработанных исключений, который не имеет доступа к переменным в завершенном потоке, вы все равно получаете ссылку на объект Thread. Если вы придерживаетесь шага № 1, вы все равно получите значимую ветку. getName () для входа, чтобы предоставить вам больше контекста.

5. Поймать внешние звонки

Всякий раз, когда вы делаете вызов API, который покидает JVM, шансы на исключение резко возрастают. Это включает в себя веб-сервис, Http, DB, файл, ОС или любые другие вызовы JNI. Относитесь к каждому вызову так, как будто он взорвется (скорее всего, в какой-то момент).

По большей части причины сбоя вызова API связаны с непредвиденным вводом данных, предоставленным им вами. Наличие этих значений в журнале является ключевым моментом при устранении проблемы.

1
2
3
4
5
6
7
try {
    return s3client.generatePresignedUrl(request);
}
catch (Exception e) {
    String err = String.format("Error generating request: %s bucket: %s key: %s. method: %s", request, bucket, path, method);
    log.error(err, e); //you can also throw a nested exception here with err instead.
}

Отладка сервера с помощью Takipi

Takipi создан для того, чтобы сделать отладку сервера еще лучше, сделав ваши журналы более интеллектуальными и насыщенными информацией. Вот 3 функции, которые могут упростить вашу жизнь при следующей отладке сервера:

  1. Отладка сервера . Когда Takipi обнаруживает исключение или ошибку в вашей JVM, он собирает код и переменные, которые его вызвали. Конечным результатом является то, что для каждой ошибки в вашем приложении вы можете перейти прямо в исходный код, который выполнялся на этом компьютере, и увидеть все значения переменных, которые его вызвали — локальные объекты, объекты, массивы и строки, которые были там, прямо в данный момент. ошибки.

    Takipi1

  2. Лог интеграции. Takipi автоматически добавляет крошечную отладочную гиперссылку к каждой ошибке журнала, так что вы можете использовать ее для прямого перехода к фактическому исходному коду и значениям переменных, которые его вызвали.

    takipi2

  3. Распределенная отладка . Если вызов в коде, который не удался, был сделан с другой машины, на которой запущен Takipi, вы увидите исходный код и значения переменных в распределенной цепочке вызовов. Так что, если компьютер A вызвал B, который вызвал C, который вышел из строя, вы увидите код и переменную по всей цепочке между ними.

    Takipi3

Нажмите здесь, чтобы попробовать Такипи