aws-observability

aws-observability — официальный скилл AWS для наблюдаемости приложений и сервисов на AWS. Его область охватывает полный цикл от подключения сервиса к Application Signals через ADOT auto-instrumentation до работы с метриками, логами и трассировками. В описании прямо перечислены CloudWatch Logs Insights, Metrics, Alarms, Dashboards и EMF, X-Ray, CloudTrail и AWS Distro for OpenTelemetry. Скилл также рассматривает synthetics и canaries, а Application Signals связывает с ServiceEvents и автоматической инструментализацией. Он применим к EC2, ECS, EKS и Lambda; в матрице источника отдельно предусмотрены Python, Node.js, Java и .NET. Маршрутизация в исходном SKILL.md построена по задаче. Для onboarding Application Signals нужно читать application-signals-onboarding.md, а для передачи git и deployment metadata через CI/CD — application-signals-cicd-metadata.md. Платформенные инструкции вынесены в guides для сочетаний EC2, ECS, EKS или Lambda с поддерживаемым языком. Запросы CloudWatch Logs Insights направляются в log-insights.md; настройки metric, composite и anomaly alarms — в alarms.md; custom metrics и Embedded Metric Format — в metrics.md. Для X-Ray, ADOT и правил sampling предназначен tracing.md, а для виджетов, cross-account и cross-region dashboards — dashboards.md. Скилл полезен не только для чтения сигналов, но и для operational debugging. В наборе источника есть troubleshooting.md с маршрутом «ошибка → причина → исправление», cloudtrail.md для аудита событий и synthetics.md с ограничениями runtime, VPC и типовыми сбоями canary. Для Lambda с CDK предусмотрен alarm-template.ts, для ADOT collector — otel-config.yaml. Эти материалы дают отправные конфигурации и команды, но не делают сервис наблюдаемым автоматически: нужно проверить IAM, сеть, runtime, регион, endpoint и фактическое поступление данных. Отдельно выделен Dynamic Instrumentation. Он позволяет ставить breakpoint или snapshot в работающем сервисе, получать live data и связывать захват с диагностикой без обычного redeploy. Источник предупреждает, что этот режим изменяет live services и захватывает данные, поэтому перед create или delete требуется подтверждение пользователя, а действия нужно объяснять через observation → hypothesis → proposed action → expected result. Подозрение по исходному коду остаётся гипотезой до подтверждения runtime evidence; найденные snapshots могут содержать чувствительные данные и требуют аккуратной обработки. Практическая граница скилла тоже описана явно. Он предназначен для AWS observability, а не для общего application logging и не для security threat detection. Он лучше всего работает вместе с AWS MCP server, который позволяет выполнять CLI-команды, запрашивать CloudWatch и проверять конфигурацию, но те же рекомендации применимы при обычном AWS CLI. Версии runtime, квоты и feature matrix могут изменяться, поэтому перед production-развёртыванием их нужно сверять с актуальной документацией AWS, а не считать содержимое справочных файлов вечной гарантией.