← Cloudflare Workers / workers / observability / logs

Workers Logs

Workers Logs позволяет автоматически собирать, хранить, фильтровать и анализировать данные журналов, которые формируют Cloudflare Workers. Данные записываются в ваш аккаунт Cloudflare, и вы можете запрашивать их в панели управления для каждого из ваших Workers. Во всех новых Workers параметр Observability включён по умолчанию.

Логи включают журналы вызовов, пользовательские логи, ошибках и необработанных исключениях.

Чтобы отправлять логи стороннему сервису, используйте Экспорт OpenTelemetry (рекомендуется), Workers Logpush, или Tail Workers.

Чтобы Worker записывал логи в Workers Logs, необходимо добавить настройку observability. Добавьте следующую настройку в файл Wrangler вашего Worker и повторно разверните Worker.

{
  "observability": {
    "enabled": true,
    "head_sampling_rate": 1 // optional. default = 1.
  }
}

[observability]
enabled = true
head_sampling_rate = 1

Head-based выборка позволяет задать процент запросов Workers, которые попадают в лог.

Окружения позволяют развертывать одно и то же приложение Worker с разными конфигурациями. Например, может понадобиться настроить другой head_sampling_rate в staging и production. Чтобы настроить observability для окружения с именем staging: 1. Добавьте следующую конфигурацию под [env.staging]

{
  "env": {
    "staging": {
      "observability": {
        "enabled": true,
        "head_sampling_rate": 1 // optional
      }
    }
  }
}

[env.staging.observability]
enabled = true
head_sampling_rate = 1

2. Разверните ваш Worker с помощью npx wrangler deploy -e staging
3. Повторите шаги 1 и 2 для каждой среды.

Доступ к логам вашего Worker в панели управления Cloudflare:

1. На панели управления Cloudflare перейдите к разделу Workers & Pages страницу.

   Перейдите в Workers & Pages ↗

2. В Обзор, выберите свой Worker.

3. Выберите Observability.

Чтобы получить максимум от Workers Logs, рекомендуется вести логи в формате JSON. Workers Logs автоматически извлекает поля и разумно индексирует их в базе данных. Преимущество такого структурированного логирования в том, что оно позволяет легко сегментировать данные по любому измерению для полей с неограниченной кардинальностью. Рассмотрим следующие сценарии:

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

Каждый вызов Workers возвращает один журнал вызова, который содержит такие сведения, как Request, Response и связанные метаданные. Эти журналы вызовов можно определить по полю $cloudflare.$metadata.type = "cf-worker-event". Каждая запись журнала вызова дополняется информацией, доступной Cloudflare в контексте этого вызова.

В интерфейсе Workers Logs журналы отображаются с локализованной меткой времени и сообщением. Сообщение зависит от обработчика вызова. Например, для запросов Fetch сообщение будет описывать метод и URL запроса, а события cron будут отображаться как cron. Ниже приведён список обработчиков вызова с соответствующими сообщениями.

Журналы вызовов можно отключить в wrangler, добавив invocation_logs = false конфигурации.

{
	"observability": {
		"logs": {
			"invocation_logs": false
		}
	}
}

[observability.logs]
invocation_logs = false

По умолчанию Worker генерирует журналы вызовов содержащий сведения о запросе, ответе и связанных метаданных.

Также можно добавлять собственные логи в любом месте кода. Любой console.log инструкции в вашем Worker будут видны в Workers Logs. Следующий пример демонстрирует пользовательский console.log внутри обработчика запросов Worker.

export default {
	async fetch(request) {
		const { cf } = request;
		const { city, country } = cf;

		console.log(`Request came from city: ${city} in country: ${country}`);

		return new Response("Hello worker!", {
			headers: { "content-type": "text/plain" },
		});
	},
};

addEventListener("fetch", (event) => {
	event.respondWith(handleRequest(event.request));
});

/**
 * Respond with hello worker text
 * @param {Request} request
 */
async function handleRequest(request) {
	const { cf } = request;
	const { city, country } = cf;

	console.log(`Request came from city: ${city} in country: ${country}`);

	return new Response("Hello worker!", {
		headers: { "content-type": "text/plain" },
	});
}

После развёртывания приведённого выше кода просмотрите журналы своего Worker в панель управления или с логи в реальном времени.

Head-based выборка позволяет логировать определённый процент входящих запросов к вашему Cloudflare Worker. Особенно для приложений с высокой нагрузкой это помогает сократить объём логов и снизить затраты, сохраняя при этом полезную информацию о производительности приложения. При настройке коэффициента head-based выборки вы можете управлять долей запросов, которые попадают в логи. При этом собираются все логи в контексте запроса.

Чтобы включить head-based выборку, задайте head_sampling_rate в конфигурации observability. Допустимый диапазон от 0 до 1, где 0 означает, что не логируется ни один запрос из ста, а 1 означает, что логируется каждый запрос. Если head_sampling_rate не указан, используется значение по умолчанию 1 (100%). В примере ниже head_sampling_rate равно 0.01, то есть в журнал записывается один из каждых ста запросов.

{
	"observability": {
		"enabled": true,
		"head_sampling_rate": 0.01 // 1% sampling rate
	}
}

[observability]
enabled = true
head_sampling_rate = 0.01

¹ Существует суточный лимит в 5 миллиардов логов на аккаунт в день. После превышения лимита в течение оставшейся части дня будет применяться 1% выборка (head-based sample).

² Максимальный размер одного лога составляет 256 KB. Логи, превышающие этот размер, будут обрезаны, а $cloudflare.truncated поле будет установлено в true.

Workers Logs включён и в план Free, и в план Paid Тарифы Workers.

Worker обрабатывает 15 миллионов запросов в месяц. Каждый запрос создает 1 журнал вызова и 1 console.log. head_sampling_rate настроен на значение 1.

Worker обрабатывает 1 миллиард запросов в месяц. Каждый запрос создает 1 журнал вызова и 1 console.log. head_sampling_rate настроен на значение 0.1.