Система логирования ALog первоначально разрабатывалась для использования в серверных приложениях. Первая реализация ALog была выполнена в 2013 году, на тот момент я и подумать не мог, что спустя семь лет буду писать про нее статью на Хабр. Но, видимо, на все воля случая Сейчас уже и не вспомню, что именно искал на просторах интернета, когда мне на глаза попалась статья Сравнение библиотек логирования. Я решил бегло просмотреть её в ознакомительных целях. По мере знакомства с материалом в голове возникла мысль: "А где же в этом 'табеле о рангах' находится мой логгер?". Чтобы это выяснить был создан небольшой проект LoggerTest для тестирования систем логирования.

Асинхронный логгер

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

0. У логгера нет ограничения по памяти (обычно серверы не испытывают недостатка в ОЗУ) ²

1. Стоимость вызова логгера в рабочих потоках должна быть минимальной. Данная характеристика важна для любой программы, но для серверной - особенно, где стоимость процессорных ресурсов может быть достаточно высока.

[1] ALog не является самостоятельной библиотекой, это всего лишь несколько модулей в составе библиотеки общего назначения.

[2] Использование ALog в ситуациях отличных от тестовых не приводит к существенному потреблению оперативной памяти, что позволяет использовать логгер на ARM-системах с небольшим объемом ОЗУ.

Участники тестирования

Первоначально для сравнения была выбран только Spdlog. Это было сделано по нескольким причинам:

0. В исходной статье Spdlog показал неплохие результаты - фактически второе место;

1. Логгер асинхронный (синхронные логгеры меня не интересовали в принципе, по причине их низкой производительности в многопоточных приложениях);

2. Под впечатлением от статьи, P7 казался просто недосягаемым, поэтому вначале я его даже не рассматривал в качестве участника тестирования.

Первые сравнения были сильно не в пользу ALog. Пришлось заняться оптимизацией, благо было понимание какие механизмы могут тормозить работу логгера. В итоге отставание стало не столь катастрофическим. Воодушевленный результатом, я написал автору статьи Сравнение библиотек логирования о своем логгере, и приложил первые тесты. Но реакции на мое сообщение не последовало. Выдержав паузу в пару месяцев, я решил самостоятельно написать о проделанной работе.

Для тестов было отобрано три логгера::

0. G3log (версия 1.3.3, gitrev: f1eff42b)

1. P7 (версия 5.5)

2. Spdlog (версия 2.x, gitrev: f803e1c7)

G3log был добавлен просто для статистики. У этого логгера не очень высокая скорость сохранения данных на диск, что и было подтверждено тестами. Последним в сравнение был включен P7. Хочу сказать спасибо разработчикам P7, за помощь в написании тестового примера.

Формат тестовых сообщений

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

У Spdlog и G3log формат префикса можно менять, что позволяет сделать лог-сообщения похожими на сообщения ALog, и таким образом обеспечить примерно одинаковый объем записываемой информации.

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

Внешний вид префиксов для лог-сообщений:

• ALog ----------------------------------------------------- 15.10.2020 19:39:23.981457 DEBUG2 LWP18876 [alog_test.cpp:35 LoggerTest]

• Spdlog ---------------------------------------------------[2020-10-15 20:22:55.165] [trace] LWP19519 [spdlog_test.cpp:76 LoggerTest]

• G3log -----------------------------------------------------2020/10/15 20:24:48 836329 DEBUG [g3log_test.cpp->thread_func:36]

Тестовый стенд

• OS: Ubuntu 20.04

• Compiler: GCC 8.4.0 C++14

• CPU: Intel Core i7 2700K, 4 ядра, 8 потоков (4.5GHz, разгон)

• RAM: 32Gb (DDR3-1600, XMP 8-8-8-24-2N)

• SSD: Samsung 860 Pro 512Gb³

• Количество итераций в тесте: 5

• Количество записываемых строк: 5 000 000

[3] Любопытный момент: скорость сохранения логов на HDD диск (TOSHIBA HDWD120) оказалась выше чем на SSD.

Тестирование

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

Прямые характеристики:

• Logging time - усредненное время, за которое все тестовые сообщения будут добавлены в систему логирования;

• Flush time - усредненное время, за которое все тестовые сообщения будут сохранены на диск (это время отсчитывается от начала теста, поэтому включает в себя значение Logging time).

Косвенные характеристики:

• Memory usage (max/average) - пиковое и среднее потребление памяти логгером в тесте (берутся худшие показатели из выполненных итераций);

• CPU usage (max/average) - пиковое и среднее потребление ресурсов процессора. За 100% принимается полная загрузка одного ядра процессора (берутся худшие показатели из выполненных итераций).

Дополнительные условия:

0. В P7 размер пула был установлен в 1 Гб (/P7.Pool=1048576). Для P7 это абсолютно сверх меры, но все участники на старте должны иметь более-менее одинаковые условия;

1. Для Spdlog размер очереди установлен в 3 млн. сообщений. Уменьшение её размера будет сказываться на показателе Logging time. Логгер работает в режиме async_overflow_policy::block, что запрещает ему отбрасывать "старые" сообщения если очередь переполнена.

Тест 4 потока (режим сборки: release, ключ компилятора -O2)

По параметру Flush time ALog так и не смог опередить Spdlog. Поэтому можно сказать, что по Flush time Spdlog - лидер. Правда тут есть одна оговорка: это преимущество сохраняется до тех пор, пока размер очереди больше либо равен 3 * 10^6. "Ложка дегтя" заключается в том, что память под очередь сообщений выделяется в момент создания Spdlog, и остается занятой на всем протяжении работы логгера. В данном тесте Spdlog использовал 1170Мб. Остальные участники тестирования выделяют память по мере повышения нагрузки, и освобождают по мере понижения.

Тест 4 потока (режим сборки: debug, ключ компилятора -O0)

Тест в debug-режиме интересен с точки зрения падения производительности. Очевидно, что проседание есть, но оно не такое катастрофическое (десятки раз), как об этом говорится в Сравнение библиотек логирования. Возможно, причина в том, что тесты проводились на Linux.

Тест 1 поток (режим сборки: release, ключ компилятора -O2)

В этом тесте P7 восстановил свой статус-кво. Запись в систему логирования 5 млн. сообщений в один поток за ~1.9 секунды выглядит просто недосягаемо! Скорость сохранения данных на диск тоже весьма впечатляет.

Здесь ALog уступает Spdlog в Logging time. Valgrind по этому поводу "говорит", что одна из причин низкой производительности кроется в использовании функции std::vsnprintf(). При сборке тестов под С++17 появляется возможность минимизировать использование std::vsnprintf(). При этом Spdlog все еще впереди, но отставание уже минимально (~0.15 сек). В то же время ALog улучшает другие показатели: максимальный объем занимаемой памяти уменьшился до 44 Мб, а пиковое потребление ресурсов процессора сократилось до 33%.

Для Spdlog размер очереди сообщений уменьшен до 1 млн. записей, что позволило сократить объем занимаемой памяти с 1170 Мб до 392 Мб. Дальнейшее уменьшение размера очереди ведет к ухудшению Logging time. Еще один штрих: сборка Spdlog под С++17 даёт незначительное (примерно на 0.1 секунды) увеличение Logging time, не затрагивая остальные результаты.

Промежуточный итог

Что ж, тщеславие удовлетворено. Пусть ALog не первый в этом тестировании, но тем не менее выглядит вполне достойно, а по параметру Logging time в многопоточном режиме работы - безусловный лидер.

Но что же дальше?! Эффективность работы системы логирования безусловно важна, но есть и другие критерии, которые целесообразно принимать во внимание. Например: возможность конфигурирования, фильтрация, удобство записи лог-сообщений в рабочем коде. Уже в процессе подготовки тестов пришла мысль, что наверное не следует ограничиваться только сравнением логгеров, и было бы неплохо рассказать об особенностях использования ALog. Это я и собираюсь сделать в следующих разделах.

Немного плагиата

Собственно, в чем плагиат: из статьи Сравнение библиотек логирования я решил позаимствовать авторские названия некоторых разделов, чтобы обеспечить ассоциативность восприятия материала.

Документация и зависимости

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

• Demo 01: Вывод в лог "Hello world";

• Demo 02: Вывод сообщений в файл;

• Demo 03: Вывод сообщений из разных потоков;

• Demo 04: Фильтрация лог-сообщений по имени модуля, с последующим сохранением в разные лог-файлы;

• Demo 05: Конфигурирование лог-системы при помощи конфиг-файлов⁴;

• Demo 06: Форматированный вывод через log_format (тестовое использование)

Для сборки потребуется QtCreator 4.12 или выше. Сборочная система QBS.

Примечание: сборка под ОС Windows не выполнялась, но проект тривиален, поэтому проблем возникнуть не должно.

Зависимости: ALog - не самостоятельное решение, он является составной частью библиотеки общего назначения SharedTools. Для такого подхода есть пара причин:

• ALog достаточно маленький - всего три программных модуля⁵:

  0. logger - непосредственно сам логгер;

  1. config - модуль конфигурирования;

  2. format - модуль для форматированного вывода сообщений.

• ALog зависит от некоторых модулей общего назначения из SharedTools. Поэтому я посчитал нецелесообразным выносить логгер в отдельную библиотеку, и делать ее зависимой от SharedTools.

[4] Для сборки примера Demo 5 требуется Qt-framework.

[5] Под программным модулем понимается пара cpp/h файлов, или один h-файл.

Тип логгера, контроль потребления памяти и потокобезопасность

• Логгер асинхронный, порядок добавления сообщений можно считать атомарным (используется спин-блокировка), что не исключает возможности перемешивания сообщений. Однако, для диапазона точности, в котором работает логгер (микросекунды), явления перемешивания вряд ли могут быть обнаружены. За семь лет использования логгера я не сталкивался с подобными проявлениями.

• Контроль потребления памяти отсутствует.

Обработка сбоев процесса

Автоматическая обработка сбоев процесса не предусмотрена. Считаю, что программист должен самостоятельно выполнять такого вида обработки, так как сложно предвидеть все инварианты, которые могут потребоваться разработчику. Тем не менее, существует механизм для немедленного "сброса" всех сообщений из буфера логгера в систему вывода. Функция "сброса" сообщений может выглядеть так:

void prog_abort(){    log_error << "Program aborted";    alog::logger().flush();    alog::logger().waitingFlush();    alog::logger().stop();    abort();}

Стиль логирования и вывод (sink)

Вывод (sink): В ALog механизм вывода называется Saver (дословно: хранитель, в вольной трактовке: средство/механизм сохранения). В дальнейшем будет использоваться именно этот термин.

По умолчанию поддерживаются вывод в файл, и в stdout. В качестве демо-примера, сделан вывод в syslog. Правда, на момент его написания, syslog не мог похвастаться высокой скоростью работы, конечно с той поры может что и поменялось.

Стиль логирования: ALog поддерживает два стиля логирования: потоковый оператор << и форматированный вывод. При этом, вывод через потоковый оператор является основным, а форматированный вывод был добавлен сравнительно недавно и, на текущий момент, находится в статусе экспериментальный.

Споры о том, какой способ вывода лучше не закончатся наверное никогда. На мой взгляд, у потокового оператора есть одно важное преимущество: его можно переопределять, что позволяет системе логирования работать с пользовательскими типами данных. А возможность выводить лог-сообщения сразу через несколько saver-ов добавляет системе логирования ещё больше гибкости.

Рассмотрим небольшой пример: предположим, нам требуется логировать действия пользователя при выполнении им некоторых задач. При этом выполняемые действия должны отображаться не только в общем лог-файле, но и фиксироваться в базе данных.

Используем структуру TaskLog для группировки необходимых параметров логирования.

struct TaskLog{    int taskId;    int userId;    string status;};

На следующем шаге реализуем потоковый оператор ⁶.

namespace alog {Line& operator<< (Line& line, const TaskLog& tl){    if (line.toLogger())        line << "TaskId: "   << tl.taskId             << "; UserId: " << tl.userId             << "; Status: " << tl.success;    return line;}} // namespace alog

Реализацию saver-a для записи сообщений в базу данных я оставлю за рамками этой статьи по причине существенного объема кода. Отмечу только, что saver нужно будет создать и зарегистрировать в системе логирования при старте программы. Далее в рабочем коде приложения вызываем логгер:

TaskLog tl {10, 20, "success"};log_info << "Task complete. " << tl;

В лог-файл будет добавлена строка: 15.10.2020 19:39:23 INFO LWP18876 [example.cpp:35] Task complete. TaskId: 10; UserId: 20; Status: success И одновременно с этим система логирования вставит в таблицу базы данных запись из трех полей: TASK_ID, USER_ID, STATUS. Конечно, реализация потокового оператора и saver-a для вывода информации в базу данных потребует определенных усилий, но это может быть оправдано удобством последующего использования.

Вот еще одна ситуация, которую хотелось бы рассмотреть: иногда лог-сообщение должно формироваться в зависимости от условия. "Классический" способ решения этой задачи - конкатенация строк с последующим выводом результата. В ALog конкатенация может быть заменена на последовательное формирование лог-сообщения при помощи явно объявленной переменной с типом alog::Line:

{ //Block for alog::Line    alog::Line logLine = log_verbose << "Threshold ";    if (threshold > 0.5)        logLine << "exceeded";    else        logLine << "is normal";    logLine << " (current value: " << threshold << ")";}

Форматированный вывод реализован как надстройка над потоковыми операторами. Таким образом форматированный вывод будет работать со всеми типами данных для которых реализован оператор <<. Пример с выводом TaskLog будет выглядеть так:

TaskLog tl {10, 20, "success"};log_info << log_format("Task complete. %?", tl);

Возможно комбинирование потоковых операторов и форматированного вывода:

log_info << "Task complete." << log_format(" %?", tl);

[6] В примере приведена базовая (упрощенная) реализация потокового оператора.

Инициализация логгера

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

Для stdout программная инициализация состоит из одной строки:

alog::logger().addSaverStdOut(alog::Level::Info);

Инициализация для вывода в файл будет чуть сложнее:

const char* saverName = "default";const char* filePath = "/tmp/logger-demo.log";alog::Level logLevel = alog::Level::Debug;bool logContinue = true;{ //Block for SaverPtr    SaverPtr saver {new SaverFile(saverName, filePath, logLevel, logContinue)};    logger().addSaver(saver);}

Для небольших приложений программная инициализация достаточно эффективна. Но по мере роста приложения, по мере усложнения конфигурации логирования, такая инициализация становится громоздкой, и в конечном счете неудобной для использования. Поэтому для больших приложений предпочтительнее будет инициализация с использованием конфигурационных файлов. Работа с файлами конфигурации требует наличия yaml-парсера. ALog для этой цели использует yaml-cpp.

Пример секции инициализации логгера:

### YAML syntax #### Конфигурирование системы логированияlogger:    # Уровень логирования. Допускаются следующие значения: error, warning, info,    # verbose, debug, debug2. По умолчанию используется info    level: verbose        # Определяет будет ли пересоздаваться log-файл при перезапуске программы.    # (флаг: true/false). Если параметр равен 'false', то log-файл будет    # пересоздаваться при каждом перезапуске программы, в противном случае    # логирование будет выполняться в существующий файл    continue: true        # Наименование файла логирования    file: /var/opt/application/log/application.log        # Наименование файла логирования в Windows    file_win: ProgramData/application/log/application.log        # Определяет файл конфигурирования сейверов и фильтров для системы логирования    conf: /etc/application/application.logger.conf        # Определяет файл конфигурирования сейверов и фильтров для системы логирования в Windows    conf_win: ProgramData/application/config/application.logger.conf        filters:        # Наименование фильтра      - name: default        type: module_name        mode: exclude            modules: [            VideoCap,            VideoJitter,        ]

В этой конфигурации будет создан saver по умолчанию⁷, с выводом в файл /var/opt/application/log/application.log. Параметры logger.conf и logger.filters отвечают за механизмы расширенной фильтрации, их назначение будет рассмотрено в разделе Настройка фильтрации.

В примере Demo 05 показано как создается saver по умолчанию с использованием файла конфигурации. А пример ниже демонстрирует, как можно переконфигурировать систему логирования в процессе работы программы:

// Время последней модификации конфиг-файла приложенияstd::time_t configBaseModify = 0;// Время последней модификации конфиг-файла для логераstd::time_t configLoggerModify = 0;void init(){    // Время модификации файлов на момент старта программы    configBaseModify = config::baseModifyTime();    configLoggerModify = config::loggerModifyTime();}// Таймер-функцияvoid configModifyTimer(){    bool modify = false;    std::time_t configModify = config::baseModifyTime();    if (configBaseModify != configModify)    {        modify = true;        configBaseModify = configModify;        config::base().rereadFile();        log_verbose << "Config file was reread: " << config::base().filePath();        alog::configDefaultSaver();    }    configModify = config::loggerModifyTime();    if (configLoggerModify != configModify)    {        modify = true;        configLoggerModify = configModify;        alog::configExtensionSavers();    }    if (modify)        alog::printSaversInfo();}

[7] Наименование saver-a по умолчанию всегда 'default'

Точность времени

Все сообщения в ALog фиксируются с точностью до 1 микросекунды, что покрывает потребности большинства существующих приложений. Но выводится это время только при уровне логирования Debug2 (режим трассировки). Такая точность временных меток необходима для режима подробной диагностики, для менее интенсивных режимов логирования вполне достаточно точности в 1 секунду. Данный подход несколько сокращает объем лог-файла. При разработке собственного saver-a разработчик может выводить микросекунды на любом уровне логирования.

Доступ к логгеру

На программном уровне доступ к логгеру осуществляется с помощью глобальной функции alog::logger(), что позволяет уйти от множества проблем связанных с использованием глобальных статических переменных.

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

Настройка фильтрации

ALog, как и большинство современных логгеров, поддерживает фильтрацию по уровням логирования. Имеются следующие варианты:

enum Level {None = 0, Error = 1, Warning = 2, Info = 3, Verbose = 4, Debug = 5, Debug2 = 6};

Debug2 - соответствует режиму трассировки, название имеет исторические причины.

На этом, сходство с другими логгерами заканчиваются. Первое существенное отличие состоит в том, что для ALog невозможно задать уровень логирования напрямую, так как уровень логирования - не характеристика логгера, а характеристика его saver-ов. Уровень логирования самого логгера всегда будет равен максимальному уровню логирования saver-ов, использующихся на данный момент. Однако, для логгера эта характеристика тоже достаточно важна, так как она позволяет еще на первичном этапе обработки сообщений отсекать те из них, которые гарантированно не будут выводиться в лог.

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

0. При использовании глобального логгера все программные модули будут выдавать сообщения с заданным уровнем логирования, в результате чего получается много лишней, избыточной информации;

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

2. Объем файлов логирования может быть очень большим (см. п.1). Иногда объемы лог-файлов исчисляются десятками гигабайт, то есть существует риск отказа операционной системы из-за отсутствия свободного места на диске;

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

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

Тогда возникает вторая мысль: "Нужно сделать так, чтобы разные модули программы могли выдавать лог-сообщения с разным уровнем логирования". При диагностике программы, как правило, уже имеются предположения о том, какие её узлы могут приводить к сбою. Соответственно, только эти узлы должны выдавать максимально подробные логи, а остальные части программы могут работать со штатным уровнем логирования. Как выводить такую гетерогенную лог-информацию? Возможны два подхода:

0. Все модули, со штатными и трассировочными уровнями логирования пишут свои сообщения в один файл. Таким образом сохраняется последовательная хронология событий;

1. Существует один главный файл логирования, в который пишут все модули в режиме штатного логирования, и одновременно модули требующие диагностики пишут свои лог-сообщения в альтернативные файлы в режиме трассировки.

ALog умеет работать в обоих режимах, но мне больше нравится второй. Главный лог-файл получается не перегруженным, и в нем легко находить сообщения с ошибками. Далее, зная время инцидента, можно провести подробный анализ ситуации с использованием альтернативного лог-файла.

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

Под логическим модулем понимается один или несколько программных модулей объединенных общим функционалом или выполняемым действием.

Ранее говорилось, что уровень логирования связан непосредственно с saver-ом, то есть весь процесс разделения сообщений происходит именно внутри механизма вывода. Управляет процессом разделения система фильтров, которая оставляет только те сообщения, которые удовлетворяют критериям фильтрации. Сейчас поддерживаются следующие критерии (типы) фильтрации:

Более подробно типы фильтрации описаны тут. Файл demo05.logger.conf содержит пример конфигурации логгера для Demo 05

Осталось рассмотреть вопрос с наименованием логических модулей. Можно использовать решение "в лоб", но выглядит оно не очень

alog::logger().debug(alog_line_location, "Module1") << "Message";

Как часто бывает в таких ситуациях - на помощь приходят макросы.

// Определяем макросы в начале модуля#define log_error_m   alog::logger().error   (alog_line_location, "Module1")#define log_warn_m    alog::logger().warn    (alog_line_location, "Module1")#define log_info_m    alog::logger().info    (alog_line_location, "Module1")#define log_verbose_m alog::logger().verbose (alog_line_location, "Module1")#define log_debug_m   alog::logger().debug   (alog_line_location, "Module1")#define log_debug2_m  alog::logger().debug2  (alog_line_location, "Module1")...void moduleFunc1(){    for (int i = 0; i < 10; ++i)    {        log_debug_m << "Func1. Message " << i;        usleep(10);    }}...// Удаляем макросы в конце модуля#undef log_error_m#undef log_warn_m#undef log_info_m#undef log_verbose_m#undef log_debug_m#undef log_debug2_m

В cpp-файлах #undef можно опустить, но не стоит так делать в заголовочных файлах. В этом случае результат работы лог-фильтров может оказаться неожиданным.

Поддержка юникода

Фактически, широкой поддержки юникода нет. В Linux в подавляющем большинстве ситуаций используется UTF-8. Для QString есть перегруженный потоковый оператор, в нем осуществляется преобразование из UTF-16 в UTF-8. На этом все.

Ротация файлов

ALog не поддерживает какие либо механизмы по ротации лог-файлов, так как с этой задачей прекрасно справляется logrotate.

Некоторые приемы использования

Здесь описаны некоторые приемы использования ALog, которые не попали в другие разделы. Делаю это на тот случай, если вдруг кому-то в голову придет мысль о применении ALog в своей программе.

Сложные трассировочные сообщения лучше использовать внутри условия:

if (alog::logger().level() == alog::Level::Debug2){    log_debug2_m << "Message was sent to socket"                 << ". Id: " << message->id()                 << ". Command: " << CommandNameLog(message->command())                 << ". Type: " << message->type()                 << ". ExecStatus: " << message->execStatus();}

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

log_debug2_m << "Message was sent to socket";

Наименование программного модуля получено из другой программы

std::string s = ".../python/example1.py";const char* file = alog::__file__cache(s);alog::logger().info(file, 0, 10, "Python") << "Message from python-script";

Не так давно в ALog была добавлена оптимизация позволяющая извлекать наименование программного модуля из макроса __FILE__ в процессе компиляции, и это реально ускорило работу логгера. Но у такой оптимизации есть обратная сторона: адреса строк содержащих наименования модулей не должны меняться на протяжении жизни программы. В принципе, с макросом __FILE__ все так и есть. Но иногда возникает желание (или необходимость) сделать сквозное логирование для внутренних и внешних (работающих в другом процессе) компонентов приложения. В данном случае наименования модулей получаемые из внешней программы имеют динамические адреса строк, а следовательно их нельзя передавать в ALog. Для решения этой проблему была создана функция alog::__file__cache(), она преобразует динамические строки в псевдостатические, что вполне устраивает логгер.

Подмена механизма логирования в сторонних библиотеках Многие сторонние библиотеки имеют свой механизм логирования. Иногда это полноценная система логирования, но чаще - это просто функция. Для обеспечения единообразного логирования собственного проекта можно попробовать сделать подмену библиотечной функции логирования⁸. При этом стороннюю библиотеку, скорее всего, придется собрать самостоятельно, или как минимум, нужно быть готовым к такому повороту событий.

Пример подмены функции логирования logmvnc() для драйвера Intel Movidius Neural Compute Stick:

void logmvnc(enum mvLog_t level, const char* file, int line, const char* func,             const char* format, ...) asm ("logmvnc");void logmvnc(enum mvLog_t level, const char* file, int line, const char* func,             const char* format, ...){    va_list args;    va_start(args, format);    int len;    char buff[1024] = {0};    auto removeLastN = [&len, &buff]()    {        if ((len < int(sizeof(buff))) && (buff[len - 1] == '\n'))            buff[len - 1] = '\0';    };    switch (level)    {        case MVLOG_DEBUG:            if (alog::logger().level() == alog::Level::Debug2)            {                len = vsnprintf(buff, sizeof(buff) - 1, format, args);                removeLastN();                alog::logger().debug2(file, func, line, "Movidius") << buff;            }            break;        case MVLOG_WARN:            {                len = vsnprintf(buff, sizeof(buff) - 1, format, args);                removeLastN();                alog::logger().warn(file, func, line, "Movidius") << buff;            }            break;        case MVLOG_ERROR:        case MVLOG_FATAL:        case MVLOG_LAST:            {                len = vsnprintf(buff, sizeof(buff) - 1, format, args);                removeLastN();                alog::logger().error(file, func, line, "Movidius") << buff;            }            break;        default:            {                // LEVEL_INFO                len = vsnprintf(buff, sizeof(buff) - 1, format, args);                removeLastN();                alog::logger().info(file, func, line, "Movidius") << buff;            }    }    va_end(args);}

[8] Это возможно не для всех библиотек.

Вместо заключения

Когда я только начинал работу над этим материалом, то полагал, что ALog уже достаточно устоявшееся, отработанное решение. Но мои представления были неверными. Оказалось, что есть много аспектов, требующих переоценки или доработки. Какие-то правки вносились в процессе тестирования, а какие-то уже в процессе написания этой статьи. Благодаря всей этой затее были созданы два новых проекта: LoggerTest и LoggerDemo. Оба проекта открыты для развития, поэтому если у кого-то возникнут вопросы по работе логгера - постараюсь, по мере возможности, на них ответить. Может быть ответы воплотятся в новых примерах. Касательно LoggerTest - думаю, я далеко не единственный, кто пишет свой логгер, так что если есть желание помериться цифирьками - приходите.

Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к спасательному кругу в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.

Предисловие

Данным постом хотел бы начать цикл статей посвященных Логированию ошибок в Oracle PL/SQL. В первую очередь донести мысль до многих разработчиков, о том как можно построить функционал фиксации, хранения логов в БД. На своем опыте продемонстрировать поэтапный процесс создания полноценного логирования в БД. Рассказать как нам удалось создать логирование ошибок, разработать единую нумерацию событий для их дальнейшей идентификации, как поверх логирования натянуть мониторинг событий, создать функционал позволяющий увидеть все текущие ошибки в БД в виде таблиц (с указанием частоты возникновения ошибок и кол-ва и т.д.), графиков (отразить динамику роста кол-ва ошибок) и правильно распределить ресурсы для устранения тех или иных ошибок.

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

Введение

В этой и следующих статьях будет показано как реализованный функционал логирования позволяет фиксировать факт возникновения не только ошибок (сообщение с типом Error), но и сообщений с предупреждением (тип Warning), информативных сообщений (с типом Info) и т.д., поэтому, в рамках данных статей введём термин - Модель логирования событий (далее по тексту - "модель") или коротко Логирование событий, где под "событием" подразумевается некоторое ожидаемое действие, возникшее в ходе штатной/внештатной работы алгоритма.

Модель логирования позволяет реализовать:

1. Единый подход в обработке и хранении событий

2. Собственную нумерацию и идентификацию событий происходящих в БД

3. Единый мониторинг событий

4. Анализ событий происходящих в БД

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

Единый подход в обработке и хранении событий

Основной идеей "Единого подхода в обработке и хранении событий" заключается в создании одного одновременно простого и в тоже время очень сложного правила: "Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события". Простота заключается в том, что легко, в команде разработчиков, на словах договориться об исполнении данного правила. Сложность же заключается в том, что данное правило должно быть установлено на ранних этапах создания вашей БД и выполняться обязательно на протяжении всего жизненного цикла. Внедрить функционал логирования в уже существующие и действующие БД очень сложно (практически не возможно).

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

Наверное сейчас кто-то из читателей может возразить: "Зачем в обязательном порядке?". А всё очень просто, если вы разработчик PL/SQL и вы не согласны с этим правилом, то вот вам пример. Посмотрите на свой текущий проект более внимательно. Скорее всего вы найдете какое-нибудь логирование событий реализованное кем-то, когда-то. Вспомните сколько раз вы обращались к этому логированию при решении багов. Именно в таких ситуациях, когда есть срочность по времени в исправлении бага, вы или ваши коллеги начинают использовать dbms_output.put_line в качестве экспресс-дебага (быстрый способ получения значений переменных используемых в коде). Согласитесь, что для исправления бага мало знать в какой процедуре, в каком запросе и на какой строке возникла ошибка, необходимо знать параметры запроса на которых возникает ошибка. И вот тут нам на помощь приходит "Логирование событий", потому что помимо места возникновения ошибки мы узнаем параметры вызова процедуры, в которой возникает ошибка и это очень упрощает исправление бага.

Первая статья посвящена базовому функционалу Логирования событий. В простейшей реализации это одна общая таблица и пакет процедур для работы с ней. Для создания и демонстрации логирования, нам необходимо реализовать следующие объекты БД (весь список объектов с их исходными кодами представлен в Git):

1. Таблица messagelog - единая таблица логов. Именно в данной таблице будет храниться информация о дате и времени события, об объекте где происходит событие, типе события с указанием кода, текста и параметров. В нашем примере, столбец backtrace вынесен в отдельную таблицу messagelog_backtrace для удобства.

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

   Структура таблицы

   Название столбца	Тип данных	Комментарий
   id	number primary key	Первичный ключ таблицы
   objname	varchar2(60)	Содержит наименование объекта из которого было инициировано событие. Чаще всего это комбинация имя_пакета.имя_процедуры
   msgtype	varchar2(3)	Тип события, например: ERR - сообщение от ошибке; INF - информационное сообщение; WRN - сообщение с предупреждением и т.д.
   insertdate	date	Дата и время создания записи о событии
   msgcode	varchar2(10)	Код ошибки, чаще всего это SQLCODE, либо код ошибки из справочника ошибок (об этом будет отдельная статья)
   msgtext	varchar2(500)	Текст ошибки, чаще всего это SQLERRM, либо текст ошибки из справочника ошибок
   paramvalue	varchar2(500)	Наименования параметров процедуры/функции и их значения. При анализе ошибок удобно видеть с каким параметрами была запущена та или иная процедура, выполнить повторный запуск этой процедуры с указанными параметрами и воспроизвести ошибку
   backtrace	varchar2(4000)	Записывается результат функции dbms_utility.format_error_backtrace, либо иная дополнительная информация

   Исходный код таблицы

   create table messagelog(id         number(38)      not null,                        msgtype    varchar2(3)     not null,                        objname    varchar2(60)    default null,                        insertdate date            default sysdate,                        msgcode    varchar2(10)    default null,                        msgtext    varchar2(4000)  default null,                        paramvalue varchar2(4000)  default null,                        constraint pk_messagelog_id primary key (id))partition by range (insertdate)  interval (numtoyminterval(3, 'MONTH'))    (partition p1 values less than (to_date('01.01.2020', 'DD.MM.YYYY'))); 
   

   *Исходный код других используемых объектов смотрите в Git

   В данной статье не будем подробно описывать способы индексирования и партицирования таблицы, всё зависит от целей и задач логирования. Самый предпочтительный вид хранения таблицы это партицирование по столбцу insertdate с интервалом 3 месяца.

   Отдельно стоит упомянуть про столбцы msgtext, paramvalue и backtrace. По своему опыту скажу, что указанные столбцы в 60% - 70% случаев будут пустыми и это очень сильно не нравится архитекторам и/или руководителям отделов разработки. Поэтому иногда есть смысл вынести указанные столбцы в отдельную таблицу с привязкой по id записи. В нашем примере столбец backtrace вынесен в отдельную таблицу messagelog_backtrace (см. исходный код в git).

2. Пакет pkg_msglog - содержит набор процедур необходимых для логирования событий. В нашем примере будут представлены одна "корневая" и две процедуры для логирования событий: "ERR" - событие об ошибке; "WRN" - предупреждающее событие. Вызов корневой процедуры выполняется в автономной транзакции и делается это для того, чтобы была возможность выполнить сохранение данных об ошибке с откатом всех предыдущих изменений.

   Исходный код процедур пакета

   -- процедура логирования ошибокprocedure p_log_err(p_objname    in varchar2,                    p_msgcode    in varchar2,                    p_msgtext    in varchar2 default null,                    p_paramvalue in varchar2 default null,                    p_backtrace  in varchar2 default null)  is  begin    p_insert_log(p_msgtype_    => 'ERR',                 p_objname_    => p_objname,                 p_insertdate_ => sysdate,                 p_msgcode_    => p_msgcode,                 p_msgtext_    => p_msgtext,                 p_paramvalue_ => p_paramvalue,                 p_backtrace_  => p_backtrace);  end p_log_err;    -- корневая процедура логирования  procedure p_insert_log(p_msgtype_    in varchar2,                         p_objname_    in varchar2,                         p_insertdate_ in date,                         p_msgcode_    in varchar2,                         p_msgtext_    in varchar2 default null,                         p_paramvalue_ in varchar2 default null,                         p_backtrace_  in varchar2 default null)  is    v_id   messagelog.id%type;    pragma autonomous_transaction;  begin    insert into messagelog(msgtype,                           objname,                           insertdate,                           msgcode,                           msgtext,                           paramvalue,                           backtrace)        values(p_msgtype_,               p_objname_,               p_insertdate_,               p_msgcode_,               p_msgtext_,               p_paramvalue_,               p_backtrace_)    return id      into v_id;    if trim(p_backtrace_) is not null then      insert into messagelog_backtrace(id,                                       backtrace)      values(v_id,             trim(p_backtrace_));    end if;    commit;  end p_insert_log;
   

   *Исходный код других используемых объектов смотрите в Git

3. Тестовый пакет pkg_clients - пакет с демонстрационными процедурами поиска и создания пользователей. Обратите внимание, что процедура p_insert_user выполняет функции аудита события - "создание нового пользователя".

   Исходный код процедур поиска и создания пользователей

   create or replace package body pkg_clients as  procedure p_insert_user(p_login_     in varchar2,                          p_firstname_ in varchar2,                          p_lastname_  in varchar2,                          p_id_        out number)  is    v_id clients.id%type;  begin    insert into clients(login,                        firstname,                        lastname)        values(upper(p_login_),               p_firstname_,               p_lastname_)    return id      into v_id;    if v_id > 0 then      -- аудит события - создание нового пользователя      pkg_msglog.p_log_wrn(p_objname    => 'pkg_clients.p_insert_user',                           p_msgcode    => '101',                           p_msgtext    => 'Создан новый пользователь с id = '||v_id,                           p_paramvalue => 'p_login = '||p_login_                                             ||', p_firstname = '||p_firstname_                                             ||', p_lastname = '||p_lastname_);    end if;    commit;  exception    when others then      pkg_msglog.p_log_err(p_objname    => 'pkg_clients.p_insert_user',                           p_msgcode    => SQLCODE,                           p_msgtext    => SQLERRM,                           p_paramvalue => 'p_login_ = '||p_login_                                             ||', p_firstname_ = '||p_firstname_                                             ||', p_lastname_ = '||p_lastname_,                           p_backtrace  => dbms_utility.format_error_backtrace);      rollback;  end p_insert_user;    procedure p_create_user(p_login     in varchar2,                          p_firstname in varchar2,                          p_lastname  in varchar2,                          p_id        out number)  is    v_id clients.id%type;  begin    begin      select id        into v_id        from clients       where login = upper(p_login);    exception      when no_data_found then        p_insert_user(p_login_     => p_login,                      p_firstname_ => p_firstname,                      p_lastname_  => p_lastname,                      p_id_        => v_id);    end;       p_id := v_id;  exception    when others then      pkg_msglog.p_log_err(p_objname    => 'pkg_clients.p_create_user',                           p_msgcode    => SQLCODE,                           p_msgtext    => SQLERRM,                           p_paramvalue => 'p_login = '||p_login                                             ||', p_firstname = '||p_firstname                                             ||', p_lastname = '||p_lastname,                           p_backtrace  => dbms_utility.format_error_backtrace);  end p_create_user;end pkg_clients;
   

   *Исходный код других используемых объектов смотрите в Git

Демонстрация логирования событий

Для демонстрации работы выполним три стандартных кейса с помощью созданного ранее пакета pkg_clients.

1. (Ошибочная ситуация) Создание пользователя с длиной имени превышающей допустимое значение в таблице

   Пример 1
   рис. пример запуска процедуры

   Результат

   рис. описание ошибки

2. (Ошибочная ситуация) Создание пользователя с пустым значением имени или фамилии (предположим, что есть такое требование)

   Пример 2
   рис. пример запуска процедуры

   Результат

   рис. описание ошибки

3. (Успешная ситуация) Создание нового пользователя с аудитом события

   Пример 3
   рис. пример запуска процедуры

   Результат

   рис. описание ошибки

   Обратите внимание, что все демонстрационные процедуры завершаются блоком exception when others then с дальнейшим вызовом процедуры логирования события вне зависимости от "важности" процедуры.

Заключение

В заключении я повторюсь, что гораздо проще и правильнее добавлять логирование событий в обработку исключений при первом написании процедуры (функции) т.к. это не занимает много времени. Гораздо сложнее в будущем, внести правки в большое количество объектов БД и это займет гораздо больше времени на написание кода, тестирование и т.д.

По своему опыту отмечу, что пакет pkg_msglog (со всеми дополнительными объектами логирования) должен быть создан самым первым в проектируемой БД и в дальнейшем другие объекты создаются с логированием событий. Также, часто в командах появляются разработчики, которые говорят: "Зачем логировать все процедуры (функции)? Давайте вести логирование только важных и нужных процедур (функций)!". Вот здесь скрывается самая главная и распространенная ошибка. У всех нас разное понимание что есть "важная и нужная" процедура (функция). По сути, вы создаете логирование ошибок, которое "как бы и есть, но как бы его нет" т.е. все в команде знают, что в БД есть лог ошибок, но в нужный момент (например, при возникновении "блокера" на продакшн) вы обнаружите что в логах нет никакой информации об ошибке. Именно в такие моменты и возникает ошибочное мнение, что логировать события бесполезно и бессмысленно, а ведь это не так.

В следующей статье я расскажу как доработать "Логирование событий", чтобы мы могли идентифицировать события (установить принадлежность события к конкретному бизнес-процессу), установить приоритет события и максимально быстро реагировать на факт появления таких событий.

Спасибо за внимание.

Идеальный способ отлаживать и отслеживать приложения хорошо определённые, информативные и удобно структурированные логи. Они являются необходимым компонентом любого малого, среднего или крупного проекта на любом языке программирования, не только на Python. Не используйте print() или корневой логгер по умолчанию, вместо этого настройте логирование на уровне проекта. К старту нового потока курса по Data Science, мы перевели статью, автор которой решил поделиться своим шаблоном для логирования. Не лишним будет сказать, что этот шаблон пришёлся по душе многим специалистам от дата-сайентистов профессионалов и до разработчиков ПО разного уровня.

Я стал работать с модулем логирования Python пару лет назад и с тех пор изучил бесчисленное количество руководств и статей в Интернете о том, как работать с ним эффективно, с наилучшей настройкой для своих проектов.

Все они хорошо объясняют, как настроить систему ведения лога для одного скрипта Python. Однако почти невозможно найти статью, которая объясняет, как настроить библиотеку ведения журнала Python для использования в масштабах всего приложения, а также то, как правильно интегрировать и удобно обмениваться информацией о ведении лога во всех модулях проекта.

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

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

Приступим к делу!

Создадим простой проект на Python

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

Создайте папку под названием 'MyAwesomeProject'. Внутри неё создайте новый файл Python с именем app.py. Этот файл будет точкой старта приложения. Я буду использовать этот проект для создания простого рабочего примера шаблона, о котором говорю.

Откройте свой проект в VSCode (или в предпочитаемом редакторе). Теперь создадим новый модуль для настройки логирования на уровне приложения. Назовем его logger. С этой частью мы закончили.

Создаём логгер уровня приложения

Это основная часть нашего шаблона. Создадим новый файл logger.py. Определим корневой логгер и воспользуемся им для инициализации логгера уровня приложения. Настало время немного покодить. Несколько импортов и название нашего приложения:

qimport loggingimport sysAPP_LOGGER_NAME = 'MyAwesomeApp'

Функция, которую мы будем вызывать в нашем app.py:

def setup_applevel_logger(logger_name = APP_LOGGER_NAME, file_name=None):     logger = logging.getLogger(logger_name)    logger.setLevel(logging.DEBUG)    formatter = logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")    sh = logging.StreamHandler(sys.stdout)    sh.setFormatter(formatter)    logger.handlers.clear()    logger.addHandler(sh)    if file_name:        fh = logging.FileHandler(file_name)        fh.setFormatter(formatter)        logger.addHandler(fh)    return logger

Мы определим наш логгер с уровнем по умолчанию DEBUG и, чтобы структурировать сообщения логгера, воспользуемся Formatter. Затем присвоим его нашему обработчику, чтобы писать сообщения в консоль. Далее мы также обязательно включаем файл, в котором можем дополнительно хранить все наши сообщения лога. Это делается через логирование FileHandler. Наконец, мы возвращаем логгер.

Необходима ещё одна функция, которая гарантирует, что наши модули могут вызывать логгер, когда необходимо. Определите функцию get_logger.

def get_logger(module_name):       return logging.getLogger(APP_LOGGER_NAME).getChild(module_name)

Также, чтобы работать с модулем как с пакетом, по желанию мы можем создать папку logger и поместить в нее этот файл. Если мы сделаем это, нам также нужно будет включить в папку файл _init.py и написать такую строку:

from .logger import *

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

Устанавливаем логгер модульного уровня

Для лучшего понимания шаблона можно сделать простой модуль, чтобы протестировать логгер. Давайте определим простой module.py.

import loggerlog = logger.get_logger(__name__)def multiply(num1, num2): # just multiply two numbers    log.debug("Executing multiply function.")    return num1 * num2

Теперь этот модуль имеет доступ к логгеру и должен вывести сообщение с соответствующим именем модуля. Давайте проверим его.

Запустите сценарий и протестируйте логгер

Соорудим app.py.

import loggerlog = logger.setup_applevel_logger(file_name = 'app_debug.log')import mymodulelog.debug('Calling module function.')mymodule.multiply(5, 2)log.debug('Finished.')

Заметили, как мы импортируем модуль после инициализации логгера? Да, это обязательно. Теперь убедитесь, что ваш каталог содержит эти файлы:

Наконец, запустите скрипт этой командой:

python3 app.py

Вы получите вывод вроде такого:

Структура каталогов также должна измениться: в ней должен появиться новый файл log. Проверим его содержимое.

Заключение

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

А если вам интересна сфера Data Science и вы думаете поучиться по ссылке можете ознакомиться с программой курса и специализациями, которыми можно овладеть на нём.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Analyst

• Курс по Data Engineering

Эволюция бессерверной архитектуры

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

После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.

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

Что такое отладка в бессерверной среде?

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

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

Различия в отладке бессерверных и монолитных приложений

На фоне того, что монолитные приложения постепенно теряют популярность и уступают бессерверным приложениям, с точки зрения простоты отладки они безусловно доминируют. Отладка монолитных приложений проводится локально, в их собственной интегрированной среде разработки (IDE), при этом разработчик создает точку останова на проверяемой строке кода. Поскольку IDE-системы поставляются уже с готовым режимом отладки это все, что требуется от разработчиков для выявления ошибок в коде. В бессерверной архитектуре, наоборот, наиболее популярным методом отладки является логирование. Разработчики отслеживают и записывают все действия сервиса в лог-файлы и таким образом получают представление о поведении приложения.

В случае монолитных приложений все проблемы можно оттестировать и устранить в локальной среде. Точки отказа обычно возникают на уровне пользовательского интерфейса, серверной части или базы данных. Бессерверные приложения, наоборот, включают в себя множество распределенных, связанных друг с другом компонентов. Поэтому в локальной среде сложно настроить бессерверные приложения и устранить все проблемы, связанные с их работой.

Кроме того, монолитные приложения поддерживают удаленную отладку. Вы можете подключить IDE к удаленным серверам, дав разработчикам привилегированный доступ. Несмотря на то, что это в принципе возможно, применять этот метод целесообразно только в тех случаях, когда локальное моделирование вряд ли даст результаты. Бессерверные приложения по природе своей не поддерживают удаленную отладку в силу отсутствия доступа на уровне ОС и сервера.

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

Типы отладочных фреймворков для бессерверных приложений

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

Таким образом, отладочные фреймворки для бессерверных приложений основываются на двух различных подходах с использованием AWS Lambda:

1. Локальная отладка бессерверных приложений

2. Отладка бессерверных приложений для облака

Локальная отладка бессерверных приложений

При разработке ПО важнейшая часть отладки происходит при локальном запуске. Модель бессерверных приложений (SAM) это решение, которое позволяет разработчикам запускать свои приложения локально на бессерверной платформе Amazon на базе AWS Lambda. В пакет решения входит два компонента: спецификация шаблона (SAM Template Specification) и интерфейс командной строки (SAM Command Line Interface). Спецификация шаблона позволяет определить приложение с помощью прав доступа, событий, API-интерфейсов и функций. При этом интерфейс командной строки позволяет вызывать функции локально, осуществлять пошаговую отладку функций, а также упаковывать и развертывать приложения в облаке. Здесь можно ознакомиться с полным руководством по использованию AWS SAM для локальной отладки на платформе AWS Lambda.

Отладка бессерверных приложений для облака

После того как вы развернули приложение в облаке, вам необходимо понять, какие проблемы возникают при подключении функций к сервисам. Некоторые из этих подключений обычно невозможно смоделировать в локальной среде тестирования, поэтому требуется разработка процедуры для тестирования в реальном времени. Вот процедура, которая используется при тестировании в реальном времени для приложения, развернутого в облаке AWS:

• Первый этап тестирование API-шлюза. Вот некоторые из наиболее популярных инструментов для тестирования конечных точек API и шлюзов: SoapUI, Postman и Curl.

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

• На следующем этапе изучается поведение приложения с помощью логов AWS CloudWatch. Функции AWS Lambda по умолчанию настроены на отправку логов в CloudWatch. Затем решение создает для каждой функции класс LogGroup, включающий все события, вызываемые этой функцией. Еще для отслеживания событий приложений можно использовать такие решения как Splunk и ELK.

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

Популярные средства отладки бессерверных приложений

Вы, конечно, можете отлаживать свое приложение с помощью встроенных средств, таких как CloudWatch и X-RAY, но все же это ручной и весьма утомительный процесс, требующий использования сразу нескольких решений. Однако существуют и самостоятельные инструменты для отладки бессерверных приложений. Они существенно упрощают процесс благодаря интегрированному интерфейсу и удобному процессу очистки всех используемых функций и сервисов. Вот некоторые из этих инструментов:

Faasly.io

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

Встроенная система безопасности Благодаря глубокой интеграции с таким решением корпоративного класса как Envoy, можно достичь высокой степени защиты и соответствия нормативным требованиям благодаря возможности перехватывать каждый сетевой запрос, отправляемый из рабочего приложения AWS Lambda. Если ваши функции в какой-то момент будут скомпрометированы, ваши настоящие учетные данные AWS всегда останутся в безопасности.

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

AWS Cloudwatch

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

Инструменты SLS-Dev

Инструментарий Serverless Development Tools это открытый фреймворк с набором инструментов для разработчиков бессерверных платформ и приложений. Этот набор инструментов следует парадигме cloud-native, что способствует ускоренному развитию инноваций и их внедрению в промышленную эксплуатацию. Поскольку этот набор подразумевает оплату по мере использования, вы платите только за фактическое время работы и тестирования своего приложения на платформе. Притом что базовая версия включает почти весь критически важный функционал инструментария, расширенная версия под названием SLS-DevTools Guardian помогает оперативно обнаруживать проблемы по мере их возникновения и проводить отладку в режиме реального времени.

Lumigo

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

Dashbird

Если ваше приложение разработано на базе AWS Lambda, то Dashbird должен стать одним из ваших самых любимых инструментов отладки и оптимизации кода. Этот инструмент нацелен на обнаружение ряда распространенных сбоев в работе AWS Lambda, включая проблемы с памятью, тайм-ауты, ошибки времени выполнения, исключения и ошибки конфигурирования. Dashbird также оперативно предупредит вас о сбоях через Slack или по электронной почте и поможет сохранить непрерывную доступность сервиса. Помимо этого, можно интегрировать Dashbird с AWS X-RAY и получать информацию обо всех событиях и вызовах функций.

SignalFX

SignalFx это решение для облачного мониторинга, способное интегрироваться с основными поставщиками услуг, включая Google Cloud Functions, Azure Functions и AWS Lambda. Этот инструмент обеспечивает мониторинг производительности в режиме реального времени и непрерывную прозрачность для всех ваших бессерверных функций. Благодаря обширному списку функций, включающему метрики с малой задержкой, оптимизацию затрат, обнаружение холодного запуска и мониторинг времени выполнения, SignalFx неуклонно набирает популярность в сообществах разработчиков.

Заключительные мысли

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

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

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

Что касается нынешнего ИТ-рынка, среда DevOps один из лучших вариантов для ИТ-специалистов с точки зрения заработной платы и карьерного роста. И мне довольно часто задают вопрос: Как стать инженером DevOps?

В этом блоге я попытаюсь ответить на него на примере своего собственного опыта работы DevOps в различных организациях.

Многие утверждают (включая меня), что нет ничего похожего на DevOps Engineer или DevOps Team, потому что это не вещь. Однако сейчас все в отрасли уже привыкли к термину инженер DevOps, и если вы понимаете философию DevOps, эти названия не имеют большого значения.

При этом существует несколько неправильных представлений о том, что на самом деле означает этот термин. Одно из таких заблуждений DevOps это автоматизация. Но чтобы стать DevOps-инженером, недостаточно развить навыки, связанные с автоматизацией. Википедия говорит:

DevOps (обособленное сочетание разработки и эксплуатации) это культура, движение или практика, которая подчеркивает сотрудничество и общение как разработчиков программного обеспечения, так и других специалистов в области информационных технологий (ИТ) при автоматизации процесса доставки программного обеспечения и изменений инфраструктуры.

Из этого определения ясно, что DevOps не зависит от каких-либо инструментов или технологий. Это философия, согласно которой разные ИТ-команды должны работать вместе для достижения лучших и быстрых результатов за счет постоянной обратной связи.

Вот интересный график тенденций, показывающий популярность DevOps за последние 5 лет.

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

Кроме того, проект или конвейер, разработанный командой, должен обеспечивать небольшие обновления или выпуски без серьёзного ручного вмешательства. Этого можно добиться только в том случае, если произойдет культурный сдвиг в работе команды.

Как стать инженером DevOps

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

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

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

Поймите культуру DevOps

Прежде всего, необходимо понять культуру DevOps. Всё дело в объединении людей для эффективной работы над общей целью.

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

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

Как только вы начнете практиковать культуру DevOps, вы перестанете говорить, что это синоним CI/CD и автоматизации.

Узнайте больше о системах *nix

Мы живем в эпоху, когда не можем жить без систем Linux/Unix. Вы должны лучше понять и получить практические знания о различных дистрибутивах Linux, широко используемых организациями (RHEL, Centos, Ubuntu, CoreOS и т.д.).

Согласно тематическому исследованию Linux Foundation, 90 % рабочей нагрузки в публичных облаках обрабатывается на Linux.

Вот еще одно интересное исследование Redhat, в котором показаны различные дистрибутивы Linux, используемые в публичных облаках:

Теперь у вас есть достаточно причин, по которым вам стоит сосредоточиться на Linux.

Когда дело доходит до Linux, это всё про терминал, графический интерфейс менее предпочтителен в мире *nix.

Для запуска Linux-серверов вы можете использовать VirtualBox или AWS/GCP/Azure и множество других облачных платформ.

Начать изучение можно со следующего:

• Разберитесь в процессе загрузки Linux.

• Установите и настройте веб-серверы (Apache, Nginx, Tomcat и т.д.). И узнайте, как работают веб-серверы.

• Узнайте, как работают процессы Linux.

• Узнайте, как работает SSH.

• Почитайте о различных файловых системах.

• Изучите ведение системного журналирования, мониторинга и устранения неполадок.

• Узнайте о важных протоколах (SSL, TLS, TCP, UDP, FTP, SFTP, SCP, SSH).

• Научитесь управлять сервисами и попробуйте создать сервис самостоятельно (Initd, Systemd).

• Попробуйте разместить статические и динамические сайты на веб-серверах.

• Настройте балансировщики нагрузки и реверс-прокси (Nginx, HAproxy и т.д.).

• Сломайте что-нибудь и научитесь устранять неполадки.

Разберитесь, как работают компоненты инфраструктуры

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

• Сети

  • Подсеть

  • Публичная сеть

  • Частная сеть

  • Обозначения CIDR

  • Статические/динамические IP-адреса

  • Firewall

  • Прокси

  • NAT

  • Внешний и локальный DNS

  • Диагностика сети

  • VPN

• Хранилище

  • SAN

  • Бэкапы

  • NFS

• Отказоустойчивость(HA)

  • Кластер

  • Механизмы отказоустойчивости

  • Аварийное восстановление

• Безопасность

  • PKI Infrastructure

  • SSL-сертификаты

• Технология единого входа(SSO)

  • Active Directory/LDAP

• Балансировщики нагрузки

  • Балансировка на разных уровнях модели OSI (L4, L7)

  • Алгоритмы балансировки нагрузки

  • Reverse Proxy

Могло быть и больше пунктов, но я выделил только ключевые компоненты ИТ-инфраструктуры.

Научитесь автоматизировать

Автоматизация стала важным аспектом каждой организации. Мы больше не создаем серверы вручную. Мы это автоматизируем.

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

• Для среды разработки

  • Vagrant

  • Docker Desktop

  • Minikube

  • Minishift

• Для обслуживания инфраструктуры

  • Terraform

  • CLI (соответствующего облачного провайдера)

• Для управления конфигурацией

  • Ansible

  • Chef

  • Puppet

  • Saltstack

• Управление образами ВМ

  • Packer

Контейнеры, распределенные системы и Service Mesh

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

Как только вы изучите Docker, можете попробовать его инструменты кластеризации и оркестрации, такие как Kubernetes, Docker Swarm и т.д. Эти платформы лучше всего подходят для архитектуры на основе микросервисов.

Вот интересная тенденция использования Kubernetes по данным Datadog:

А вот пятилетняя тенденция роста поисковых запросов по Kubernetes:

Кроме того, многие инженеры проявляют интерес к изучению Kubernetes, и в 2021 году немало людей получат сертификаты по этой технологии (CA, CKD и CKD).

Service mesh это выделенный слой инфраструктуры с низкой задержкой для обеспечения взаимодействия между сервисами. Он даёт массу возможностей для межсервисного взаимодействия: балансировки нагрузки, шифрования трафика, авторизации, трассировки, обнаружения сервисов (service discovery) и использования паттерна автоматического выключения (circuit breaker), с которым можно ознакомиться тут. Service mesh это сложная тема, когда дело касается распределенных систем. Если вы новичок в работе с инструментами для контейнеров, вы можете изучить это после получения хороших знаний об архитектуре на основе микросервисов.

Журналирование и мониторинг

Журналирование и мониторинг очень важные аспекты инфраструктуры.

Большинство приложений, развернутых в инфраструктуре, будут создавать журналы. Основываясь на дизайне архитектуры, журналы будут передаваться и храниться в отдельном слое инфраструктуры.

Каждая компания будет иметь отдельный уровень инфраструктуры под журналирование. Обычно используются такие стеки, как Splunk, ELK и Graylog. Кроме того, существует несколько SaaS-компаний, таких как Loggly, которые предоставляют инфраструктуру для централизованного хранилища журналов.

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

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

Также на основании правил, настроенных в системах мониторинга, будут срабатывать оповещения. Например, оповещение может быть в виде уведомления в Slack или Telegram, задачи в Jira, простого email, SMS-сообщения или даже звонка на телефон. Все схемы оповещения могут разниться от компании к компании.

Как инженер DevOps, вы должны иметь доступ к журналам и уметь устранять неполадки во всех средах (Dev, QA, Stage, Prod). Понимание регулярных выражений очень важно для построения запросов в любом инструменте централизованного хранилища журналов.

Понимание лучших практик в сфере кибербезопасности (DevSecOps)

DevSecOps ещё одна область, связанная с интеграцией практик безопасности на каждом этапе DevOps. Википедия говорит:

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

Обзор инфобезопасности в 2020 показывает распределение разных кибератак по регионам:

В облачных средах криптомайнинг является распространенной атакой. В основном это происходит, когда секреты облачного доступа хранятся плохо, так что хакеры получают к ним доступ.

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

А вот основные стандартные практики DevSecOps, опубликованные Redhat:

Hashicorp Vault отличный инструмент для управления секретами. Существует множество рабочих процессов для управления секретами среды.

Изучайте программирование

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

Например, для написания конвейера Jenkins в декларативном виде (как код) требуется знания Groovy; кастомный модуль Ansible требует знания Python; для написания оператора Kubernetes требуется опыт работы с Go.

Обратите внимание на следующие языки программирования, которые часто используются для написания скриптов или небольших программ:

• Bash/Shell

• Python

• Go

Go действительно становится популярным в сфере DevOps. Его используют многие инструменты. Например, Kubernetes и Terraform написаны на Go. JFrog исследовал внедрение Go во время GopherCon, и 18 % респондентов заявили, что используют этот язык для работы, связанной с DevOps.

Изучите Git, научитесь документировать, узнайте о GitOps

Очень важно применять систему контроля версий ко всему, что вы делаете (кроме паролей и секретов). Git лучший инструмент для этого. Для него доступно множество руководств, и изучение важных операций с Git не займет много времени.

Вы можете начать с Github или Bitbucket в качестве удаленного репозитория кода.

А как только вы поймете Git, изучите GitOps. Что этот такое?

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

Ещё очень важно документировать всё, что вы делаете. Каждый репозиторий должен иметь файл README, лучше объясняющий ваш код. Хорошая документация поможет не только вам, но и тем, кто попытается использовать вашу кодовую базу.

Освойте непрерывный жизненный цикл доставки приложений

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

• Continuous Integration (Непрерывная интеграция)

• Continuous Delivery (Непрерывная доставка)

• Continuous Deployment (Непрерывное развертывание)

Научитесь использовать инструменты CI/CD, такие как Jenkins, Gitlab CI, Travis CI и т.д. Вот хорошее графическое представление процесса CI/CD:

DevOps vs SRE

SRE еще одна развивающаяся тема в сообществе DevOps. Это набор практик и философий, разработанных Google. Вот что компания говорит о DevOps и SRE:

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

Я рекомендую изучить официальные документы от Google:

1. What is SRE?

2. SRE vs. DevOps: competing standards or close friends?

Читать, читать и еще раз читать

Нет ничего лучше для приобретения знаний, чем чтение. Прочтите хотя бы один технический блог DevOps, связанный с инженерией. Следите за всеми значимыми инженерными блогами, такими как Netflix, Twitter, Google и т.д. Узнайте, как они используют правильный набор инструментов, стратегии развертывания и свои последние проекты с открытым исходным кодом.

Заключение

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

А теперь мне интересно услышать от вас:

Что из культуры DevOps вы применяете на практике у себя?

Каков путь становления DevOps инженером вы прошли?

В любом случае, делитесь вашими мыслями об этой статье в комментариях.