JavaNotes

Инженерные инструменты эксплуатации

2 min read

Инженерные инструменты эксплуатации

Эта заметка связывает инструменты, которыми я пользуюсь после написания кода. Их задача — ответить на конкретный вопрос о системе: что запущено, где сломалось, с какой конфигурацией и что изменилось.

Карта

  • контейнеры и локальное окружение — Docker;
  • Linux-процессы, сеть и файлы — Linux;
  • оркестрация контейнеров — Kubernetes и k3s;
  • просмотр Kubernetes-кластера — Lens;
  • логи Java-приложения — Log4j;
  • история изменений — Основы GIT;
  • безопасный доступ к узлу — SSH протокол;
  • сообщения и consumer groups — Kafka;
  • исполняемые бизнес-процессы — Camunda 7 и BPMN.

Лестница диагностики

Я начинаю с наблюдаемого симптома и двигаюсь от внешнего слоя к внутреннему:

клиентский запрос
→ DNS / сеть / TLS
→ ingress или port
→ pod / container
→ process
→ application logs
→ dependency
→ data

Так проще не перепутать причину со следствием. Например, Connection refused и HTTP 500 требуют разных веток поиска: в первом случае соединение не установлено, во втором приложение уже приняло запрос.

До изменения состояния

Сначала собираю доказательства:

  • точное время и часовой пояс;
  • окружение, namespace и имя workload;
  • request/correlation id, если он есть;
  • версия артефакта или image digest;
  • команда и полный текст ошибки;
  • последние события и логи предыдущего контейнера;
  • отличие от рабочего окружения.

Перезапуск может убрать симптом вместе с данными для расследования. Поэтому сначала смотрю, потом меняю.

Минимальная последовательность для Kubernetes

kubectl config current-context
kubectl get pods -A
kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp
kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous

Эти команды отвечают на разные вопросы:

КомандаЧто даёт
getтекущее состояние и размещение
describeконфигурацию, conditions и события объекта
eventsхронологию решений scheduler/kubelet/controllers
logsвывод приложения
logs --previousвывод завершившегося контейнера

Как фиксирую результат

Для повторяемой проблемы сохраняю:

  1. симптом;
  2. минимальный способ воспроизведения;
  3. факты, которые сузили поиск;
  4. корневую причину;
  5. изменение;
  6. способ проверить результат;
  7. технический вывод, который пригодится в другом проекте.

Именно по этой схеме записаны Инженерные кейсы.

Связанные заметки

Graph View

Backlinks