> For the complete documentation index, see [llms.txt](https://docs.teleskope.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.teleskope.ai/setup/deployment/deployments/telemetry-and-monitoring.md). # Telemetry and Monitoring {% hint style="info" %} **Applies to:** single-tenant SaaS, Teleskope-Managed deployments on AWS, Azure, and GCP, and Outpost deployments. Self-Managed customers typically operate their own monitoring, but that is a choice rather than a constraint. The same Helm chart options described here are available to you, and shipping telemetry to Teleskope's monitoring environment is a supported option if you would rather Teleskope hold operational visibility for support purposes. Talk to your Teleskope team about which model fits. {% endhint %} Where Teleskope operates your deployment, monitoring is part of the operational responsibility Teleskope takes on. To do that, Teleskope collects operational telemetry — logs, metrics, and cluster health — from the environment running in your cloud account. This page describes what is collected, where it goes, who can reach it, how long it is kept, and the controls you have over all of it. *** ## The telemetry stack Two independent layers, with different owners and destinations: | Layer | Destination | Owner | Default | | ------------------------------------------------------------- | --------------------------------- | --------- | ----------------------------------------------------------- | | **Datadog agent** — application logs, metrics, cluster events | Teleskope's Datadog organization | Teleskope | On for SaaS; per-deployment elsewhere | | **Cloud-native telemetry** — provider logging and monitoring | Your own cloud account and region | You | Partially enabled — several paid paths are deliberately off | The distinction matters for review purposes: cloud-native telemetry never leaves your account, while Datadog telemetry is the only path where operational data egresses to a third party. *** ## Where the Datadog agent is enabled Datadog is the primary observability backend for deployments Teleskope operates, and cloud-native telemetry is deliberately trimmed to avoid paying twice for the same signal. Which means the agent is on in most environments, but it is a per-deployment setting rather than something the chart forces: | Model | Default | | ---------------------- | ----------------------------------------- | | **Single-tenant SaaS** | **On** in all deployments | | **Teleskope-Managed** | Set per deployment, and enabled in most | | **Outpost** | Set per deployment, and commonly left off | | **Self-Managed** | Your choice | The chart itself ships with the component disabled, so no Datadog telemetry is collected implicitly: ```yaml datadog: enabled: false ``` Enabling it is an explicit decision recorded in your environment's values file. A deployment with no `datadog` block sends nothing to Datadog. Required product traffic, such as API calls, scan results, and an Outpost service heartbeat, is separate from Datadog telemetry. *** ## What the Datadog agent collects The agent is deployed from a source-controlled Helm template with a deliberately narrow scope. | Signal | Scope | Default | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | **Container logs** | Only the `teleskope` namespace. All other namespaces are explicitly excluded. Only warn and error level; info-level logs are dropped at the agent before transmission. | On when Datadog is enabled. Can be disabled independently. | | **Infrastructure metrics** | CPU, memory, disk, and pod/container health for Teleskope workloads. | On | | **Application metrics** | DogStatsD metrics from Teleskope services, plus Prometheus scraping restricted to `teleskope.*` metric names on explicitly annotated pods. | On | | **Kubernetes events** | Cluster-level events for health and diagnostics, via the cluster agent. | On. Can be disabled. | | **Traces (APM)** | Per-service opt-in only. Unlabelled pods are never instrumented. | **Off** | Namespace scoping is enforced at the agent through container include and exclude rules, not by convention: ```yaml container_include: "kube_namespace:teleskope" container_exclude: "kube_namespace:.*" ``` ### Not collected The following Datadog capabilities are not deployed and are absent from the agent configuration: * **Live process data** — no process-level command lines or arguments * **Network monitoring** — no system-probe, no NPM, no packet or flow capture * **Security agent modules** — no Cloud Workload Security, no CSPM * **Real User Monitoring** — no browser or end-user session data * **Anything outside the `teleskope` namespace** — including your own workloads on the same cluster The agent does not collect environment variables or secret contents. *** ## Cloud-native telemetry Cloud-native telemetry stays inside your own account, in your own region, under your retention and access policies. It is not uniformly enabled, though — where a provider-native path would duplicate what Datadog already collects, it is deliberately switched off rather than paid for twice. {% hint style="info" %} **Why some of this is off.** Provider-native log ingestion is billed per GB and Container Insights is billed per cluster. With Datadog as the primary backend, enabling both means paying twice to store the same signal. The defaults below reflect that, not a gap in coverage. Any of them can be turned on for your deployment if you want the data in your own provider tooling — the cost lands on your cloud bill, so it is your call. {% endhint %} ### AWS | Mechanism | Default | Notes | | -------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Container Insights metrics** (CloudWatch Observability EKS add-on) | **On** | Cluster and pod-level infrastructure metrics. Billed per cluster; can be disabled. | | **Container log ingestion to CloudWatch Logs** | **Off** | Deliberately disabled — Datadog is the log path. Can be enabled for any environment that needs logs retained in CloudWatch. | | **EKS control-plane logs** | **Audit only** | Other control-plane log types (API server, authenticator, scheduler, controller manager) are not enabled. | | **VPC flow logs** | **On** | Delivered to S3 in your account. | | **AWS Managed Prometheus** | **Off** | Opt-in per deployment. Several customers enable it. | CloudWatch log groups for cluster, application, and performance logs are always created, so the group names exist even where the corresponding data is not being shipped. Default retention is 365 days for cluster logs, 3 days for application logs, and 1 day for performance logs. ### GCP | Mechanism | Default | Notes | | ---------------------------------------------------- | -------------------------- | ---------------------------------------------------------------------------- | | **Cloud Logging** (workload and infrastructure logs) | **On** | Standard GKE behavior; no exclusion filters applied. | | **Cloud Monitoring** | **System components only** | Narrowed from the full component set. Google Managed Prometheus is disabled. | | **Project audit logs** | **On** | Admin read, data read, and data write across all services. | | **VPC and NAT flow logs** | **On** | 50% sampling on subnet flow logs. | ### Azure | Mechanism | Default | Notes | | -------------------------------------------- | ------------------ | --------------------------------------------------------------------------------- | | **Container Insights / Azure Monitor agent** | **Off** | Enabled by wiring a Log Analytics workspace, which is not provisioned by default. | | **AKS diagnostic settings** | **Not configured** | Available on request. | *** ## Optional components Each is enabled only when a deployment needs it: | Component | Purpose | Notes | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CloudWatch metric bridge** | Forwards CloudWatch metrics for managed services (RDS, SQS) into Datadog so database and queue health sit alongside application metrics. | AWS only. Reads metrics via a scoped IAM role; no data-plane access. Enabled alongside Datadog by default, and disabled per deployment where not wanted. | | **Synthetic monitoring** | External uptime and health-check probes against platform endpoints. | Can run from a private location inside your network. Does not require granting Datadog access to your cloud account. | | **Redis metrics exporter** | Exposes in-cluster cache metrics. | Off by default. | *** ## Data classification Telemetry is operational metadata, not scanned content. Nothing in the pipeline carries the contents of your data stores. **Metrics and events contain no customer data.** They are counters, gauges, and histograms labelled with operational dimensions — connector name, queue name, file type, HTTP status, error class, replica identifier. There is no path by which file contents or scan findings enter a metric. **Logs carry the only residual exposure.** Error-level logs can contain identifiers such as object and path names, hostnames, and connector names. They do not contain file contents, credentials, or scan findings. Where resource names are themselves sensitive, note that those names have already been transmitted to the platform as part of normal cataloguing, so Datadog introduces no new category of data — though it does introduce an additional processor holding it. {% hint style="info" %} If log collection is more exposure than your review allows, it can be disabled while keeping metrics and events. Metrics are the highest-value signal for performance diagnosis and carry no sensitive data at all. {% endhint %} *** ## Data residency | Data | Location | | ---------------------- | --------------------------------------------------------------------------------------- | | Datadog telemetry | Datadog **US5** site (`us5.datadoghq.com`), hosted in the United States on Google Cloud | | Cloud-native telemetry | Your own cloud account, in your deployment region | *** ## Retention | Data type | Retention | | ----------------------------------- | ------------------------------------------------------------------ | | Metrics — tags and values | 15 months | | Indexed logs | Determined by Teleskope's Datadog plan, and configurable per index | | APM errors | 15 days | | APM indexed spans | 15 or 30 days, determined by plan | | APM service and resource statistics | 30 days | Log retention is worth calling out, because it is a plan-level setting rather than a fixed product default. That also makes it the most adjustable figure here: your telemetry can be tagged and routed to a dedicated index with a retention period agreed with you — 3 or 7 days, for example — instead of inheriting whatever the general index uses. Ask your Teleskope team for the current configured value if you need it in writing. Datadog publishes its retention periods by data type at [Datadog Data Retention Periods](https://docs.datadoghq.com/data_security/data_retention_periods/). On expiry, data is deleted per Datadog's data-deletion practices. At the end of an engagement, Teleskope can additionally file a targeted deletion request for your tagged telemetry and confirm completion in writing. *** ## Access Access to Teleskope's Datadog organization is limited to engineering and support personnel who need it to operate customer deployments. Access is via SSO with MFA enforced, under role-based permissions. Two additional controls are available on request: * **A named access list** — the specific personnel who can view your telemetry * **Scoped visibility** — routing your telemetry to a restricted index or team scope, narrowing access below the general support population **Audit records:** Datadog Audit Trail records who accessed what within the organization — queries, dashboard views, configuration changes, and API key actions. Audit events relevant to your deployment can be exported on request, giving per-user, per-timestamp access records. *** ## Credentials The Datadog API key is unique per deployment. It is stored in a secrets manager on the Teleskope side, injected into the cluster as a Kubernetes Secret at deploy time, and never committed to source control. In deployments using External Secrets, the agent reads it from your cloud provider's parameter store rather than from Helm values. The key is **intake-only**. An API key can send data to Datadog but cannot read data back out. It can be rotated or revoked at any time, which stops ingest immediately — before any change to the running agent. *** ## Security controls * **In transit:** all agent-to-Datadog traffic is TLS 1.2 or higher over HTTPS, egress-only from the cluster. * **At rest:** Datadog encrypts stored data with AES-256. * **Network:** the agent requires no inbound connectivity. Because the path is egress-only to a single destination, you can verify at the network layer exactly what leaves the cluster. *** ## Compliance and subprocessors Datadog holds SOC 2 Type II and ISO 27001, 27017, and 27018 certifications among others, supports GDPR and CCPA through its Data Processing Addendum, and is HIPAA-eligible with a BAA on qualifying configurations. Datadog acts as a processor under its DPA and does not use customer telemetry to train models or for its own purposes. Its Trust Center is the authoritative list, since the certification set changes over time. Datadog is the only third party in this path. Its own hosting subprocessor for the US5 site is Google Cloud. No managed service providers or subcontractors have access to your telemetry. For Datadog's own documentation, two references are useful during a security review: * [Datadog Trust Center](https://trust.datadoghq.com/) — security posture, certifications, and requestable audit reports and policies * [Datadog subprocessor list](https://www.datadoghq.com/legal/subprocessors/) — the current published list For Teleskope's certifications and contractual commitments, see the [Teleskope Trust Center](https://trustcenter.teleskope.ai/). *** ## Purpose limitation Telemetry is used solely to operate and support your deployment — monitoring, alerting, and diagnosing issues. It is not used for analytics, benchmarking, product improvement, or AI model training. *** ## Verifying what is collected The configuration is auditable rather than something you have to take on trust: * **The agent configuration is a single Kubernetes resource** in your own cluster. Inspect it at any time and diff it against this page: ```bash kubectl get datadogagent -n datadog -o yaml ``` * **The Helm chart is version-controlled.** Rendered manifests can be provided for review through your change-management process before anything is deployed. * **The egress path is single-destination.** You can independently confirm at the network layer what leaves the cluster and where it goes. *** ## Disabling and offboarding Because the infrastructure runs in your account, each of these is available to you directly: 1. **Revoke the API key.** Ingest stops immediately, before any change to the agent. 2. **Disable the agent.** A single Helm flag (`datadog.enabled: false`), or delete the `datadog` namespace. In Teleskope-Managed and Outpost deployments you can do this through your own change-management process, since you operate the cluster. 3. **Delete the data.** Tagged telemetry ages out per the agreed retention. A targeted deletion request to Datadog can be submitted and confirmed in writing. *** ## Differences by deployment model | Model | Datadog agent | Cloud-native telemetry | Who can disable it | | ---------------------- | ---------------------------------------------------------------------- | ----------------------- | ----------------------------- | | **Single-tenant SaaS** | **On by default** in all deployments. Runs in Teleskope's account. | Teleskope's account | Teleskope | | **Teleskope-Managed** | Set per deployment and enabled in most. Runs in your account. | Your account and region | You or Teleskope | | **Outpost** | Set per deployment, commonly left off. Egress-only from your cluster. | Your cluster | You — you operate the cluster | | **Self-Managed** | Your choice, including shipping to Teleskope's monitoring environment. | Your account | You | {% hint style="info" %} **Outposts without Datadog.** An Outpost with the Datadog component disabled sends no logs, application metrics, infrastructure metrics, or Kubernetes events to Teleskope's Datadog account. It still exchanges required product data with your Teleskope environment, including scan results and a minimal service heartbeat. The Teleskope Helm chart applies standard `prometheus.io` scrape annotations to the workloads, so you can point your own Prometheus-compatible collector at the pod metrics endpoints and keep operational telemetry inside your environment. Contact Teleskope for the current scrape target inventory. {% endhint %}