Dynatrace is a popular analytics and data insights platform.

‍

BPL's Dynatrace Metrics Emitter for Apiman lets you send Apiman metrics data directly from your Apiman Gateways to Dynatrace over HTTP.

‍

Features:

• Our implementation uses a variety of robust strategies to optimise performance.
• Tolerates short periods of network outage without losing data (will retry).
• Can capture custom headers and query parameters along with standard data.

‍

QuestDB is a columnar time-series database that enables fast queries against large datasets, such as metrics.

‍

The QuestDB Metrics Emitter for Apiman writes Apiman metrics directly from the Apiman Gateway to QuestDB, using a variety of techniques to optimise performance and avoid losing records during short network interruptions.

‍

Timescale is a high-performance time-series database built on top of Postgres.

‍

The Timescale Metrics Emitter for Apiman writes Apiman metrics directly from the Apiman Gateway to Timescale, using a variety of techniques to optimise performance and avoid losing records during short network interruptions.

Splunk is a popular analytics and data insights platform.

‍

BPL's Splunk Metrics Emitter for Apiman lets you send Apiman metrics data directly from your Apiman Gateways to Splunk over HTTP.

‍

Features:

• Our implementation uses a variety of robust strategies to optimise performance.
• Tolerates short periods of network outage without losing data (will retry).
• Can capture custom headers and query parameters along with standard data.

BPL are developing an Apiman Kubernetes operator to automate a range of tasks and more easily enable a range of K8s-specific integration patterns.

‍

If you have any specific capabilities you would like from our Kubernetes operator, please let us know.

If you want a more immutable style of Apiman deployment, you can use our example GitOps pipeline to "bake" an Apiman deployment (usually Docker/containers).

‍

This means that your Apiman configuration is stored statically in git, and then everything you need for your deployment is burned into Docker images during the build. You can even deploy with a local-only database (noting that if you want distributed rate limiting, etc, then you still need some shared storage).

‍

One cool feature of this flow is that you can still augment Apiman after deployment, which is useful for manual administrator actions, debugging, etc.

‍

We can work with you to enable this workflow on your chosen CI/CD system and deployment environment.

Deploy Apiman on Kubernetes with our service definition templates, broken down into its constinuent components.

‍

You can modify them however you wish, and we're happy to work with you to tweak them for your needs.

Specific support for emitting Apiman metrics directly into InfluxDB 2 (including batching), with explicit settings to support the new architecture introduced in InfluxDB 2.

‍

This metrics plugin has support for capturing arbitrary headers and query parameters (as per configuration).

Support for writing Apiman Metrics directly into Apache Kafka, with the usual suite of settings, including batching.

‍

By pushing Apiman Metrics into Kafka, you can easily sink your gateway's valuable metrics data into a wide variety of datastores and analysis platforms. You can even perform ETL operations directly in Kafka, using manually built pipelines or via Confluent's ksql.

Integration between Apiman and Auth0, allowing sign-in to the Apiman Manager and validation of tokens against the Apiman Gateway.

‍

Functionally equivalent to Keycloak's current level of integration, but with Auth0.

Integration between Apiman and Okta, allowing sign-in to the Apiman Manager and validation of tokens against the Apiman Gateway.

‍

Functionally equivalent to Keycloak's current level of integration, but with Okta.

An improved rate limiting and quotas component that is optimised for distributed environments with extremely high throughput, whilst maintaining low latency and limited-to-no overshoot in most scenarios.

‍

This is a drop-in replacement for the default rate limiting component and hence will work transparently with any existing in-built or custom policies that use Apiman's RateLimiterComponent, such as the rate limiting policy, quotas policy, etc.

‍

Benefits:

• Designed specifically to works with multiple Apiman gateways via a distributed algorithm.
• Handles high request volumes with low latency.
• Avoids rate limit overshoot in most scenarios (i.e. strict limits in most situations).
• Avoids putting high load on databases.
• Tolerates a range of network issues, with tradeoffs configurable by the user where appropriate.