Log Levels: When to Use What
Understanding when and how to use different log levels appropriately in Triton logging for optimal debugging and monitoring.
Understanding Log Levels
Log levels in Triton follow a standard hierarchy from least verbose to most verbose:
ERROR
Failures impacting user flows or data integrity
Uncaught exceptions, failed DML batches, failed callouts, validation breaches
Don't log benign/expected conditions as ERROR
WARNING
Unexpected but recoverable states
Fallback behavior, degraded external service, approaching governor limits
Don't spam warnings on every retry unless unique
INFO
Lifecycle & business milestones
"Batch started/finished", "Wire loaded 250 rows", "Converted 12 Leads"
Don't log every loop iteration as INFO
DEBUG/FINE/FINER/FINEST
Developer diagnostics & verbose traces
Query shapes, branch decisions, payload snippets
Don't enable noisy DEBUG in prod; rely on dynamic level control
Guideline: Tune logging frequency by environment via metadata / runtime config. In lower environments, allow DEBUG/FINE; in production, default to INFO/WARN/ERROR and elevate temporarily when investigating.
Real-World Example: E-commerce Order Processing
// Order processing batch - appropriate level usage
public class OrderProcessingBatch implements Database.Batchable<SObject> {
public void execute(Database.BatchableContext bc, List<Order> scope) {
Long startTime = System.now().getTime();
// Set up template for all order processing logs
Triton.instance.setTemplate(
Triton.makeBuilder()
.category(TritonTypes.Category.Apex)
.type(TritonTypes.Type.Backend)
.area(TritonTypes.Area.OpportunityManagement)
);
// INFO: Business milestone
Triton.instance.log(
Triton.instance.fromTemplate()
.level(TritonTypes.Level.INFO)
.summary('Processing order batch')
.details('batchSize=' + scope.size())
);
try {
for (Order order : scope) {
// DEBUG: Individual record processing
Triton.instance.addLog(
Triton.instance.fromTemplate()
.level(TritonTypes.Level.DEBUG)
.summary('Processing order')
.details('orderId=' + order.Id + ', status=' + order.Status)
.relatedObject(order.Id)
);
processOrder(order);
}
// INFO: Success milestone with duration
Triton.instance.log(
Triton.instance.fromTemplate()
.level(TritonTypes.Level.INFO)
.summary('Order batch completed')
.details('processed=' + scope.size())
.duration(System.now().getTime() - startTime)
);
} catch (Exception e) {
// ERROR: Critical failure
Triton.instance.log(
Triton.instance.fromTemplate()
.exception(e)
.relatedObjects(new Map<Id, Order>(scope).keySet())
);
throw e;
}
}
}Level-Specific Guidelines
ERROR Level
Use for critical failures that require immediate attention:
Unhandled exceptions and system errors
Integration failures that break business processes
Data corruption or loss scenarios
Security violations or authentication failures
System resource exhaustion (CPU, memory, governor limits)
WARNING Level
Use for issues that may need attention but aren't critical:
Deprecated feature usage
Performance degradation indicators
Business rule violations that don't break the process
Retry scenarios and temporary failures
Approaching governor limits
INFO Level
Use for important business events and milestones:
Record creation, updates, and deletions
Process completion and major workflow steps
User actions and business transactions
Integration success and data synchronization
Scheduled job execution and completion
DEBUG Level
Use for detailed debugging information:
Method entry and exit points
Variable values and state changes
Decision points in business logic
Query results and data transformations
Performance timing information
FINE/FINER/FINEST Levels
Use for progressively more detailed debugging:
FINE: Loop iterations, conditional branches, minor state transitions
FINER: Individual record processing, detailed stack analysis
FINEST: Character-level operations, memory details, micro-optimizations
Environment-Specific Recommendations
Development Environment
Default Level: DEBUG or FINE
Purpose: Comprehensive debugging and development support
Considerations: Higher verbosity helps with development and testing
Staging Environment
Default Level: INFO
Purpose: Simulate production behavior while maintaining debugging capability
Considerations: Balance between debugging needs and production-like performance
Production Environment
Default Level: INFO or WARNING
Purpose: Focus on business events and actual problems
Considerations: Minimize performance impact while maintaining visibility
Troubleshooting Mode
Temporary Level: DEBUG or FINE
Purpose: Detailed investigation of specific issues
Considerations: Use metadata to elevate levels for specific areas temporarily
Performance Considerations
Higher log levels (FINE, FINER, FINEST) can impact performance
String concatenation and object serialization in logs should be minimized
Consider using conditional logging for expensive operations
Monitor log volume and adjust levels based on system performance
Best Practices Summary
Start Conservative: Begin with INFO level in production and adjust based on monitoring needs
Use Specific Rules: Create targeted log level rules for different functional areas
Monitor Volume: Keep an eye on log volume and adjust levels accordingly
Error Logging: Always log errors at the ERROR level - these should never be filtered out
Environment Tuning: Use different configurations for development and production environments
By understanding and properly configuring log levels, you can maintain comprehensive visibility into your application's behavior while keeping log volumes manageable and focused on the information that matters most for your specific use case.
Last updated