Для того чтобы еще лучше понять Diamond, запустим его. Нам нужен модифицированный файл конфигурации, который мы можем поместить в созданный нами каталог Diamond/tmp. Находясь в нем, введите следующий код: (venv)$ mkdir tmp
(venv)$ cp conf/diamond.conf.example tmp/diamond.conf
Далее отредактируйте файл tmp/diamond.conf, чтобы он выглядел так:
Из этого примера конфигурации видно следующее.
Далее запустите Diamond, указав, что журнал будет сохраняться по адресу
Для того чтобы завершить процесс, нажимайте Ctrl+C до тех пор, пока снова не появится командная строка. Журнал показывает, что делают сборщики и обработчики: сборщики собирают разные метрики (вроде объема общей, свободной памяти и памяти подкачки от MemoryCollector), которые обработчики форматируют и отправляют в разные точки назначения вроде Graphite, MySQL (в нашем тестовом случае — как сообщения журнала в
Читаем код Diamond
Для чтения более крупных проектов лучше использовать IDE — с их помощью вы можете быстро обнаружить оригинальное определение функций и классов исходного кода (при наличии определения можете найти все места в проекте, где задействованы функция или класс). Для использования этой функциональности укажите интерпретатору Python вашей IDE применять одну из виртуальных сред57.
Вместо того чтобы разбирать каждую функцию, как мы сделали это для HowDoI, изучим рис. 5.2 (показаны операторы импорта). Схема демонстрирует, какие модули Diamond импортируют другие модули. Подобные рисунки помогают понять более крупные проекты. Можно начать с исполняемого файла diamond в левом верхнем углу и следовать всем операторам импорта в проекте Diamond. Помимо исполняемого файла diamond, в каждом квадрате указывается файл (модуль) или папка (пакет) в каталоге src/diamond.
Хорошо организованные и удачно названные модули Diamond позволяют понять идею кода, просто взглянув на схему: модуль diamond получает версию из util, затем настраивает журналирование с помощью utils.log и запускает экземпляр сервера с помощью server. Сервер импортирует почти все вспомогательные модули, используя классы utils.classes, чтобы получить доступ к обработчикам в handler и сборщикам, config — для чтения файла конфигурации и получения настроек для сборщиков (дополнительные пути для сборщиков, определенных пользователем), scheduler и signals — для установки интервала опроса для сборщиков, чтобы подсчитать их метрики, а также для настройки обработчиков и указания им приступать к обработке очереди метрик, которые нужно отправить.
Схема не включает в себя вспомогательные модули convertor.py и gmetric.py, используемые определенными сборщиками, а также более 20 реализаций обработчиков, определенных в подпакете handler, и более 100 реализаций сборщиков, определенных в каталоге проекта Diamond/src/collectors/ (которые находятся в другом месте, если процесс установки Diamond отличается от того, который мы выполнили при чтении, то есть использовали дистрибутивы пакетов PyPI или Linux вместо исходного кода). Они импортируются с помощью функции diamond.classes.load_dynamic_class(), которая затем вызывает функцию diamond.util.load_class_from_name() для загрузки классов на основе имен, представленных в строках конфигурационного файла, поэтому операторы импорта могут не вызывать их явно.
Рис. 5.2. Структура импортированных модулей в Diamond
Чтобы понять, для чего в проекте присутствуют пакет utils и модуль util, нужно открыть код: модуль util предоставляет функции, связанные с упаковкой Diamond (а не с его работой): функцию для получения номера версии на основе version.__VERSION__ и две функции, которые анализируют строки, позволяющие определить модули или классы и импортировать их.
Журналирование в Diamond
Функция diamond.utils.log.setup_logging(), которая находится в файле src/diamond/utils/log.py, вызывается из функции main() исполняемого файла diamond при запуске демона: # Инициализация журналирования
log = setup_logging(options.configfile, options.log_stdout)
Если значение options.log_stdout равно True, функция setup_logging() настроит средство ведения журнала со стандартным форматированием так, чтобы оно
отправляло записи в стандартный поток выхода на уровне DEBUG. Это делается в следующем фрагменте кода: