Observability in Terraform providers primarily comes from logging. The provider uses HashiCorp’s structured logging via the tflog package (from the terraform-plugin-log module) for emitting logs (Implement logging | Terraform | HashiCorp Developer). This approach provides context-rich logs that can be filtered by verbosity levels (TRACE, DEBUG, INFO, WARN, ERROR). As a contributor, you should use tflog to add useful debug or info statements in the code. For example, logging when entering a create function or when receiving a response from the Power Platform API can greatly aid debugging for users and maintainers. Avoid using print statements or the standard library logger, as they won't integrate with Terraform’s logging controls. Instead, use tflog.Info(ctx, "message"), tflog.Debug(ctx, "message", map[string]interface{}{"field": value}), etc., which attaches structured data and respects user-set log levels (Implement logging | Terraform | HashiCorp Developer).
The provider is configured so that when a user sets TF_LOG or TF_LOG_PROVIDER environment variables, the logs from tflog calls will appear. By default, normal usage might not show any logs, but if a user is troubleshooting and sets TF_LOG=DEBUG, our provider's debug logs will help pinpoint issues. We strive to log enough information at DEBUG level to diagnose issues (like API endpoints called, IDs of resources - but no sensitive info), without overwhelming at INFO level (which should be more high-level events). Do not log secrets or PII. For instance, never log full access tokens or raw responses that contain personal data. Mask or omit sensitive fields. HashiCorp’s logging library has some facilities to filter sensitive data as well.
In addition to logs, telemetry is part of observability. This provider collects minimal telemetry data by including certain headers in API requests to Power Platform. Specifically, a session ID and a user agent identifying Terraform usage may be sent. Users can opt out of this telemetry by setting the provider configuration telemetry_optout = true (Power Platform Terraform Provider). When telemetry is opted out, the provider will not include those identifying headers in requests. There is no other data being collected. As a developer, just be aware that this mechanism exists; it’s implemented in the provider initialization. The telemetry is useful for the maintainers to understand usage patterns and improve the provider, but respecting user privacy and choice to opt out is paramount.
If you make changes to how API calls are made (for example, using a new SDK or altering the HTTP client), ensure that the telemetry headers and logging integration remain intact. Also, any new subsystem (like if we introduce metrics or tracing in the future) should follow Terraform’s patterns and Microsoft Open Source guidelines.
To summarize, for observability: use structured logging (tflog) conscientiously, avoid exposing sensitive data, and maintain the telemetry opt-out honor. This will help both developers and users to monitor and troubleshoot the provider’s behavior in the field.