#traefik
⚙ Traefik

👋 Привет! Работа Traefik условно делится на 4 этапа.

📦 Как устроен процесс маршрутизации:

1️⃣ Entrypoints
Traefik слушает входящие соединения на указанных портах. В нашем примере — 80 (HTTP) с редиректом на 443 (HTTPS). Это "точки входа" нашего трафика.

2️⃣ Routers
Здесь происходит основной роутинг. Роутеры связывают запросы с правилами и middleware'ами (например, авторизация, редиректы, модификация заголовков).

3️⃣ Rules и Frontend
Роутер сопоставляет запрос с нужным правилом (например, Host(`api.domain.com`) или Host(`domain.com`), Path(`/web`)), и направляет трафик правильному сервису.

4️⃣ Backends (services)
Здесь уже находятся ваши реальные приложения: API, веб-приложения и микросервисы. Traefik доставляет запросы туда, куда нужно, учитывая все заданные правила.

👨‍💻 Личный опыт:
У себя в кластере я поднимаю Traefik через Helm и настраиваю его с помощью CI/CD, передавая нужные values-файлы при деплое:

helm upgrade traefik traefik/traefik --namespace traefik -f $CHART_PATH/traefik/values.yaml

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

#loki

👋 Привет! А как вы читаете логи?

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

Если инфраструктура относительно небольшая, и вы, как и я, любите Grafana — отличным вариантом станет использование Loki.

📦 Как работает Loki: сбор и визуализация логов

1. Архитектура:

- Логи с серверов и приложений собирает агент Promtail.
- Promtail отправляет логи в Loki (обычно по порту 3100).
- Визуализация логов и построение графиков происходит в Grafana, которая интегрируется с Loki.

2. Как это работает:

- Promtail читает указанные лог-файлы и отправляет данные в Loki.
- Grafana подключается к Loki как к источнику данных — и вы можете просматривать логи, строить графики и делать алерты.

3. Плюсы такого подхода:

✅ Централизованный сбор логов.
✅ Гибрид между ELK и Prometheus: минимальное потребление ресурсов, легко масштабируется.
✅ Работает как с метриками, так и с сырыми логами, что удобно при отладке или расследованиях.

📌 Советы:

- Не забывайте настраивать лейблы — без них не получится нормально фильтровать логи в Grafana.
- Настраивайте отдельные scrape_configs для разных типов логов: системные, приложенческие, nginx, базы и т.д.
- Не открывайте Grafana без авторизации — логи могут содержать чувствительные данные.

👨‍💻 Личный опыт:
Нужны логи с подов в Kubernetes? Легко! Добавьте в ваш promtail следующую задачу:

  - job_name: kubernetes-pods
    static_configs:
      - targets: ["localhost"]
        labels:
          node: "k3s_node"
          __path__: /var/log/containers/*.log
          level: info
    pipeline_stages:
      - cri: {}
    relabel_configs:
      - source_labels: ['__path__']
        regex: '/var/log/containers/(?P<pod_name>[^_]+)_(?P<namespace>[^_]+)_(?P<container_name>[^-]+)-.+\.log'
        target_label: 'pod'
        replacement: '$1'
      - source_labels: ['__path__']
        regex: '/var/log/containers/(?P<pod_name>[^_]+)_(?P<namespace>[^_]+)_(?P<container_name>[^-]+)-.+\.log'
        target_label: 'namespace'
        replacement: '$2'
      - source_labels: ['__path__']
        regex: '/var/log/containers/(?P<pod_name>[^_]+)_(?P<namespace>[^_]+)_(?P<container_name>[^-]+)-.+\.log'
        target_label: 'container'
        replacement: '$3'
      - action: replace
        replacement: 'kubernetes-pods'
        target_label: '__job__'

Теперь вы сможете легко отлавливать логи всех подов в вашем кластере!

Кстати, если хотите узнать как это все красиво визуализировать в Graphana, дайте знать в комментариях.

Отдыхая от работы наткнулся на любопытную, хоть и спорную статью. Я знаю, что тип личности это вещь очень условная, меняется в разные периоды жизни и так далее и вообще чуть ли не астрология)
Но я решил поэкспериментировать, выложил всю биографию и достижения в Grok 3 xAI и, в результате, определил типы своей личности на текущий момент, после чего перепроверил его через тест MBTI на https://www.16personalities.com/

Мне этого показалось мало и я пошел дальше: построил краткосрочный и долгосрочный карьерный трек исходя из своих типов личностей (2 пограничных варианта - архитектор и лидер), а также ценностей и возможностей. Результат, в принципе, ожидаем, хотя несколько полезных советов нашлось, так что считаю затею, в целом, полезной👍

А как вы корректируете свой карьерный трек?

Хабр
Как я разобрался в своей карьере с помощью Deepseek
https://habr.com/p/904940/

#tempo

👋 Привет! Зачем нужна трассировка (Distributed Tracing)?

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

🔍 Что такое Trace и Span?
- Trace — это полная цепочка операций, связанных с обработкой одного запроса (например, HTTP-запрос от пользователя).
- Span — это отдельная операция внутри трейса: вызов БД, обращение к другому сервису, внутренняя логика и т.д.
Каждый trace состоит из набора связанных span'ов, и таким образом можно видеть путь запроса "сквозь" систему.

📊 Как устроена архитектура трассировки с Grafana Tempo
1️⃣ Приложения собирают трейсы через OTEL SDK.
2️⃣ Данные отправляются в OTEL Collector — централизованный буфер, маршрутизатор и процессор.
3️⃣ Collector передаёт данные в Grafana Tempo.
4️⃣ Tempo сохраняет трейсы во внешнее blob-хранилище (S3 и аналоги).
5️⃣ Grafana подключается к Tempo и визуализирует трассировки.

Так выглядит типичная архитектура:
Приложения → OTEL SDK → OTEL Collector → Tempo → Grafana

🏆 Преимущества Tempo:
✅ Масштабируется — можно собирать миллионы трейсов
✅ Экономичен — нет индексации, поиск через trace_id
✅ Интеграция с Grafana: поиск трейса по логу (через Loki) или по метрике (через Prometheus)

🎯 Рекомендации по работе с трассировкой
- Обеспечивайте распространение trace_id skвозь все микросервисы, включая внешние вызовы и очереди (Kafka, RabbitMQ и т.п.).
- Используйте OTEL Collector — он масштабируется, стандартизирует приём и позволяет гибко настраивать пайплайны.
- Интеграция с логами через trace_id — один из мощнейших инструментов отладки. Добавьте trace_id в каждый лог — и можно найти трассировку по сообщению.
- Используйте группировку span'ов по namespace, сервису и операции — это упростит визуализацию в Grafana.

👨‍💻 Личный опыт:
При установке observability-стека (Tempo + Loki + Prometheus + Grafana) удобно автоматизировать процесс через Ansible. Роли, параметризированные переменными, позволяют разворачивать компоненты повторяемо и предсказуемо в любых окружениях. Это немного трудоёмко на старте, но стратегически оправдано — весь стек управляется единым способом, легко масштабируется и обновляется.

🐳 Еще лучше запускать компоненты в изоляции в Docker контейнерах, выделяя им ограниченный объем ресурсов через коллекцию community.docker:
- docker_container — для одиночных контейнеров
- docker_compose_v2 — для работы с Compose-файлами

- name: Stop container if it exists
  community.docker.docker_container:
    name: "{{ otelcol__container_name }}"
    state: absent
  failed_when: false

- name: Deploy or Restart docker-compose
  community.docker.docker_compose_v2:
    project_src: "{{ otelcol__dir }}"
    state: present
    recreate: auto
  notify: Restart container

#Prometheus #SLI

👋 Привет! Мы уже собирали метрики с хоста…
А как насчёт мониторинга самого приложения?

Когда FastAPI-сервис работает в проде и доступен пользователям — важно следить за его здоровьем.
В этом нам помогают SLI (Service Level Indicators) — метрики, которые говорят, насколько надёжно и быстро работает наш сервис.

🔍 Что такое SLI?

Service Level Indicators — это количественные показатели, описывающие:

- 📈 Доступность (например, % успешных запросов — Error Rate)
- 🕒 Производительность (например, задержка ответов — Latency)
- ⚡ Нагрузка (RPS — запросы в секунду)

На их основе строят SLO/SLA: что мы обещаем пользователям по стабильности и скорости работы.

📊 Инструментирование FastAPI с Prometheus FastAPI Instrumentator

Собираем метрики сразу из приложения 👇

from prometheus_fastapi_instrumentator import Instrumentator

def setup_metrics(app):
    Instrumentator(
        should_group_status_codes=True,
        should_ignore_untemplated=False,
        excluded_handlers=["/metrics"],
    ).instrument(app).expose(app)

Что получаем на выходе:

- ✅ RPS (запросы/секунду)
- ❌ Error Rate (процент не 2xx ответов)
- 🐢 Latency (p50, p95, p99)
- 🔍 Расчёты по каждому endpoint

Хостим /metrics, собираем метрики в Prometheus, а потом — в Grafana.

👨‍💻 Личный опыт:
Это конфигурация и дашборд моего pet-проекта на микросервисах.
За 5 минут можно увидеть живую картину в Grafana с RPS и ошибками.
Но для production-сценариев стоит:

- 🛑 Следить за аптаймом и ответами критичных роутов
- 🚨 Настроить алерты по SLA

📣 Для алертов используем Alertmanager:

groups:
  - name: fastapi_alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_server_requests_total{status!~"2.."}[5m]) > 0.05
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Высокий уровень ошибок в FastAPI"

💬 Если нужно выложить конфиги дашборда с иллюстрации или настроить алерты для этих сервисов — пишите в комментариях.

#LLM #LLM_agent

👋 Привет!
А вы используете AI в работе с кодом?
Поставьте ➕ если да, ➖ если нет.

Я каждый день работаю с AI — учусь, ускоряю задачи. Но однажды столкнулся с проблемой: когда проект становится большим, просто «скидывать» куски кода в чат уже не работает. Код усложняется, взаимосвязей становится всё больше, и ручное ревью уже не спасает.

🔍 Решение:
Я собрал собственного AI-агента для code-review. Он реально экономит время и находит те ошибки, которые легко пропустить!

---
🚀 Что умеет агент?
- Анализ одного файла:
Находит баги, антипаттерны, предлагает улучшения, выдает вердикт 👍/👎
- Мульти-обзор:
Анализирует сразу несколько файлов, видит архитектурные слабости, даёт рекомендации по проекту.
- Работа с большими файлами:
Сам режет код на чанки (токены), не боится крупных скриптов 📏
- Краткие конспекты:
Быстро формирует 5–7 пунктов по содержанию: что делает, что вызывает вопросы 📝
- Надёжность и удобство:
Работает через OpenAI API, обрабатывает ошибки, поддерживает прокси через .env.
- Простой запуск:

make review FILES="путь/к/файлу1.py путь/к/файлу2.js ..."

Как устроено внутри?

1️⃣ Загрузка конфигурации и валидация доступа
2️⃣ Нарезка больших файлов с помощью tiktoken
3️⃣ Промпты для OpenAI по каждому куску
4️⃣ Сбор и объединение результатов
5️⃣ Лог ошибок и рекомендаций прямо в консоль


👨‍💻 Личный опыт
Агент реально экономит время: находит то, что пропускаю сам, видит архитектурные «дыры», помогает с рефакторингом. Важно: AI — это ассистент, а не замена, но с таким помощником продуктивность растёт заметно! ⚡️

💬 Хотите попробовать?
Ссылка на репозиторий - https://github.com/AndreyChuyan/AI-Code-Reviewer

Пишите мне в личку https://news.1rj.ru/str/Andrey_Chuyan «👀» — помогу с настройкой 👌

В комментарии к этому посту — результат анализа одного из моих проектов этим агентом.

#юмор
Руководитель: А давай внедрим DevOps SRE? На хабре статей почитаешь как, разберешься.
Инженер: ...

#юмор
В этом наша стратегия!