cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Send data to Dynatrace Managed Clsuter through a locally run extension[dt-sdk]

g_kat
Helper

Hi,

We are on Dynatrace Managed and are trying our hand in implementing our Python Extensions 2.0 using the dt-sdk.

For this reason we have setup a "development" server with VSCode and Python 3.10 with dt-sdk module. We initialized the workspace and connected VSCode to our Environment and from there downloaded an existing 2.0 extension to modify. We made a couple minor changes, crated an activation configuration for remote execution and run it locally. In the output, it's polling the endpoints and logs sending data to EEC(which is not running in this development server), yet no metrics are reported in the DT environment.

Now, my theory is that I'm missing something in the configuration. Considering the DEV server has access to an AG, can I somehow instruct the sdk module to send the data to the AG in order to reach the environment. Also, I guess that putting an agent in the server and using the --local-ingest would achieve the same result.

 

Thanks,

George

4 REPLIES 4

Julius_Loman
DynaMight Legend
DynaMight Legend

Data is reported to Dynatrace environment only if the extension is running in the environment. If you run it locally using dt simulate or in the vs code, it does not send data, but writes it on the stdout output. To have data in your environment, you must build your extension and deploy it.

Certified Dynatrace Master | Alanata a.s., Slovakia, Dynatrace Master Partner

I was hoping to be able to test the metric ingestion without having to build and deploy every time, and based on the existence of a --local-ingest flag I assumed something could be done to communicate with a remote EEC. Oh well, it's probably less hassle to do it your way than digging through the framework 🙂

Thank you for the answer.

In theory we could add support for it, but it comes with quite a bit of maintenance burden:

  • Support custom certificates for managed, which our simple http client doesn't
  • Support proxy configurations, which the http client also doesn't support
  • Add parameters for the tenant URL, the API token, the proxy, etc


    We don't want to include any dependencies to the SDK that we don't need, and this would have us add dependencies or make the code much more complicated when differentiating between SDK mode and EEC mode

    Another side effect of this is that it would make it easier for folks to publish extensions without first deploying them to an AG or OA, which can lead to all sorts of bugs because the extension install step was not "tested" since they could test all metrics/dashboards/entities without ever installing the extension.

Thank you David for the detailed insights. It makes total sense the way you put it, although testing metrics/dashboards/entities without uploading the extension over and over again sounds quite appealing to be honest.

 

Featured Posts