DOCS ЖУРНАЛЛИСТ LOGG

Appearance

Настройка macOS для отправки журналов в LOGG ​

Назначение ​

Эта инструкция описывает основные варианты передачи системных и прикладных журналов с устройств macOS в подсистему LOGG.

Современные версии macOS используют Apple Unified Logging System. Для интеграции с внешними системами можно использовать поток Unified Log, Syslog-совместимые сообщения или специализированные агенты и коллекторы.

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

По умолчанию LOGG принимает Syslog:

ТранспортПортПрименение
UDP514Простая передача Syslog
TCP601Рекомендуемый вариант для постоянной передачи

В примерах ниже используется:

text
LOGG_SERVER = 192.0.2.10

Замените этот адрес на IP-адрес или DNS-имя вашего сервера LOGG.

Особенности журналирования macOS ​

В современных версиях macOS основным механизмом журналирования является Unified Logging System.

Просмотр сохранённых событий:

bash
log show

Просмотр событий в реальном времени:

bash
log stream

Для получения текстового потока, близкого к Syslog:

bash
log stream --style syslog

Типичная запись может выглядеть следующим образом:

text
2026-08-18 14:35:22.597226+0300  localhost kernel[0]: network interface changed state

LOGG распознаёт такой формат и может извлечь:

  • timestamp;
  • hostname;
  • имя программы;
  • PID;
  • текст сообщения.

Поэтому обязательного предварительного преобразования событий macOS в RFC 3164 или RFC 5424 не требуется.

Вариант 1. Передача Syslog-сообщений ​

Если приложение или системный компонент уже формирует Syslog-сообщения, их можно направлять непосредственно в LOGG.

Для проверки локального журналирования можно использовать:

bash
logger "LOGG test message from macOS"

Для непосредственной сетевой передачи в LOGG можно использовать стандартные сетевые утилиты или специализированный Syslog-клиент.

Вариант 2. Передача Unified Log ​

Для современных версий macOS основным источником системных событий является Unified Log.

Получить поток в реальном времени можно командой:

bash
log stream --style syslog

Пример:

text
2026-08-18 14:35:22.577771+0300  mymac WindowServer[186]: display wake

или:

text
2026-08-18 14:35:22.597226+0300  mymac kernel[0]: network interface changed state

LOGG может принимать такие сообщения без дополнительного преобразования формата.

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

text
Apple Unified Log
       │
       ▼
  log stream
       │
       ▼
   Collector
       │
       │ Syslog
       ▼
      LOGG

В качестве коллектора могут использоваться Vector, Fluent Bit, Fluentd, syslog-ng или другие совместимые средства.

Вариант 3. Использование syslog-ng ​

Если требуется классическая схема централизованного Syslog, на macOS можно установить syslog-ng.

При использовании Homebrew:

bash
brew install syslog-ng

Пример назначения для LOGG по TCP:

text
destination d_logg {
    network(
        "192.0.2.10"
        port(601)
        transport("tcp")
    );
};

Для UDP:

text
destination d_logg {
    network(
        "192.0.2.10"
        port(514)
        transport("udp")
    );
};

После этого источник журналов необходимо связать с destination d_logg в конфигурации syslog-ng.

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

Вариант 4. Использование Vector ​

Для большого количества устройств macOS удобно использовать специализированный агент-коллектор, например Vector.

Общая схема:

text
macOS
 │
 ├── Unified Log
 ├── application logs
 └── log files
        │
        ▼
      Vector
        │
        │ Syslog
        ▼
       LOGG

Vector может использоваться для:

  • сбора данных из нескольких локальных источников;
  • фильтрации малоинформативных событий;
  • преобразования форматов;
  • добавления информации об источнике;
  • буферизации;
  • централизованной отправки данных в LOGG.

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

Вариант 5. Передача через shell-скрипт ​

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

Пример:

bash
#!/bin/bash

LOGG_SERVER="192.0.2.10"
LOGG_PORT="601"

log stream --style syslog | while IFS= read -r line
do
    printf '%s\n' "$line" | nc "$LOGG_SERVER" "$LOGG_PORT"
done

Скрипт можно сохранить, например:

text
/usr/local/bin/logg-forward.sh

Сделать исполняемым:

bash
chmod +x /usr/local/bin/logg-forward.sh

Запустить:

bash
/usr/local/bin/logg-forward.sh

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

Для постоянной эксплуатации предпочтительнее использовать коллектор.

Постоянное TCP-соединение ​

Более компактный вариант:

bash
log stream --style syslog | nc 192.0.2.10 601

В этом случае поток передаётся через одно TCP-соединение.

LOGG поддерживает формат macOS Unified Log, поэтому дополнительное преобразование каждой строки в RFC 3164 или RFC 5424 не требуется.

Фильтрация Unified Log ​

Unified Log может содержать большой объём событий, поэтому перед централизованной передачей полезно ограничить поток.

Например, только события процесса WindowServer:

bash
log stream \
  --style syslog \
  --predicate 'process == "WindowServer"'

Только события определённой подсистемы:

bash
log stream \
  --style syslog \
  --predicate 'subsystem == "com.apple.network"'

Фильтр можно использовать и при прямой передаче:

bash
log stream \
  --style syslog \
  --predicate 'process == "WindowServer"' \
| nc 192.0.2.10 601

Перед включением постоянной передачи рекомендуется сначала проверить выбранный predicate локально.

Передача журналов отдельных приложений ​

Некоторые приложения macOS ведут собственные файлы журналов независимо от Unified Log.

Например:

text
/var/log/application.log

Такие файлы можно собирать специализированным агентом и передавать в LOGG отдельно.

Типовая схема может выглядеть так:

text
Unified Log ──────────────┐
                          │
Application logs ─────────┼──► Collector ──► LOGG
                          │
Security logs ────────────┘

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

Проверка сетевого соединения ​

Перед настройкой постоянной передачи рекомендуется проверить доступность LOGG.

Для TCP:

bash
nc -vz 192.0.2.10 601

Для тестовой UDP-передачи:

bash
echo '<14>Aug 18 14:35:00 mymac test: LOGG UDP test from macOS' \
  | nc -u 192.0.2.10 514

Успешная TCP-проверка подтверждает доступность порта. Для UDP отсутствие ошибки отправки не гарантирует фактического получения сообщения сервером.

Проверка RFC 5424 ​

Для проверки парсинга можно отправить тестовое RFC 5424-сообщение:

bash
printf '<14>1 2026-08-18T14:35:00+03:00 mymac test-app 123 TEST - Test message from macOS\n' \
  | nc 192.0.2.10 601

После отправки найдите сообщение в Журнале событий LOGG.

Ожидаемые значения:

text
source_node = mymac
program     = test-app
severity    = info
facility    = user

Проверка собственного формата macOS ​

Можно отдельно проверить обработку характерного формата Unified Log:

bash
printf '2026-08-18 14:35:22.597226+0300  mymac testapp[123]: LOGG macOS format test\n' \
  | nc 192.0.2.10 601

LOGG должен определить:

  • источник mymac;
  • программу testapp;
  • PID 123;
  • временную метку;
  • текст сообщения.

Какие события передавать ​

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

Обычно полезны:

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

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

Рекомендуемая схема промышленной эксплуатации ​

Для единичного устройства или тестовой среды допустима непосредственная передача потока.

Для постоянной эксплуатации рекомендуется следующая схема:

text
macOS
   │
   │ Unified Log / application logs
   ▼
Vector / Fluent Bit / Fluentd / syslog-ng
   │
   │ TCP Syslog
   ▼
LOGG

Такой подход позволяет организовать:

  • фильтрацию;
  • буферизацию;
  • повторную доставку;
  • централизованное управление настройками;
  • снижение нагрузки на центральную систему.

Для критичных журналов рекомендуется использовать TCP/601.

Проверка результата в LOGG ​

После настройки передачи рекомендуется убедиться, что:

  • события поступают в LOGG;
  • корректно определяется источник;
  • определяется имя приложения или процесса;
  • правильно распознаётся timestamp и часовой пояс;
  • сохраняется полный текст сообщения;
  • поток не содержит чрезмерного количества малоинформативных записей.

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

Краткая рекомендация ​

Для современных версий macOS базовая схема выглядит следующим образом:

Unified Log → локальный коллектор → TCP/601 → LOGG.

Для быстрого тестирования можно использовать:

bash
log stream --style syslog | nc 192.0.2.10 601

Для промышленной эксплуатации рекомендуется использовать Vector, Fluent Bit, Fluentd или syslog-ng, обеспечивающие буферизацию, управление потоком и повторную доставку сообщений.