# Dynatrace

Dynatrace: Unified Observability — Drive business transformation with contextual analytics, AI, and automation. 

To add a Dynatrace destination to Axoflow, complete the following steps.

## Prerequisites

  * An [access token](<https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens>) to your Dynatrace instance. The token must have access to the [Log ingestion API endpoint](<https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-api/basics/dynatrace-api-authentication>).

  * Your AxoRouters that are sending data to Dynatrace must have network access to the following [Log Ingestion endpoints](<https://docs.dynatrace.com/docs/analyze-explore-automate/logs/lma-log-ingestion/lma-log-ingestion-via-api>):

    * For the **Cloud** collector, when you’re sending data directly to the Dynatrace SaaS: `https://{your-environment-id}.live.dynatrace.com/api/v2/logs/ingest`
    * For the `ActiveGate` collector: `https://{your-activegate-domain}:9999/e/{your-environment-id}/api/v2/logs/ingest`

If nothing prevents it, we recommend using the **Cloud** collector.

  * Make sure to configure the [limits of your Dynatrace instance](<https://docs.dynatrace.com/docs/analyze-explore-automate/logs/lma-limits>) to make sure it can ingest the amount of data you’re sending.




## Steps

  1. Create a new destination.

     1. Open the AxoConsole.
     2. Select **Destinations > \+ Add Destination**.
  2. Configure the destination.

     1. Select **Dynatrace**.

     2. Enter a name for the destination.

![Configure the Dynatrace destination](/docs/axoflow/destinations/dynatrace/destination-simple.png)

     3. Enter the token you’ve created into the **Token** field.

     4. Select the Dynatrace **Bucket** type (**Logs** or **Security events**) where you want to send the data. Where exactly the data will be stored in Dynatrace depends on your [Bucket assignment rules](<https://docs.dynatrace.com/docs/shortlink/lma-bucket-assignment#assign-log-data-to-a-bucket>).

     5. Select the type of Dynatrace **Collector** where you want to send the data:

        * **Cloud** : Send data directly to your Dynatrace SaaS subscription.
        * **ActiveGate** : Send data directly to a local ActiveGate endpoint.
        * **Advanced** : Specify a custom URL endpoint.

If nothing prevents it, we recommend using the **Cloud** collector.

     6. Configure the endpoint of the destination, depending on the collector type you’ve selected.

        * **Cloud** : Provide your **Environment Id** for your Dynatrace SaaS subscription.

        * **ActiveGate** :

          * Provide your **Environment Id** for your Dynatrace SaaS subscription.
          * Enter the **Domain** (or hostname) where your Dynatrace ActiveGate is running.
          * Enter the **Port** number where ActiveGate is listening on. Usually it’s `9999`. and optionally the **Port** of the ActiveGate endpoint where you want to send your data.
        * **Advanced** : Specify a custom **URL** endpoint.

     7. (Optional) Set other options as needed for your environments.

        * **Timeout**: The number of seconds to wait for a log-forwarding request to complete, and attempt to reconnect the server if exceeded. If the timeout is exceeded, AxoRouter attempts to reconnect the destination. The default (`0`) is unlimited. For more details, see the [AxoSyslog documentation](<https://axoflow.com/docs/axosyslog-core/chapter-destinations/configuring-destinations-http-nonjava/reference-destination-http-nonjava/#http-options-timeout>).
        * **Disk Buffer**: Explicitly enable or disable disk buffer on AxoRouter. Default value: **Enabled**.

AxoRouter can store messages on the local disk if the destination or the network connection to the destination becomes unavailable. AxoRouter automatically sends the stored messages (in the order they were received) to the destination when the connection is reestablished. Note that the disk buffer is separate from AxoStore.

**Disk buffer capacity (bytes per worker)** : Size of the disk buffer files in bytes. This value applies for each worker. Default value is 100MiB (104857600 bytes), which is also the recommended minimum.

The disk required for using disk buffering is **Disk buffer capacity (bytes per worker)*** **Number of Workers** for each destination of AxoRouter.

        * **Batch Bytes**: Sets the maximum size of payload in a batch. If the size of the messages reaches this value, AxoRouter sends the batch to the destination even if the number of messages is less than the value of the batch lines option.

**CAUTION:**

When setting **Batch Bytes** :

          * Note that the actual HTTP request will be about 4KB larger because of the request headers.
          * Check the configuration of your destination, as SaaS solutions and ingress controllers often limit the maximal size of HTTP requests. If the sum of **Batch Bytes** and the request headers exceeds this limit, the data will be rejected. (In case of NGINX, with a `client intended to send too large body` error message.)

        * **Batch Lines**: Number of lines sent to the destination in one batch. AxoRouter waits for this number of lines to accumulate and sends them off in a single batch. Increasing this number increases throughput as more messages are sent in a single batch, but also increases message latency.

Note that **Initial window size** * **Maximum Connections** must be greater or equal than **Batch lines** * **Number of workers** for all the sources that feeds a given destination. Otherwise, the destination worker might be unable to send data until **Batch timeout** expires, even if there’s data available.

For more details, see the [AxoSyslog documentation](<https://axoflow.com/docs/axosyslog-core/chapter-destinations/configuring-destinations-http-nonjava/reference-destination-http-nonjava/#batch-lines>).

        * **Batch Timeout**: Maximal time in milliseconds to wait for a batch to be filled before sending it. The default value (`-1`) means that the batch should be full before sending, which may result in a long wait if the incoming traffic is low. For more details, see the [AxoSyslog documentation](<https://axoflow.com/docs/axosyslog-core/chapter-destinations/configuring-destinations-http-nonjava/reference-destination-http-nonjava/#batch-timeout>).

        * **Content compression**: Specifies the compression to use when sending data to the destination. `No compression` explicitly disables compression. Other possible values: `Gzip`, `Deflate`. Select only compression that your destination supports and has enabled. Default value: `No compression`
        * **Number of Workers**: Used for scaling the destination in case of high message load. Specifies the number of worker threads AxoRouter uses for sending messages to the destination. The default is 1. If high message throughput is not a concern, leave it on 1. For maximum performance, increase it up to the number of CPU cores available on AxoRouter. For more details, see the [AxoSyslog documentation](<https://axoflow.com/docs/axosyslog-core/chapter-destinations/configuring-destinations-http-nonjava/reference-destination-http-nonjava/#workers>).
        * **Response actions**: Specifies what AxoRouter does with the log message, based on the response code received from the destination.

          * If the status code begins with 2 (for example, `200`), AxoRouter assumes the message was successfully sent.
          * If you’ve configured a custom action in AxoConsole for the status code, AxoRouter performs the specified action.
          * If the status code appears in the [default response actions table](../../docs/axoflow/destinations/dynatrace/index.md#default-actions), AxoRouter performs the specified action.
          * For other status codes, AxoRouter disconnects.

To add a custom response action, select **Add new action** , then enter the **HTTP status code** and the related **Action**. The following actions are available:

          * **Disconnect** : Keep trying to resend the message indefinitely.
          * **Drop** : Drop the message without trying to resend it.
          * **Retry** : Retry sending the message for a maximum of 3 times.
          * **Success** : Assume the message was successfully sent.
Show default actions code | explanation | action  
---|---|---  
100 | “Continue” | disconnect  
101 | “Switching Protocols” | disconnect  
102 | “Processing” | retry  
103 | “Early Hints” | retry  
200 | “OK” | success  
201 | “Created” | success  
202 | “Accepted” | success  
203 | “Non-Authoritative Information” | success  
204 | “No Content” | success  
205 | “Reset Content” | success  
206 | “Partial Content” | success  
300 | “Multiple Choices” | disconnect  
301 | “Moved Permanently” | disconnect  
302 | “Found” | disconnect  
303 | “See Other” | disconnect  
304 | “Not Modified” | retry  
307 | “Temporary Redirect” | disconnect  
308 | “Permanent Redirect” | disconnect  
400 | “Bad Request” | disconnect  
401 | “Unauthorized” | disconnect  
402 | “Payment Required” | disconnect  
403 | “Forbidden” | disconnect  
404 | “Not Found” | disconnect  
405 | “Method Not Allowed” | disconnect  
406 | “Not Acceptable” | disconnect  
407 | “Proxy Authentication Required” | disconnect  
408 | “Request Timeout” | disconnect  
409 | “Conflict” | disconnect  
410 | “Gone” | drop  
411 | “Length Required” | disconnect  
412 | “Precondition Failed” | disconnect  
413 | “Payload Too Large” | disconnect  
414 | “URI Too Long” | disconnect  
415 | “Unsupported Media Type” | disconnect  
416 | “Range Not Satisfiable” | drop  
417 | “Expectation Failed” | disconnect  
418 | “I’m a teapot” | disconnect  
421 | “Misdirected Request” | disconnect  
422 | “Unprocessable Entity” | drop  
423 | “Locked” | disconnect  
424 | “Failed Dependency” | drop  
425 | “Too Early” | drop  
426 | “Upgrade Required” | disconnect  
428 | “Precondition Required” | retry  
429 | “Too Many Requests” | disconnect  
431 | “Request Header Fields Too Large” | disconnect  
451 | “Unavailable For Legal Reasons” | drop  
500 | “Internal Server Error” | disconnect  
501 | “Not Implemented” | disconnect  
502 | “Bad Gateway” | disconnect  
503 | “Service Unavailable” | disconnect  
504 | “Gateway Timeout” | retry  
505 | “HTTP Version Not Supported” | disconnect  
506 | “Variant Also Negotiates” | disconnect  
507 | “Insufficient Storage” | disconnect  
508 | “Loop Detected” | drop  
510 | “Not Extended” | disconnect  
511 | “Network Authentication Required” | disconnect  
  
  3. Create a [flow](../../docs/axoflow/data-management/index.md) to connect the new destination to an [AxoRouter instance](../../docs/axoflow/provisioning/axorouter/index.md).
     1. Select **Flows**.

     2. Select **Add Flow**.

     3. Enter a name for the flow, for example, `my-test-flow`.

![Create a flow](/docs/axoflow/img/data-management/flow-management/flows/create-flow.png)

     4. In the **Router Selector** field, enter an expression that matches the router(s) you want to apply the flow. To select a specific router, use a name selector, for example, `name = my-axorouter-hostname`.

You can use any labels and metadata of the AxoRouter hosts in the Router selectors, for example, the hostname of the AxoRouter, or any [custom labels](../../docs/axoflow/onboard-hosts/hosts/add-host-metadata/index.md).

        * If you leave the **Router Selector** field empty, the selector will match every AxoRouter instance.
        * To select only a specific AxoRouter instance, set the `name` field to the name of the instance as selector. For example, `name = my-axorouter`.
        * If you set multiple fields in the selector, the selector will match only AxoRouter instances that match all elements of the selector. (There in an AND relationship between the fields.)
     5. Select the **Destination** where you want to send your data. If you don’t have any destination configured, you can select **\+ Add** in the destination section to create a new destination now. For details on the different destinations, see [Destinations](../../docs/axoflow/destinations/index.md).

        * If you don’t have any destination configured, see [Destinations](../../docs/axoflow/destinations/index.md).
        * If you’ve already created a [store](../../docs/axoflow/destinations/axostore/index.md), it automatically available as a destination. Note that the **Router Selector** of the flow must match only AxoRouters that have the selected store available, otherwise you’ll get an error message.
        * If you want to send data to another AxoRouter, enable the **Show all destinations** option, and select the connector of the AxoRouter where you want to send the data.

![AxoRouter as destination](/docs/axoflow/img/data-management/flow-management/flows/axorouter-destination.png)

     6. (Optional) To process the data transferred in the flow, select **Add New Processing Step**. For details, see [Processing steps](../../docs/axoflow/data-management/processing/index.md). For example:

        1. Add a **Classify** , a **Parse** , and a **Reduce** step, in that order, to automatically remove redundant and empty fields from your data.
        2. To select which messages are processed by the flow, add a **Select Messages** step, and enter a filter into the **AQL Expression** field. For example, to select only the messages received from Fortinet FortiGate firewalls, use the `meta.vendor = fortinet AND meta.product = fortigate` query.
        3. **Save** the processing steps.

![Example processing steps](/docs/axoflow/img/data-management/flow-management/flows/processing/example-processing-steps.png)

     7. Select **Add**.

     8. The new flow appears in the **Flows** list.

![The new flow](/docs/axoflow/img/data-management/flow-management/flows/new-flow.png)




## Related message fields

You can use the [following message fields](../../docs/axoflow/reference/message-schema/reference/index.md#meta.destination.dynatrace) to modify messages sent to this destination using [processing steps](../../docs/axoflow/data-management/processing/index.md).