fleet/server/platform
Victor Lyuboslavsky 07949df530
Improved OpenTelemetry error handling (#38757)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or
remove if NA -->
**Related issue:** Resolves #38756 

- Changed to NOT mark many client errors as exceptions
- Instead, added client_error and server_error metrics that can be used
to alert on unusual error rates

# Checklist for submitter

- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.

## Testing

- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Added separate metrics for distinguishing between client and server
errors, enhancing observability and monitoring capabilities.

* **Bug Fixes**
* Client request errors no longer incorrectly appear in error tracking
as exceptions; improved accuracy of error reporting to external
services.
* Adjusted logging levels for authentication and enrollment operations
to provide clearer diagnostics.

<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-01-26 17:07:32 -06:00
..
authz Activity bounded context: /api/latest/fleet/activities (1 of 2) (#38115) 2026-01-19 09:07:14 -05:00
endpointer Implement trusted proxies config (#38471) 2026-01-19 22:13:37 -06:00
http Improved OpenTelemetry error handling (#38757) 2026-01-26 17:07:32 -06:00
middleware Moved common endpointer packages to platform dir. (#37780) 2026-01-06 14:23:07 -06:00
mysql Improved OpenTelemetry error handling (#38757) 2026-01-26 17:07:32 -06:00
arch_test.go Moved common_mysql package to server/platform/mysql (#38017) 2026-01-08 13:17:19 -06:00
README.md Moved common_mysql package to server/platform/mysql (#38017) 2026-01-08 13:17:19 -06:00

Platform packages

This directory contains infrastructure and cross-cutting technical concerns that are independent of Fleet's business domain. These packages provide foundational capabilities used across the codebase.

Platform vs domain

Following separation of concerns, we distinguish:

  • Platform (infrastructure): Technical concerns like database connectivity, HTTP utilities, middleware, and transport-level error handling. These packages have no knowledge of Fleet's business domain.
  • Domain (business logic): Feature-specific code organized into bounded contexts. Domain packages depend on platform packages, not the reverse.

Guidelines

  • Platform packages must not import domain packages
  • Platform packages should be general-purpose and reusable
  • Architectural boundaries are enforced by arch_test.go