* Chore: Migrate to use buf for protobuf generation
* fix codeowners
* fixes after review
* docs/tooling for installing buf
* add back codeowners
* Update upgrading-dependencies.md
Co-authored-by: Giuseppe Guerra <giuseppe.guerra@grafana.com>
* sdk v0.229.0
---------
Co-authored-by: Giuseppe Guerra <giuseppe.guerra@grafana.com>
* Chore: Upgrade/fix deps after thema removal
* github.com/deepmap/oapi-codegen v1.14.0
* github.com/deepmap/oapi-codegen v1.15.0
* github.com/deepmap/oapi-codegen v1.16.0
* fix for dep used in enterprise
* github.com/deepmap/oapi-codegen/v2 v2.0.0
* oapi-codegen/v2 v2.1.0, kin-openapi v0.122.0, sdk
* keep kin-openapi at v0.122.0 and allow SDK to use v0.124.0
* remove github.com/deepmap/oapi-codegen v1 dep
* fix owner
* add back github.com/deepmap/oapi-codegen v1 dep
* upgrade github.com/influxdata/influxdb-client-go/v2 to get rid of deepmap/oapi-codegen
* migrate to oapi-codegen/runtime
* sdk
* sdk v0.227.0
Fixes so that auth middleware trace/span doesn't wrap the next handlers.
Allow tracing service name to be overridden in standalone apiserver.
Change k8s api tracing operation name to KubernetesAPI from
grafana-apiserver (which is the service name)
* Chore: Remove unused dependenices in plugin client middlewares
* refactor logger middleware to remove cfg dependency
* hack to make tracing work in api group builders
Adds support for logs (specify level), metrics (enable metrics and Prometheus /metrics endpoint
and traces (jaeger or otlp) for standalone API server. This will allow any grafana core service
part of standalone apiserver to use logging, metrics and traces as normal.
Check embedded errors in query data response for plugin metrics/logs status label.
Plugin Request Completed log messages are now logged with info level if status=ok,
otherwise error level.
Fixes#76769
Moving call resource API stream handling within plugin management as a utility/wrapper.
Closes#66889
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
Automatically forward core plugin request HTTP headers in outgoing HTTP requests.
Core datasource plugin authors don't have to specifically handle forwarding of HTTP
headers, e.g. do not have to "hardcode" the header-names in the datasource plugin,
if not having custom needs.
Fixes#57065
Grafana would forward the X-Grafana-User header to backend plugin request when
dataproxy.send_user_header is enabled. In addition, X-Grafana-User will be automatically
forwarded in outgoing HTTP requests for core/builtin HTTP datasources.
Use grafana-plugin-sdk-go v0.147.0.
Fixes#47734
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
Removes request/response connection/hop headers for call resource in similar
manner as Go's reverse proxy functions. Also removes Prometheus datasource
custom call resource header manipulation in regards to hop-by-hop headers.
Fixes#60076
Ref #58646
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
Adding support for backend plugin client middlewares. This allows headers in outgoing
backend plugin and HTTP requests to be modified using client middlewares.
The following client middlewares added:
Forward cookies: Will forward incoming HTTP request Cookies to outgoing plugins.Client
and HTTP requests if the datasource has enabled forwarding of cookies (keepCookies).
Forward OAuth token: Will set OAuth token headers on outgoing plugins.Client and HTTP
requests if the datasource has enabled Forward OAuth Identity (oauthPassThru).
Clear auth headers: Will clear any outgoing HTTP headers that was part of the incoming
HTTP request and used when authenticating to Grafana.
The current suggested way to register client middlewares is to have a separate package,
pluginsintegration, responsible for bootstrap/instantiate the backend plugin client with
middlewares and/or longer term bootstrap/instantiate plugin management.
Fixes#54135
Related to #47734
Related to #57870
Related to #41623
Related to #57065
* Plugins: Remove support for V1 manifests
* Plugins: Make proxy endpoints not leak sensitive HTTP headers
* Security: Fix do not forward login cookie in outgoing requests
(cherry picked from commit 4539c33fce)
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
A first rough draft of adding some guidance/conventions for instrumenting
Grafana with logs, metrics and traces together with how to run things
locally to query/visualize logs, metrics and traces.
Closes#55470
Co-authored-by: Emil Tullstedt <emil.tullstedt@grafana.com>
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
Co-authored-by: Carl Bergquist <carl.bergquist@gmail.com>
Introduces a FromContext method on the log.Logger interface that
allows contextual key/value pairs to be attached, e.g. per request,
so that any logger using this API will automatically get the per request
context attached. The proposal makes the traceID available for
contextual logger , if available, and would allow logs originating from
a certain HTTP request to be correlated with traceID.
In addition, when tracing not enabled, skip adding
traceID=00000000000000000000000000000000
to logs.
Removes various custom headers logic sprinkled around in the backend.
It should automatically be applied to outgoing HTTP requests via the
CustomHeadersMiddleware.
This also removes decryption of SecureJSONData to populate custom
headers in ngalert which seemed to have caused a ton of CPU usage.
Earlier we only allowed symlinks in plugins starting with grafana- in zip archives when
installing plugins using the grafana-cli. This changes so that symlinks in zip archives
containing relative links to files in the zip archive are always allowed when installing
plugins. The reasoning behind this is that Grafana per default doesn't load a plugin
that has an invalid plugin signature meaning that any symlink must be included in
the plugin signature manifest.
Co-authored-by: Will Browne <will.browne@grafana.com>
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
For a proxied request, e.g. Grafana's datasource or plugin proxy:
If the request is cancelled, e.g. from the browser, the HTTP status code is
now 499 Client closed request instead of 502 Bad gateway.
If the request times out, e.g. takes longer time than allowed, the HTTP status
code is now 504 Gateway timeout instead of 502 Bad gateway.
This also means that request metrics and logs will get their status codes
adjusted according to above.
Fixes#46337Fixes#46338
Refactors GetPluginDashboards/LoadPluginDashboard by moving database
interaction from plugin management to the plugindashboards service.
Fixes#44553
Co-authored-by: Will Browne <wbrowne@users.noreply.github.com>
Fixing a couple bugs, adds some tests and hopefully decrease
lock contention when logging.
Switching from using sync.RWMutex to go-kit SwapLogger.
Fixes bug when creating a new logger from an existing one that
screwed up the keyvals and/or lost the logger name.
Ref #44681
Marcus Efraimsson
