---
title: 'Наблюдаемост: логове, метрики и здраве за Laravel и микроуслуги | DevSense'
description: 'Как да наблюдавате състоянието на приложението под натоварване: структурирано логване, метрики, трасиране, correlation ID между услуги и спектър от инструменти от syslog до Prometheus, Loki, OpenTelemetry и APM.'
faq:
- { question: 'Каква е разликата между ниво на логване (log level) и контекст на лога (log context)?', answer: 'Нивото на логване (напр. DEBUG, INFO, WARNING, ERROR) класифицира важността на съобщението за филтриране в продакшън. Контекстът на лога представлява структурирани метаданни (масиви с потребителски ID, ID на заявката, време за изпълнение), прикачени към записа, които позволяват автоматично индексиране и свързване без парсване на текст.' }
- { question: 'Защо етикетите с висока уникалност (high-cardinality) са опасни за системи за метрики като Prometheus?', answer: "Prometheus съхранява метриките като записи във времева база данни. Всяка уникална комбинация от етикети създава нов времеви ред. Записването на силно уникални параметри (като потребителски ID-та или пълни URL адреси) води до 'експлозия на времевите редове', което препълва оперативната памет на Prometheus сървъра." }
- { question: 'Как разпределеното трасиране предава контекст между микроуслугите?', answer: 'Разпределеното трасиране използва HTTP заглавки (като `X-Request-Id` или стандарта W3C `traceparent`) за предаване на уникално ID на трасирането (trace ID) и ID на текущата стъпка (span ID). Всяка микроуслуга по веригата извлича тази заглавка, записва я в лога си и я предава нататък при изходящи HTTP заявки или в заглавките на опашките.' }
- { question: 'Защо Laravel Telescope трябва да бъде изключен в продакшън?', answer: 'Laravel Telescope записва подробна информация за всяка заявка, SQL заявки и логове директно в базата данни. При високо натоварване в продакшън този оверхед за запис намалява общата производителност на приложението, претоварва основната база данни и бързо изчерпва дисковото пространство.' }
published: '2026-05-31'
---
# Наблюдаемост: логове, метрики и проверка на здравето в монолити и микроуслуги с Laravel
Фразата „на моята машина работи“ не е стратегия за мониторинг. В продакшън системите се чупят **по съвсем конкретни начини**: дисковете се препълват, латентността на опашките скача, някоя външна интеграция спира поради таймаут или някоя реплика започва да връща остарели данни. Добрата наблюдаемост (observability) ви позволява да отговорите на въпросите: **какво се промени**, **за кого** и **кое звено се провали** — без да се налага да се свързвате по SSH към всяка машина. Същите концепции важат независимо дали управлявате **Laravel монолит** или **множество микроуслуги**; само **интеграциите** и **кардиналността** стават по-сложни с разделянето на границите.
**Свързани ръководства:** [PHP: пул от връзки към БД](php-database-connection-pooling) · [Бази данни под натоварване](database-performance-and-scaling) · [API шлюзове и съобщения](../microservices/api-gateway)
## Съдържание
* [Трите стълба: логове, метрики, трасиране](#pillars)
* [Разлики по среди (environments)](#environments)
* [Laravel монолит: практически слоеве](#monolith)
* [Микроуслуги: корелация и трасиране](#microservices)
* [Спектър от инструменти: от класически до модерни](#tools)
* [Под натоварване: семплиране, кардиналност, разходи](#load)
* [Аларми, които хората ще уважават](#alerting)
* [Чести грешки](#common-mistakes)
* [Контролен списък](#checklist)
* [Тест за самопроверка](#self-test-quiz)
---
## Трите стълба: логове, метрики, трасиране
| Стълб | Какво обяснява | Чести грешки |
|--------|---------|------------------|
| **Логове** | *Какво се случи по стъпки?* (грешки, одит, контекст за отстраняване на грешки) | Неструктуриран текст, който не може да се филтрира; записване на тайни (secrets) в лога; **INFO** наводнения в продакшън |
| **Метрики** | *Колко, колко бързо, в сравнение с вчера?* | Етикети с **висока уникалност (high-cardinality)** (потребителски ID или пълни URL адреси); графики, които никой не гледа |
| **Трасиране** | *Коя стъпка по веригата беше бавна?* | Липса на **предаване на контекст (correlation ID)**, поради което услуга Б не знае, че нейната заявка е част от заявка А |
Те се допълват взаимно: **скок в процента грешки** (метрика) ви насочва към конкретен времеви диапазон, в който намирате **свързаните логове** и **следата (trace)** на бавната трансакция. Нито един от стълбовете не замества останалите.
---
## Разлики по среди (environments)
* **Локална среда / разработка** — максимална **скорост за разработчиците**: `tail` на логове, Telescope, подробни съобщения за грешки на екрана, брейкпоинти. **Не пренасяйте** тази детайлност в продакшън непроменена.
* **Staging / pre-prod** — копира продакшън инфраструктурата за логване и табла за управление (доколкото е възможно), за да хване грешки от типа „всичко работеше, докато не пуснахме JSON логове към Loki“.
* **Production** — оптимизиран за **сигнал**, **разходи за съхранение** и **сигурност**: структурирани логове без лични данни, семплиране при отстраняване на грешки, **health checks**, отразяващи реалното състояние на зависимостите.
> [!NOTE]
> **Принцип на съвместимост на договорите**
> Целта не е еднакви инструменти навсякъде, а **съвместими договори** (едни и същи имена за correlation ID полета, едни и същи имена на основните метрики), така че при инцидент разработчиците да не трябва да се учат наново.
---
## Laravel монолит: практически слоеве
### Логване в приложението
* Използвайте каналите в **`config/logging.php`**: `stack`, `daily`, `syslog` или изход в stdout в **JSON** формат, за да могат контейнерите да агрегират логовете.
* Предпочитайте **структурирани полета** (масив `context`), вместо да съединявате текстови низове.
* Прикачвайте **request id**, **user id** (ако е разрешено от политиката), **queue job id** — всичко, което ще помогне за свързването на един лог ред с останалата част от историята.
Пример за конфигуриране на канал за логване:
```php
// config/logging.php
'channels' => [
'stack' => [
'driver' => 'stack',
'channels' => ['daily'],
'ignore_exceptions' => false,
],
// ...
],
```
И употреба в кода:
```php
// app/Http/Controllers/OrderController.php
Log::info('Order processed successfully', [
'order_id' => $order->id,
'user_id' => auth()->id(),
'execution_time_ms' => $timeMs,
]);
```
### Жизнен цикъл на заявката (Request lifecycle)
* Middleware за **correlation id**: приемайте входящ `X-Request-Id` или генерирайте такъв; връщайте го в отговорите; предавайте го във фонови задачи и изходящи HTTP заявки.
* Използването на **`Log::withContext()`** в съвременните версии на Laravel помага за запазване на контекста на заявката без ръчно предаване на параметри.
### Опашки и планировчик
* **Horizon** (Redis) предоставя **дълбочина на опашката, пропускателна способност, неуспешни задачи** — третирайте го като първичен мониторинг, а не просто като удобен UI.
* Задачи по график: логвайте **старт/край/продължителност**; настройвайте аларми за **пропуснати изпълнения** (чрез външна cron-heartbeat услуга).
### Дълбок анализ (не за продакшън)
* **Telescope** е безценен в **local/staging** среди; дръжте го **изключен** в продакшън, освен ако нямате строги филтри по IP/авторизация и не се притеснявате от натоварването върху базата данни.
* **Laravel Pulse** показва **бавни заявки, SQL заявки, натоварване на опашките** — но внимавайте с обема събирани данни при силно натоварени системи.
### Здраве и готовност (Health and readiness)
* Ендпойнт **`/up` (Health)** в Laravel 11+: разделяйте концепциите **liveness** („процесът работи“) и **readiness** („приложението е готово да приема трафик, базата данни и кешът са достъпни“). Това е критично за балансьорите на натоварването и Kubernetes.
### Грешките като продукт
* **Sentry**, **Flare**, **Bugsnag** — групиране на стек трасета, проследяване на релизи и хлебни трохи (breadcrumbs). Те допълват логовете на системата, но не заменят **метриките за натоварване на системата**.
---
## Микроуслуги: корелация и трасиране
Когато едно HTTP извикване премине през веригата **gateway → услуга А → услуга Б → брокер на съобщения → worker**, обикновеният access-лог на всяка услуга поотделно става **безполезен**.
### Correlation ID
* Предавайте стабилен идентификатор при всяко изходящо повикване (`X-Request-Id` или стандарта **W3C `traceparent`**).
* Записвайте го в лога на входа на **всяка** услуга; предавайте го в **асинхронните** съобщения (вътре в payload на задачата или в заглавките на брокера).
### Разпределено трасиране
* **OpenTelemetry** — модерен **вендорски-независим** стандарт за събиране на трасета; агентите изпращат данни към **Jaeger**, **Tempo**, **Zipkin** или SaaS решения.
* Зрелостта на библиотеките в PHP екосистемата варира — проверявайте **автоматичното инструментариране** за вашия HTTP клиент, драйвер за БД и брокер на опашки. Частичното трасиране все пак е по-добре от никакво.
### Граници на услугите
* Стандартизирайте политиките за **таймаут, повторни опити (retries) и идемпотентност**. Мониторингът ще покаже „лавинообразни повторни опити“, ако всеки слой сляпо преизпраща заявки.
---
## Спектър от инструменти: от класически до модерни
### Хост и мрежово ниво
* **syslog**, **rsyslog**, **logrotate** — централизация на текстови файлове; все още актуално като транспортен слой.
* **Nagios**, **Icinga**, **Zabbix** — базови проверки на хостове, ping, дискове, RAM. По-малко за логове на приложения, повече за инфраструктурна основа.
### Агрегиране на логове
* **ELK / Elastic Stack** (Elasticsearch, Logstash/Beats, Kibana) — мощно търсене в логове; изисква сериозно администриране или бюджети за SaaS.
* **Graylog**, **Splunk** (enterprise) — алтернативни решения в същия сегмент.
### Метрики и табла
* Събиране на метрики **Prometheus** + табла **Grafana** — де факто стандарт за **Kubernetes** и виртуални машини. **Alertmanager** за маршрутизация на аларми.
* **VictoriaMetrics**, **Mimir**, **Thanos** — решения за дългосрочно съхранение на Prometheus метрики.
### Логове „като метрики“
* **Grafana Loki** — съхранение на логове на базата на етикети (labels). По-евтино за поддръжка в сравнение с пълно индексиране на всяка дума в търсачките.
### Облачни решения
* **AWS CloudWatch**, **Google Cloud Logging/Monitoring**, **Azure Monitor** — нативни инструменти, ако инфраструктурата ви е изцяло при един доставчик.
### SaaS „всичко в едно“
* **Datadog**, **New Relic**, **Honeycomb** — логове, метрики, APM, RUM; **бърз старт**, но **заплащане според обема** изисква строг контрол над кардиналността на данните.
### Грешки и APM за PHP
* **Sentry** (грешки + performance), **Scout**, **Tideways** (PHP профайлинг) — популярни инструменти в Laravel общността.
### Вълна на стандартизация
* **OpenTelemetry (OTel)** — унифицирани SDK и експортьори. **Collector** може да разпределя данни към различни бекенди, предотвратявайки vendor lock-in.
---
## Под натоварване: семплиране, кардиналност, разходи
* **Обемът на логовете** расте линейно с трафика. Логването на всяка заявка в `DEBUG` режим в JSON формат може да изразходва повече CPU от самото приложение. Използвайте **нива на логване** и семплиране.
* **Етикети на Prometheus**: никога не използвайте **неограничени** стойности (потребителски ID, имейли, пълни динамични URL адреси) като имена или стойности на етикети — това ще доведе до **експлозия на кардиналността** на метриките.
* **Семплиране на трасета**: запазвайте **100%** от грешките и бавните заявки; обикновените успешни заявки семплирайте (напр. запазвайте само 1% или 5%).
* **Съхранение (Retention)**: разделяйте логовете на **горещи** (достъпни веднага), **студени** (в евтино обектно хранилище за одит) и **изтриваеми**.
---
## Аларми, които хората ще уважават
Настройвайте известия за събития, които влияят на потребителите или сочат към предстоящ срив: **изгаряне на SLO (SLO burn)**, рязък ръст в **броя грешки**, закъснения в опашките **p95 (queue latency)**, критично ниско ниво на **дисково пространство**, изтичане на **SSL сертификати**.
Избягвайте аларми по „шумни“ метрики, ако към тях няма ясни инструкции (runbooks). „CPU > 80%“ в продължение на 5 минути най-често **не** изисква събуждане на дежурния; „**успеваемостта на плащанията** падна с 15%“ — изисква незабавно действие.
---
## Чести грешки
1. **Етикети на метриките с висока уникалност (High-Cardinality)**: Добавяне на динамични данни (като `user_id` или `email`) като лейбъли за Prometheus, което води до прекомерен разход на памет и срив на мониторинга.
2. **Логване на конфиденциални данни**: Записване на масива `$request->all()` при влизане на потребител, поради което пароли, токени и лични данни попадат в текстовите логове.
3. **Оставен Telescope в продакшън**: Записване на всички SQL заявки и заявки на приложението без редовно почистване, което заема ценно дисково пространство и натоварва СУБД.
4. **Липса на таймаути при външни заявки**: Заявки към външни услуги без задаване на времеви лимит за изчакване, което води до блокиране на воркерите на PHP-FPM и бързо изчерпване на процесите.
---
## Контролен списък
1. **Структурирани логове** се записват в stdout или лог-шипър; използва се **един** correlation id за синхронни и асинхронни вериги.
2. Проследяват се **Golden Signals** за всяка услуга: latency, traffic, errors, saturation (плюс **дълбочина на опашките** за воркерите на Laravel).
3. Ендпойнтовете за проверка на **здравето** тестват **реални** зависимости; разделени са **liveness** и **readiness** проверките.
4. Грешките се проследяват чрез специализиран инструмент (Sentry/Bugsnag); **Telescope** и аналогични са достъпни само в среди, различни от прод.
5. Направена е проверка на **разходите и кардиналността** преди включването на детайлни логове и етикети.
---
## Извод
Наблюдаемостта е **част от продукта**: същият код на Laravel, който обслужва потребителите, трябва да предоставя **доказателства** за коректната си работа и да сочи точното място на проблема, когато той възникне.
---
## Тест за самопроверка
### Въпрос 1: Каква е основната опасност от добавянето на потребителски имейли като етикети (labels) в метриките на Prometheus?
- А) Prometheus не поддържа текстови стойности в етикетите.
- Б) Това води до експлозия на кардиналността (cardinality explosion) и срив на сървъра за метрики.
- В) Това нарушава правилата за сигурност на протокола HTTP.
Кликнете, за да видите отговора
**Отговор: Б**
Всеки уникален имейл създава нов времеви ред в базата данни на Prometheus. При голям брой потребители Prometheus бързо ще изчерпи оперативната памет.
### Въпрос 2: За какво служи readiness проверката на приложението в Kubernetes или при балансьорите на натоварването?
- А) За проверка дали процесът на сървъра просто е стартирал.
- Б) За проверка дали приложението е готово да приема трафик (напр. дали има връзка с БД и кеша).
- В) За логване на бавни заявки.
Кликнете, за да видите отговора
**Отговор: Б**
Readiness probe проверява дали контейнерът е готов да приема потребителски заявки. Ако проверката се провали, балансьорът временно изключва възела от разпределението на трафика.