- Home
- Skills
- Bitsoex
- Bitso Java
- Dynamic Loglevel Rfc 27
dynamic-loglevel-rfc-27_skill
- JavaScript
35
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill bitsoex/bitso-java --skill dynamic-loglevel-rfc-27- SKILL.md8.1 KB
Overview
This skill implements RFC-27 compliant runtime log level control for Java services. It explains correct log level usage, how to enable dynamic log levels in the estate-catalog, and how to change levels at runtime via the Developer Portal or Bitso CLI. Use it to debug production issues safely and to configure logging for services across the estate.
How this skill works
The skill inspects service registration in the estate-catalog and ensures a logs configuration enabling managed runtime control. Once enabled, it surfaces loggers and their current levels in the Developer Portal and exposes CLI commands to list, get, set, reset, and temporarily change levels. Changes propagate immediately across service instances and are recorded in an audit trail including who, when, and what changed.
When to use it
- You need to debug a production issue without redeploying code
- Enable runtime log control for a new Spring Boot service in estate-catalog
- Temporarily increase verbosity for a specific class or package to capture more context
- Automate or script log level changes across services via Bitso CLI
- Validate that a service appears in Developer Portal observability controls
Best practices
- Prefer the most specific logger (class) over package-level changes to minimize noise
- Use DEBUG for troubleshooting and INFO as the default production level for com.bitso.*
- Avoid logging sensitive data; never include credentials or PII
- Use temporary durations for elevated levels so they auto-reset and reduce blast radius
- Include correlation IDs and structured fields for consistent cross-service tracing
Example use cases
- Quickly set DEBUG on a payment processor class to reproduce a transaction bug, auto-reset after 15 minutes
- Enable temporary TRACE on a failing integration path across multiple services using a scripted CLI loop
- Register a new service in estate-catalog by adding logs.management: "managed" and logs.format to enable Developer Portal controls
- Audit who changed log levels and when via the Developer Portal or bitso logs level history before postmortem
FAQ
Add a logs block in your estate-catalog entity .cue file with management: "managed" and format set (json or plain-text), then merge the PR and wait for the next sync.
Will changes affect all instances immediately?
Yes. Applied changes propagate to all running instances instantly and temporary changes will auto-reset after the specified duration.