### Output of kubectl krew install datadog Source: https://github.com/datadog/datadog-operator/blob/main/docs/kubectl-plugin.md Example output from installing the Datadog plugin with Krew, showing the success message and usage instructions. ```console $ kubectl krew install datadog Installing plugin: datadog Installed plugin: datadog \ | Use this plugin: | kubectl datadog | Documentation: | https://github.com/DataDog/datadog-operator / ``` -------------------------------- ### kubectl datadog autoscaling cluster install --help Source: https://github.com/datadog/datadog-operator/blob/main/docs/kubectl-plugin.md Shows the help output for the install command, including usage, examples, and flags. The command installs Karpenter on an EKS cluster, creating CloudFormation stacks and a Helm release. It can optionally create EC2NodeClass and NodePool resources. The command exits with an explanatory message if EKS auto-mode is active or if an unmanaged Karpenter installation exists. Re-running with default flags re-creates Karpenter resources, discarding manual edits. ```console $ kubectl datadog autoscaling cluster install --help Install autoscaling on an EKS cluster Usage: datadog autoscaling cluster install [flags] Examples: # install autoscaling kubectl datadog autoscaling cluster install Flags: --cluster-name string Name of the EKS cluster --create-karpenter-resources CreateKarpenterResources Which Karpenter resources to create: none, ec2nodeclass, all (default: all) (default all) --debug Enable debug logs --fargate-subnets strings Override auto-discovery of private subnets for the Fargate profile (comma-separated subnet IDs). Only used when --install-mode=fargate. --inference-method InferenceMethod Method to infer EC2NodeClass and NodePool properties: nodes, nodegroups (default nodegroups) --install-mode InstallMode How to run the Karpenter controller: fargate (on dedicated Fargate nodes, default) or existing-nodes (on existing cluster nodes) (default fargate) --karpenter-namespace string Name of the Kubernetes namespace to deploy Karpenter into (default "dd-karpenter") --karpenter-version string Version of Karpenter to install (default to latest) ``` -------------------------------- ### Install Datadog kubectl plugin with Krew Source: https://github.com/datadog/datadog-operator/blob/main/docs/kubectl-plugin.md Installs the Datadog kubectl plugin using the Krew plugin manager. Requires Krew to be installed and configured. ```shell kubectl krew install datadog ``` -------------------------------- ### kubectl datadog autoscaling cluster update --help Source: https://github.com/datadog/datadog-operator/blob/main/docs/kubectl-plugin.md Shows the help output for the update command, including usage, examples, and flags. The command refreshes an existing autoscaling installation, updating CloudFormation stacks and the Karpenter Helm release. It refuses to touch installations it did not create. Parameters that cannot change after install are read from the CloudFormation stack. The --create-karpenter-resources flag defaults to none to preserve manual edits. ```console $ kubectl datadog autoscaling cluster update --help Update an existing autoscaling installation on an EKS cluster Usage: datadog autoscaling cluster update [flags] Examples: # update a previously installed kubectl-datadog Karpenter deployment kubectl datadog autoscaling cluster update Flags: --cluster-name string Name of the EKS cluster --create-karpenter-resources CreateKarpenterResources Which Karpenter resources to (re-)create: none (default), ec2nodeclass, all (default none) --debug Enable debug logs --inference-method InferenceMethod Method to infer EC2NodeClass and NodePool properties when --create-karpenter-resources is set: nodes, nodegroups (default nodegroups) --karpenter-version string Version of Karpenter to upgrade to (default to latest) ``` -------------------------------- ### DatadogDashboard example configuration Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_dashboard.md Example DatadogDashboard resource definition with a timeseries widget. The widgets field is a JSON string containing the widget definition and layout. ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogDashboard metadata: name: example-dashboard spec: title: Test Dashboard layoutType: ordered tags: - "team:my_team" templateVariables: - availableValues: - host1 - host2 - host3 name: first prefix: bar-foo notifyList: - foobar@example.com widgets: '[{ "id": 2639892738901474, "definition": { "title": "", "title_size": "16", "title_align": "left", "show_legend": true, "legend_layout": "auto", "legend_columns": [ "avg", "min", "max", "value", "sum" ], "type": "timeseries", "requests": [ { "formulas": [ { "formula": "query1" } ], "queries": [ { "name": "query1", "data_source": "metrics", "query": "avg:system.cpu.user{*} by {host}" } ], "response_format": "timeseries", "style": { "palette": "dog_classic", "order_by": "values", "line_type": "solid", "line_width": "normal" }, "display_type": "line" } ] }, "layout": { "x": 0, "y": 0, "width": 4, "height": 2 } }]' ``` -------------------------------- ### Install Datadog Operator with Conversion Webhook Source: https://github.com/datadog/datadog-operator/blob/main/docs/v2alpha1_migration.md Install Datadog Operator v1.0.0+ with the Conversion Webhook Server enabled and the migration settings for v2alpha1. ```shell helm install \ datadog-operator datadog/datadog-operator \ --set image.tag=1.0.0 \ --set datadogCRDs.migration.datadogAgents.version=v2alpha1 \ --set datadogCRDs.migration.datadogAgents.useCertManager=true \ --set datadogCRDs.migration.datadogAgents.conversionWebhook.enabled=true ``` -------------------------------- ### Custom header file example Source: https://github.com/datadog/datadog-operator/blob/main/cmd/yaml-mapper/README.md Optional header file content to prepend to the mapped output. Define a headerPath to use it. ```yaml apiVersion: v1 kind: MyCustomResource ``` -------------------------------- ### Install Datadog Operator with Helm Source: https://github.com/datadog/datadog-operator/blob/main/docs/getting_started.md Add the Datadog Helm repository and install the Datadog Operator using the datadog-operator chart. ```shell helm repo add datadog https://helm.datadoghq.com helm install my-datadog-operator datadog/datadog-operator ``` -------------------------------- ### Install Datadog Operator with DatadogMonitor enabled Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_monitor.md Install the Datadog Operator with DatadogMonitor enabled, passing API and application keys via --set flags. ```shell helm install my-datadog-operator datadog/datadog-operator --set apiKey= --set appKey= --set datadogMonitor.enabled=true ``` -------------------------------- ### DatadogSLO example configuration Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_slo.md Example DatadogSLO resource configuration for a metric SLO. Defines the SLO name, description, query, tags, target threshold, timeframe, and type. ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogSLO metadata: name: example-slo namespace: system spec: name: example-slo description: "This is an example metric SLO from datadog-operator" query: denominator: "sum:requests.total{service:example,env:prod}.as_count()" numerator: "sum:requests.success{service:example,env:prod}.as_count()" tags: - "service:example" - "env:prod" targetThreshold: "99.9" timeframe: "7d" type: "metric" ``` -------------------------------- ### Example agent status output for http_check Source: https://github.com/datadog/datadog-operator/blob/main/docs/integrations_autodiscovery.md Example output from the agent status command showing the http_check check under Running Checks. The output includes instance ID, total runs, metric samples, events, service checks, and average execution time. ```shell ... http_check (3.1.1) ------------------ Instance ID: http_check:My service:5b948dee172af830 [OK] Total Runs: 234 Metric Samples: Last Run: 3, Total: 702 Events: Last Run: 0, Total: 0 Service Checks: Last Run: 1, Total: 234 Average Execution Time : 90ms ``` -------------------------------- ### Install Datadog Operator with DDGR enabled Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadoggenericresource/datadog_generic_resource.md Installs the Datadog Operator with the DatadogGenericResource CRD and controller enabled. Both flags are required: datadogCRDs.crds.datadogGenericResources=true installs the CRD, and datadogGenericResource.enabled=true starts the controller. ```shell helm install datadog-operator datadog/datadog-operator \ --set apiKey= \ --set appKey= \ --set datadogCRDs.crds.datadogGenericResources=true \ --set datadogGenericResource.enabled=true ``` -------------------------------- ### Run tests and build Source: https://github.com/datadog/datadog-operator/blob/main/docs/component_registry_dev/QUICK_START.md Use these commands to run the test suite and build the project. ```bash make test make build ``` -------------------------------- ### Create hello.yaml configuration file Source: https://github.com/datadog/datadog-operator/blob/main/docs/custom_check.md Configuration file for the custom check. It defines an empty init_config and a single instance. ```yaml init_config: instances: [{}] ``` -------------------------------- ### kubectl get datadogagent and ddai Without Profiles Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_agent_internal.md Example output showing that without DatadogAgentProfiles, a DatadogAgent creates a single DatadogAgentInternal with the same name and namespace. ```console $ kubectl get datadogagent -n datadog NAME AGE datadog 5m $ kubectl get ddai -n datadog NAME AGENT CLUSTER-AGENT CLUSTER-CHECKS-RUNNER AGE datadog Running Running Running 5m ``` -------------------------------- ### kubectl get ds output showing introspection DaemonSets Source: https://github.com/datadog/datadog-operator/blob/main/docs/introspection.md Example output from `kubectl get ds` in a mixed GKE cluster with Ubuntu and COS nodes. Shows two DaemonSets: `datadog-agent-default` for Ubuntu nodes and `datadog-agent-gke-cos` for GKE COS nodes, each with a suffix identifying the provider. ```console $ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE datadog-agent-default 2 2 2 2 2 3m21s datadog-agent-gke-cos 2 2 2 2 2 3m21s ``` -------------------------------- ### kubectl get datadogagent, datadogagentprofile, and ddai With Profiles Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_agent_internal.md Example output showing that with DatadogAgentProfiles, the Operator creates a default DatadogAgentInternal and one additional DatadogAgentInternal per profile. Profile-specific DDAIs run only the node Agent; Cluster Agent and Cluster Checks Runner run in the default DDAI. ```console $ kubectl get datadogagent -n datadog NAME AGE datadog 10m $ kubectl get datadogagentprofile -n datadog NAME AGE high-memory-nodes 2m $ kubectl get ddai -n datadog NAME AGENT CLUSTER-AGENT CLUSTER-CHECKS-RUNNER AGE datadog Running Running Running 10m high-memory-nodes Running 2m ``` -------------------------------- ### Test bundle with operator-sdk Source: https://github.com/datadog/datadog-operator/blob/main/RELEASING.md Tests the generated bundle locally using kind and operator-sdk. Optionally load a local image first, then install OLM and run the bundle. ```bash # When using a local image # kind load docker-image ./bin/operator-sdk olm install # If not already installed in your cluster. ./bin/operator-sdk run bundle docker.io/datadog/operator-bundle:0.7.1 ``` -------------------------------- ### Install cert-manager for webhook testing Source: https://github.com/datadog/datadog-operator/blob/main/docs/how-to-contribute.md Installs cert-manager, required for testing the webhook. ```shell $ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.0/cert-manager.yaml ``` -------------------------------- ### Deploy Datadog via mpdev Source: https://github.com/datadog/datadog-operator/blob/main/marketplaces/charts/google-marketplace/README.md Creates a dedicated namespace, builds and pushes the deployer image, then installs the Datadog application via mpdev with the specified parameters. Replace with your actual Datadog API key. ```shell kubectl create ns datadog-agent docker build --pull --platform linux/amd64 --build-arg TAG=$TAG --tag $REGISTRY/$APP_NAME/deployer . && docker push $REGISTRY/$APP_NAME/deployer && mpdev install \ --deployer=$REGISTRY/$APP_NAME/deployer \ --parameters='{"name": "datadog", "namespace": "datadog-agent", "datadog.credentials.apiKey": ""}' ``` -------------------------------- ### Install cert-manager with installCRDs Source: https://github.com/datadog/datadog-operator/blob/main/docs/v2alpha1_migration.md Install cert-manager with installCRDs set to true, a prerequisite for the Datadog Operator migration. ```shell helm install \ cert-manager jetstack/cert-manager \ --version v1.11.0 \ --set installCRDs=true ``` -------------------------------- ### View detailed monitor info with kubectl describe Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_monitor.md Run this command to view details about the 'datadog-event-v2-alert-test' monitor, including its specification, status conditions, and events. The sample output shows the monitor synced successfully with status OK. ```shell $ kubectl describe datadogmonitor datadog-event-v2-alert-test Name: datadog-event-v2-alert-test Namespace: system Labels: Annotations: API Version: datadoghq.com/v1alpha1 Kind: DatadogMonitor Metadata: Creation Timestamp: 2025-09-22T19:10:03Z Finalizers: finalizer.monitor.datadoghq.com Generation: 5 Resource Version: 3193 UID: 60c8071f-518f-4b75-a445-caaecea92061 Spec: Controller Options: Message: 1-2-3 testing Name: Test event v2 alert made from DatadogMonitor Options: Evaluation Delay: 300 Include Tags: true Locked: false No Data Timeframe: 30 Notify No Data: true Renotify Interval: 1440 Priority: 5 Query: events("sources:nagios status:(error OR warning) priority:normal").rollup("count").last("1h") > 10 Tags: test:datadog generated:kubernetes Type: event-v2 alert Status: Conditions: Last Transition Time: 2025-09-22T19:10:21Z Last Update Time: 2025-09-22T19:10:21Z Status: False Type: Error Last Transition Time: 2025-09-22T19:10:21Z Last Update Time: 2025-09-22T19:10:21Z Message: DatadogMonitor Created Status: True Type: Created Last Transition Time: 2025-09-22T19:10:21Z Last Update Time: 2025-09-22T19:10:21Z Message: DatadogMonitor ready Status: True Type: Active Last Transition Time: 2025-09-22T19:10:26Z Last Update Time: 2025-09-22T19:10:26Z Message: DatadogMonitor Updated Status: True Type: Updated Created: 2025-09-22T19:10:21Z Creator: eman.okyere@datadoghq.com Current Hash: 009148d415bf6e16d2f920e69d03a5f3 Downtime Status: Id: 217179025 Monitor Last Force Sync Time: 2025-09-22T19:10:26Z Monitor State: OK Monitor State Last Transition Time: 2025-09-22T19:11:27Z Monitor State Last Update Time: 2025-09-22T19:32:31Z Monitor State Sync Status: OK Primary: true Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Create DatadogMonitor 22m DatadogMonitor system/datadog-event-v2-alert-test ``` -------------------------------- ### Implement ComponentReconciler in component_.go Source: https://github.com/datadog/datadog-operator/blob/main/docs/component_registry_dev/COMPONENT_REGISTRY.md Create a new component file `component_.go` (copy from `component_example.go.tmpl`) implementing the ComponentReconciler interface. The Reconcile method creates a default deployment, applies global settings, features, and overrides, then calls createOrUpdateDeployment; Cleanup removes resources. The example uses placeholder names like MyNewComponent and MyNewComponentName that must be replaced. ```go package datadogagent import ( "context" // ... other imports datadoghqv2alpha1 "github.com/DataDog/datadog-operator/api/datadoghq/v2alpha1" "github.com/DataDog/datadog-operator/internal/controller/datadogagent/feature" "sigs.k8s.io/controller-runtime/pkg/reconcile" ) // MyNewComponent implements ComponentReconciler for my new deployment type MyNewComponent struct { reconciler *Reconciler } // NewMyNewComponent creates a new instance func NewMyNewComponent(reconciler *Reconciler) *MyNewComponent { return &MyNewComponent{ reconciler: reconciler, } } // Name returns the component name func (c *MyNewComponent) Name() datadoghqv2alpha1.ComponentName { return datadoghqv2alpha1.MyNewComponentName } // IsEnabled checks if the component should be reconciled func (c *MyNewComponent) IsEnabled(requiredComponents feature.RequiredComponents) bool { return requiredComponents.MyNewComponent.IsEnabled() } // GetConditionType returns the condition type for status updates func (c *MyNewComponent) GetConditionType() string { return common.MyNewComponentReconcileConditionType } // Reconcile reconciles the component func (c *MyNewComponent) Reconcile(ctx context.Context, params *ReconcileComponentParams) (reconcile.Result, error) { var result reconcile.Result // 1. Create default deployment/daemonset deployment := componentmynew.NewDefaultMyNewDeployment(params.DDA) podManagers := feature.NewPodTemplateManagers(&deployment.Spec.Template) // 2. Apply global settings global.ApplyGlobalSettingsMyNew(params.Logger, podManagers, params.DDA.GetObjectMeta(), ¶ms.DDA.Spec, params.ResourceManagers, params.RequiredComponents) // 3. Apply features for _, feat := range params.Features { if errFeat := feat.ManageMyNewComponent(podManagers, params.Provider); errFeat != nil { return result, errFeat } } // 4. Apply overrides if defined if componentOverride, ok := params.DDA.Spec.Override[c.Name()]; ok { if apiutils.BoolValue(componentOverride.Disabled) { return c.Cleanup(ctx, params) } override.PodTemplateSpec(params.Logger, podManagers, componentOverride, c.Name(), params.DDA.Name) override.Deployment(deployment, componentOverride) } // 5. Create or update the deployment return c.reconciler.createOrUpdateDeployment(params.Logger, params.DDA, deployment, params.Status, updateStatusV2WithMyNew) } // Cleanup removes the component's resources func (c *MyNewComponent) Cleanup(ctx context.Context, params *ReconcileComponentParams) (reconcile.Result, error) { deployment := componentmynew.NewDefaultMyNewDeployment(params.DDA) return c.reconciler.cleanupV2MyNew(params.Logger, params.DDA, deployment, params.Status) } // Helper functions for status updates func updateStatusV2WithMyNew(deployment *appsv1.Deployment, newStatus *datadoghqv2alpha1.DatadogAgentStatus, updateTime metav1.Time, status metav1.ConditionStatus, reason, message string) { newStatus.MyNewComponent = condition.UpdateDeploymentStatus(deployment, newStatus.MyNewComponent, &updateTime) condition.UpdateDatadogAgentStatusConditions(newStatus, updateTime, common.MyNewComponentReconcileConditionType, status, reason, message, true) } func (r *Reconciler) cleanupV2MyNew(logger logr.Logger, dda *datadoghqv2alpha1.DatadogAgent, deployment *appsv1.Deployment, newStatus *datadoghqv2alpha1.DatadogAgentStatus) (reconcile.Result, error) { // Cleanup logic here // Delete deployment, RBACs, etc. return reconcile.Result{}, nil } ``` -------------------------------- ### DatadogGenericResource YAML example Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadoggenericresource/datadog_generic_resource.md Example manifest for a DatadogGenericResource of type synthetics_browser_test. The jsonSpec field follows the Datadog API payload directly. ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogGenericResource metadata: name: browser-test-example spec: type: synthetics_browser_test jsonSpec: |- { "config": { [...] }, "locations": [ "aws:us-east-2" ], "message": "lorem ipsum", "name": "Example Browser test (DatadogGenericResource)", "options": { [...] }, "tags": [ "foo:bar" ], "type": "browser", "steps": [ [...] ] } ``` -------------------------------- ### Deploy DatadogDashboard with kubectl Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_dashboard.md Applies the DatadogDashboard configuration file to create the dashboard in Datadog. Replace /path/to/your/datadog-dashboard.yaml with the actual path. ```shell kubectl apply -f /path/to/your/datadog-dashboard.yaml ``` -------------------------------- ### kubectl get ds output Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_agent_profiles.md Output of kubectl get ds showing the DaemonSets created by the default profile (datadog-agent) and the profile datadogagentprofile-sample. ```console $ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE datadog-agent 1 1 1 1 1 5m3s datadogagentprofile-sample 1 1 1 1 1 44s ``` -------------------------------- ### kubectl datadog autoscaling cluster evict-legacy-nodes --help Source: https://github.com/datadog/datadog-operator/blob/main/docs/kubectl-plugin.md Shows the help output for the `evict-legacy-nodes` command, including usage, examples, and all flags. Use `--all` to target every non-Datadog node group, `--target` for a specific group, and `--dry-run` to preview actions. The command scales down `cluster-autoscaler`, then cordons and drains nodes one target at a time; it is re-runnable and does not restore capacity. ```console $ kubectl datadog autoscaling cluster evict-legacy-nodes --help Drain workloads from non-Datadog node groups onto Datadog-managed Karpenter NodePools Usage: datadog autoscaling cluster evict-legacy-nodes [flags] Examples: # evict every node group that is not Datadog-managed (cluster-autoscaler ASGs, # EKS managed node groups, user Karpenter NodePools, standalone EC2) kubectl datadog autoscaling cluster evict-legacy-nodes --all # evict a single ASG by name kubectl datadog autoscaling cluster evict-legacy-nodes --target=asg/my-legacy-asg # preview the actions without performing them kubectl datadog autoscaling cluster evict-legacy-nodes --all --dry-run Flags: --all Evict every node group that is not managed by Datadog --cluster-name string Name of the EKS cluster --debug Enable debug logs --dry-run Log the actions that would be taken without performing them --ensure-pdbs Create temporary PodDisruptionBudgets (maxUnavailable: 1) for workloads without one, and remove them at the end (default true) --eviction-timeout duration Time budget per pod for the Eviction API to succeed before giving up (PDB-blocked pods) (default 5m0s) --karpenter-namespace string Namespace where Karpenter is deployed (auto-detected when empty) --node-timeout duration Time budget per node for it to become empty after pods have been evicted (default 15m0s) --skip-cluster-autoscaler Do not scale the cluster-autoscaler Deployment to 0 replicas as step 1 --target standalone Target a specific node group: /, with one of asg, eksManagedNodeGroup, karpenter. Use standalone (no name) for standalone EC2 instances. Repeatable. Mutually exclusive with --all. --yes Skip the confirmation prompt ``` -------------------------------- ### Deploy basic v2alpha1.DatadogAgent resource Source: https://github.com/datadog/datadog-operator/blob/main/docs/how-to-contribute.md Creates the required secrets (datadog-secret with api-key and app-key, datadog-token with a 32-character token) and applies the minimum DatadogAgent example. The secret and deployment must be in the same namespace (system by default). ```bash #!/bin/bash export KUBE_NAMESPACE=system export DD_API_KEY= export DD_APP_KEY= export DD_TOKEN=<32-chars-token> kubectl -n $KUBE_NAMESPACE create secret generic datadog-secret --from-literal api-key=$DD_API_KEY --from-literal app-key=$DD_APP_KEY kubectl -n $KUBE_NAMESPACE create secret generic datadog-token --from-literal token=$DD_TOKEN kubectl -n $KUBE_NAMESPACE apply -f examples/datadogagent/datadog-agent-minimum.yaml ``` -------------------------------- ### Install Datadog Operator with DatadogSLO enabled Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_slo.md Installs the Datadog Operator via Helm with the DatadogSLO controller enabled. Substitute your Datadog API and application keys. ```shell helm install my-datadog-operator datadog/datadog-operator --set apiKey= --set appKey= --set datadogSLO.enabled=true ``` -------------------------------- ### DatadogMonitor configuration example Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadog_monitor.md A simple DatadogMonitor configuration that creates a metric alert for disk usage. Only metric alerts, query alerts, and service checks are supported. ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMonitor metadata: name: datadog-monitor-test spec: query: "avg(last_10m):avg:system.disk.in_use{*} by {host} > 0.5" type: "metric alert" name: "Test monitor made from DatadogMonitor" message: "We are running out of disk space!" tags: - "test:datadog" ``` -------------------------------- ### DatadogGenericResource notebook example Source: https://github.com/datadog/datadog-operator/blob/main/docs/datadoggenericresource/datadog_generic_resource.md Example DatadogGenericResource manifest that creates a notebook with a markdown cell and a timeseries graph. The jsonSpec contains the Datadog API payload for the notebook. ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogGenericResource metadata: name: ddgr-notebook-sample namespace: spec: type: notebook jsonSpec: |- { "data": { "attributes": { "cells": [ { "attributes": { "definition": { "text": "## Some test markdown\n\n```js\nvar x, y;\nx = 5;\ny = 6;\n```", "type": "markdown" } }, "type": "notebook_cells" }, { "attributes": { "definition": { "requests": [ { "display_type": "line", "q": "avg:system.load.1{*}", "style": { "line_type": "solid", "line_width": "normal", "palette": "dog_classic" } } ], "show_legend": true, "type": "timeseries", "yaxis": { "scale": "linear" } }, "graph_size": "m", "split_by": { "keys": [], "tags": [] }, "time": null }, "type": "notebook_cells" } ], "name": "Example-Notebook", "status": "published", "time": { "live_span": "1h" } }, "type": "notebooks" } } ``` -------------------------------- ### Build and test commands Source: https://github.com/datadog/datadog-operator/blob/main/AGENTS.md Common build and test commands for the Datadog Operator. Use `make build` for a full build, `make managergobuild` for just the Go binary, `go test ./...` for unit tests, `make ci-test` for unit and integration tests, `make lint` before committing, and `go test ./path/to/pkg/ -run TestName` for a single test. ```bash make build # Build manager + kubectl plugin (includes generate + lint) make managergobuild # Build only Go binary (skip lint/generate) go test ./... # Unit tests only make ci-test # Unit + integration tests (no build/fmt/licenses) make lint # golangci-lint + go vet — run before committing go test ./path/to/pkg/ -run TestName # Single test ```