How does the ECS Logging Audit help prepare my application for Elasticsearch?

This skill performs a read-only analysis of your codebase to inventory log calls, flag sensitive data (PII/secrets), and identify 'blind spots' where logging is missing, helping you prepare for a clean ELK stack integration.

Which programming languages and logging frameworks are supported?

The skill is designed to work with common backend stacks (like Node.js/NestJS) and popular logging libraries; it automatically detects your runtime and logger configuration during the scan.

Will this skill automatically change my code to comply with ECS standards?

No, this is a read-only audit tool that identifies issues and provides a 'keep/enrich/drop' verdict table without modifying a single line of your source code.

What is the difference between this free Audit skill and the full Retrofit version?

The free version provides a comprehensive audit report and a full ECS retrofit summary, while the full 'ECS Logging Retrofit' skill (available separately) automates the code rewrites and Filebeat configuration.

Are there any specific security permissions or setup steps required to run the audit?

Because it is read-only and runs via a single command, you only need to grant it access to read your repository; no complex environment configuration or database access is required.

ECS Logging Audit (Free)

Summary

Audited 3 log calls in a NestJS 11 service (1,100 lines): 1 keep, 1 enrich, 1 drop, plus 1 data leak and 2 modules with no logging at all.

Log call inventory

File:line	Current call	Verdict	Why
src/main.ts:37	Logger.error('Failed to start...')	keep	already meaningful, format conversion only
key-value.service.ts:26	console.error(err)	enrich	bare error, no context or outcome
key-value.service.ts:47	console.log(updateKeyValueDto)	drop	dumps the full request DTO into logs (data leak)

Risky logging

1 call writes a whole request DTO: whatever a client sends lands raw in production output.

The gap

No structured logger installed; logs are plain text. Modules company-name-validation and health log nothing, so their failures would be invisible in Kibana. A finding beyond the table: the bootstrap catch never fires for database failures, because NestJS's default abortOnError exits the process first.

Next steps

Fix the DTO leak now (one deleted line)
A full ECS retrofit for this stack: nestjs-pino with the official ECS formatter, service.name from env, Filebeat container input

About this skill

Getting an app's logs into Elasticsearch starts with knowing what you have. Most codebases fail that check in interesting ways: console.log(dto) calls that dump whatever a client sends, error handlers that log a bare err with no context, and entire modules where failures never get logged at all.

This skill runs that audit in one command. It is read-only and changes nothing.

What it does

Detects your stack, logger, and runtime
Inventories every log call into a keep / enrich / drop table with reasons
Flags secrets, tokens, and personal data being written to logs
Lists the modules with no logging at all, where failures would be invisible in Kibana
Summarizes what a full ECS retrofit would involve for your stack

Proven on a real service

On the first production app this ran against, the audit found the app's only error log was dead code: NestJS's default abortOnError exits the process before bootstrap().catch ever fires.

Free vs full

This audit edition is free and read-only. The full version, ECS Logging Retrofit (also on Agensi), applies the changes: converts calls to ECS JSON with the official formatter for your logger, rewrites messages so variables become queryable fields, and generates a working filebeat.ecs.yml. MIT licensed; source at github.com/Erick-CM/ecs-logging-audit.

Frequently Asked Questions

ECS Logging Audit (Free)